Forums

by Chris Power >> Sun, 22 Apr 2001 20:35:28 GMT

Date: Saturday, 14 April 2001 1:52 p.m.
Resubmitted Monday 23 April 2001

I've been spending some long bus journeys commuting to work figuring out why and how Jade could use real object-oriented interfaces.

Why should Jade have interfaces? Well I am convinced that a schema hierarchy is not the best higher-level organising principle. It works moderately for some purposes and situations, but doesn't allow you to incorporate frameworks easily. Mostly these frameworks or subsystems require you to subclass classes in the framework, which is altogether too tight a form of coupling for re-use. Interfaces allow you to define a views of classes and hand out only interface references, which don't let you get at stuff you shouldn't know about. Interfaces can be implemented by classes anywhere in a class hierarchy, and this is the loose coupling required between subsystems. As an example, think of a class that you might want to simultaneously to have table-displayability and to have task-schedulability and half a dozen other things. It would simply implement the table-displayability interface and the task-schedulability interface, etc. without having to be a subclass of anything in particular.

I believe that some sort of package concept with interfaces would meet the need. Interfaces have been around OO circles for long enough and Java programmers and many C++ programmers have met them. There is support for them in Rational Rose.

How? Well, that's a long discussion I'd like to have, along with the "Why?" question, with anyone who's interested.

As a starting point for debate, I've whipped up a tiny proof-of-concept demo that shows interfaces - without the desirable changes to the development environment and language. The implementation of interfaces in this schema is very much manual, whereas it should use dialogs in the development system and hide the "implementation classes" I've had to use for mapping of method calls to methods of the implementator classes.

--

Chris Power
Email crpower@ihug.co.nz
Phone 64 (9) 818 1281

by Wilfred Verkley >> Wed, 9 May 2001 1:05:59 GMT

Why should Jade have interfaces?

Im not against Interfaces, but many of the reasons you would use Interfaces for in another language (event handling, implementing collection classes etc) already have workarounds or alternate ways of doing it in Jade even if they can be clumsy. A well designed class hierarchy that implements the required interface methods at a high level is normally good enough.

The extra complexity that Interfaces would introduce to Jade isn't justified I think. There are other things, like streaming classes or simpler IDispatch COM support, that would make better additions to Jade IMHO.

Well I am convinced that a schema hierarchy
is not the best higher-level organising principle. It works moderately for some purposes and situations, but doesn't allow you to incorporate frameworks easily.

I agree. Its very difficult to seperate a schema like CardSchema into seperate components that can be transferred or inserted to other systems. Fine if you can dump everything into a universally used bemehoth like CardSchema, not so good for 3rd party components.

Wilfred.

by JensRichnow >> Mon, 15 Jul 2002 23:45:46 GMT

I would like to bring this thread to live again. I have been thinking for quite a while about the pros and cons of interfaces in Jade. Certainly, for many purposes there will be a workaround. However, every workaround has a down side (or many downsides), e.g, cluttered design, rigid hierarchical design which is more difficult to change, performance issues, etc. If we can avoid workarounds I'm in favour for interfaces in Jade.

From a design perspective, interface guarantee a certain behaviour. Working with Java and frequently using various design patterns I appreciate the power of interfaces. Implementing various design patterns in Jade in almost impossible due to the lack of interfaces.

Why would is be difficult to implement interfaces in Jade?

by dcooper@jade.co.nz >> Tue, 16 Jul 2002 2:54:16 GMT

Why would is be difficult to implement interfaces in Jade?

It not so much that it's difficult, but it's certainly not trivial either (clearly we'd want Interfaces in JADE to apply to persistent objects (as well as transients), and likely we'd want them to define state as well as behaviour - both of which mean Interfaces would need to take into account database reorg effects, which is something that other languages alone can avoid).

It's more about the priority of Interfaces with respect to all of the other capabilities that people would like incorporated into JADE.

First up, let me say that we think Interfaces are a great idea. The ability to avoid rigid class (implementation) hierarchies and refactor/redesign interfaces without having to change class inheritance is a compelling enough reason alone for us to consider providing them in JADE. They would be particularly useful in JADE where your class hierarchy defines both your transient and persistent object model, as they would allow redesign of the interface(s) to persistent objects while (in many cases) avoiding physical database reorgs/data reloads. We intend to provide Interfaces in a future release of JADE - we just can't give you a date right now.

JADE 6 provides a new feature called Packages. While this is not exactly the same as Interfaces, it will significantly enhance the ability for developers to package code in reusable components and reuse this code *across* schemas (ie: there is no requirement for the code to be in a superschema of the schemas that want to use it). Developers often define interface classes to expose functionality and this will become an even more valuable approach with Packages. While these are not Interfaces per se, as has already been mentioned, in many cases they can be used to achieve the same result. Interfaces have been considered throughout the design of Packages. We decided to implement Packages first as there has been more concrete demand for this capability and it will allow people to more easily refactor and reuse their existing (often large) monolithic reuse schemas while minimising the changes required to do so (because classes are the export mechanism between Packages - not a new concept such as Interfaces). Interfaces are a valuable concept in their own right, both within a schema branch and across schema branches.

