CSC/ECE 517 Fall 2012/ch2b 2w22 sk

Requirements

The introduction to the GoF book gives three principles for writing reusable and flexible software.

• Program to an interface, not an implementation.
• Favor object composition over class inheritance.
• Consider what should be variable in your design (originally, Encapsulate the behavior that varies).

Explain these principles, and illustrate them with original examples.

Program to an interface, not an implementation

This principle is really about dependency relationships which have to be carefully managed in a large app - Erich Gamma

The main idea behind this principle is to avoid dependencies as much as possible between different classes by decoupling the interface from the implementation. While it is easy to create dependencies, getting rid of them later during re-factoring is a tough task. When you have a tight coupling between the implementation and the interface, in the worst case it stops you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies.

So this approach gives you flexibility, but it also separates the really valuable part, the design, from the implementation, which allows clients to be decoupled from the implementation. One question is whether you should always use a Java interfaces for that. An abstract class is good as well. In fact, an abstract class gives you more flexibility when it comes to evolution. You can add new behavior without breaking clients.

In Java when you add a new method to an interface, you break all your clients. When you have an abstract class, you can add a new method and provide a default implementation in it. All the clients will continue to work. As always there is a trade-off, an interface gives you freedom with regard to the base class, an abstract class gives you the freedom to add new methods later. It isn't always possible to define an interface in an abstract class, but in the light of evolution you should consider whether an abstract class is sufficient.

Since changing interfaces breaks clients you should consider them as immutable once you've published them. As a consequence when adding a new method to an interface you have to do so in a separate interface. In Eclipse we take API stability seriously and for this reason you will find so called I*2 interfaces like IMarkerResolution2 or IWorkbenchPart2 in our APIs. These interfaces add methods to the base interfaces IMarkerResolution and IWorkbenchPart. Since the additions are done in separate extension interfaces you do not break the clients. However, there is now some burden on the caller in that they need to determine at run- time whether an object implements a particular extension interface.

Another lesson learned is that you should focus not only on developing version one, but to also think about the following versions. This doesn't mean designing in future extensibility, but just keeping in mind that you have to maintain what you produce and try to keep the API stable for a long time. You want to build to last. That's been an important theme of Eclipse development since we started. We have built Eclipse as a platform. We always keep in mind as we design Eclipse that it has to last ten or twenty years. This can be scary at times.

We added support for evolution in the base platform when we started. One example of this is the IAdaptable interface. Classes implementing this interface can be adapted to another interface. This is an example of the Extension Object pattern,. [4]

REFERENCES

<references/> http://www.fatagnus.com/program-to-an-interface-not-an-implementation/
http://www.artima.com/lejava/articles/designprinciples.html
http://www.amazon.com/gp/product/0596007124?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596007124
http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201633612