CSC/ECE 517 Fall 2012/ch2b 2w22 sk: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 10: Line 10:
This principle is really about dependency relationships which have to be carefully managed in a large app - Erich Gamma <br>
This principle is really about dependency relationships which have to be carefully managed in a large app - Erich Gamma <br>


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.
In this principle, the word interface is more conceptual and should not be seen from the viewpoint of a language like Java or C# which has keyword by the same name. Interface in this context is relates to the OO principle of capabilities that the object(s)is(are) able to support. So by this definition an object can have many types or interfaces, and objects of different classes can have the same interface or type. In this context, the main idea behind this principle is how to decouple the implementation from the interface so that the code can be extended polymorphically.


For example:  
For example:  


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.
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.  
 
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.
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]


==Favor object composition over class inheritance==
==Favor object composition over class inheritance==

Revision as of 17:12, 17 November 2012

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

In this principle, the word interface is more conceptual and should not be seen from the viewpoint of a language like Java or C# which has keyword by the same name. Interface in this context is relates to the OO principle of capabilities that the object(s)is(are) able to support. So by this definition an object can have many types or interfaces, and objects of different classes can have the same interface or type. In this context, the main idea behind this principle is how to decouple the implementation from the interface so that the code can be extended polymorphically.

For example:

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.

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.

Favor object composition over class inheritance

Consider what should be variable in your design

REFERENCES

<references/> http://www.fatagnus.com/program-to-an-interface-not-an-implementation/
http://www.artima.com/lejava/articles/designprinciples.html
http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx
http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.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

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2b_2w22_sk&oldid=69914"