It is interesting that in the last couple of years or so (in my experience, anyway) there has been an increasing focus towards operational (eg: 24 x 7, DR, deployment, etc), performance/scalability and interoperability features. This is to be expected given the nature of the IT environment today, the (ongoing) maturing of JADE, the size of the organisations that are using JADE and the size of the systems they're deploying. That's certainly not to question the validity of features such as Interfaces, but we have to take this into account and respond accordingly when prioritising new feature development.

Dean.

by JensRichnow >> Tue, 16 Jul 2002 4:46:34 GMT

Thanks Dean for the fast reply.

I do see your point in terms of priorities of Jade features. However, this highlights one of the great assets (and simultaneously, 'dilemma') of Jade, namely, to provide a complete tool, from language to DB to implementation, employment, etc. Priorities have to be made, I agree completely. And it is good to know that Interfaces are in discussion and, one day, maybe imlemented.

You spared me another posting (thread) to the newsgroup with respect to the new Packages in Jade 6 (I didn't had the time yet). When you talked about the Packages at the User Group Meeting I intuitively saw it as a great feature. Mostly because I associated it with the packages in Java which allow for a logical grouping of classes irrespective of inheritance and hierarchy (of course, depending on usage and design). On second thought, and probably because I still not fully understand the Jade concept of Packages, it appears to me as a more 'advanced', reusable partial schema extraction. After loading the Package into a new Schema, the class structure will be based on inheritance again? If so, what is the difference between a standalone Schema designed as a 'Package' (or Framework), for instance a XML parser, that can be loaded into any given other Schema?

Cheers

Jens

by dcooper@jade.co.nz >> Tue, 16 Jul 2002 11:41:33 GMT

[snip] it appears to me as a more 'advanced', reusable partial schema extraction.

Not really. You can achieve (sort of) similar results using partial schema extracts, but:

- For large units of reusable code, partial extracts can quickly become cumbersome.

- Client schemas can become bloated with implementation details that they don't need/want to know about (even if the source is stripped, you still have all of the implementation classes loaded and visible in the client schema).

- You can encounter class/property/method conflicts when loading reusable partial extracts from multiple different sources.

- There is no (easy) way for the provider of the reusable code to enforce an interface because all of the implementation classes are visible in the client schema.

- For multiple client schemas to reuse the code, the partial extract must be loaded into a common top-level schema (which encourages large, monolithic reuse schemas). Otherwise, the partial extract must be loaded (duplicated) multiple times, once for each client schema (this duplication is also necessary where multiple, unrelated schemas want to reuse the code).

Packages in JADE 6 recognise that single schema inheritance is limiting when you want a framework of classes implemented in one schema to be available to multiple other, unrelated schemas. For example, you may want to implement a "services" layer of schemas below the RootSchema in which you package all of your common class frameworks. You may want these services to be available to all application schemas implemented in unrelated schema branches. Each application schema may want to use classes from multiple frameworks.

Such a structure is possible, but difficult, to implement today (using global instance visibility) and is subject to several restrictions (which Packages remove). Typically, developers create few framework schemas (often only one) at the top of their schema hierarchy, from which all application schemas inherit. This can result in large and inflexible top-level schemas, as it is difficult to insert new framework schemas into an existing schema branch. Too many top-level framework schemas can lead to a top-heavy hierarchy as in order to maximise reuse, all framework schemas must be defined in a common branch from which all application schemas inherit.

Packages provide an easier and more effective way to build and reuse common code/components/frameworks. Existing schema hierarchies will require no changes and new functionality will be able to be added without the need to insert schemas into an existing schema branch.

A Package is part of a schema. A Package is *implemented* in a schema using class inheritance, just as you implement a schema today - that doesn't change. However, in JADE 6, the implementation schema can export one or more Packages, with each Package defining only those classes, properties, methods and constants that it wants to expose to other schemas. The implementation schema (ie: the schema that exports a Package) is also referred to as an *exporting* schema. From the exporting schema's point of view, think of a Package as a set of export definitions. The ability to export multiple Packages from a schema is important because you may implement a NetworkServicesSchema, for example, that provides SMTP, LDAP, FTP and SNMP functionality. You need to be able to expose each capability in its own logical Package (but with them all implemented in the same schema). The schema can still be used as the unit of deployment. For example, I can extract my NetworkServicesSchema (which will extract the implementation and all Package definitions) and load it into another environment (which will make the exported Packages available for use in that environment).

Another schema can import and use the features exposed in the Packages exported by an exporting schema. A schema that imports a Package is referred to as an *importing* schema. A single schema may be both an importer and an exporter. Importing and exporting schemas can be totally unrelated (ie: they may exist in completely independent schema branches).
The import name of a Package can be defined at import time (the default is the exported Package name). This caters for situations where an importing schema wants to make use of multiple exported Packages with the same name. However, Package definitions and export characteristics cannot be changed by an importer.

Where an imported class can unambiguously be identified (ie: its name does not conflict with a class already defined in the importing schema's branch, or another imported class), that class can be accessed by name. Where the name of an imported class does conflict with another class, you can access the imported class by prefixing the class name with the imported Package name using a new <Package name> :: <Class name> syntax. This addresses the problem of namespaces when several Packages export classes with the same name.

Hope this helps.

Dean.

by JensRichnow >> Tue, 16 Jul 2002 21:05:52 GMT

Thanks again for the exhausting reply. Looking forward to the Jade 6 release (not only because of this Package feature).

In a sense it is a shame that your feature description is buried in a different thread.