Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:27:17Z

Karthi2: /* References */

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?'''<ref>http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from</ref> 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition'''<ref>http://www.kuro5hin.org/story/2002/7/14/81923/3656</ref> 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks'''<ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref> <ref>http://www.kuro5hin.org/story/2002/7/14/81923/3656</ref> 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them:<ref>http://www.palserv.com/dp/DesignPatternsOverview.html</ref> 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html 
2. http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance 
3. http://www.amazon.com/gp/product/0596007124?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596007124 
4. http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201633612

==References==
<references/>

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:26:58Z

Karthi2: /* Consider what should be variable in your design */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:25:42Z

Karthi2: /* Favor object composition over class inheritance */

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?'''<ref>http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from</ref> 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition'''<ref>http://www.kuro5hin.org/story/2002/7/14/81923/3656</ref> 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks'''<ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref> <ref>http://www.kuro5hin.org/story/2002/7/14/81923/3656</ref> 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html 
2. http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance 
3. http://www.amazon.com/gp/product/0596007124?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596007124 
4. http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201633612

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:19:33Z

Karthi2: /* See Also */

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?'''<ref>http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from</ref> 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks'''<ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref> 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html 
2. http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance 
3. http://www.amazon.com/gp/product/0596007124?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596007124 
4. http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201633612

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:17:03Z

Karthi2: /* Favor object composition over class inheritance */

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?'''<ref>http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from</ref> 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks'''<ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref> 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html 
2. http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:15:47Z

Karthi2: /* See Also */

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks'''<ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref> 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html 
2. http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:15:34Z

Karthi2:

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks'''<ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref> 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html
2. http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:13:39Z

Karthi2:

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' <ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref>
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
1. http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:13:02Z

Karthi2:

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''<ref>http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation</ref>

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' <ref>http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance</ref>
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:08:59Z

Karthi2:

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==See Also==
http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html 

==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://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T17:08:27Z

Karthi2: /* References */

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T16:58:22Z

Karthi2:

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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<ref>http://www.fatagnus.com/program-to-an-interface-not-an-implementation/</ref> <ref>http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx</ref>. 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-24T16:27:16Z

Karthi2:

==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 <ref>http://www.artima.com/lejava/articles/designprinciples.html</ref> 

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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-20T00:27:04Z

Karthi2: /* Program to an interface, not an implementation */

==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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.png]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

File:UML-Program to an Interface.png

2012-11-20T00:25:49Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-20T00:21:38Z

Karthi2: /* Program to an interface, not an implementation */

==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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted. The UML diagram for the interface would look something like this:-

[[File:UML-Program_to_an_Interface.jpg]]

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-20T00:10:22Z

Karthi2: /* Program to an interface, not an implementation */

==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 a keyword by the same name. Interface relates to the OO principle of capabilities that the object is 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 ie., to reduce the implementation 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.

'''Dynamic Binding, Polymorphism and Interfaces'''

The first principle of design patterns is also tied to polymorphism as noted above. Let us look at this part in more detail.

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Another way to look at this principle is that one should focus not only on developing one single version of an application, but to design it keeping in mind that one have to maintain and keep the API stable for a sustained period of time.

Just by following this rule, you get two very important benefits as stated in the GOF book:
# Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
# Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

An example why we have to program to an interface is shown below:
<pre>
public ProcessedBeans processBeans(Beans beans){
ProcessedBeans processedBeans = beans.getProcessedBeans();
return processedBeans;
}
</pre>

In the above code, we are programming for an implementation assuming that beans is the only item that needs processing. But, as we know, this is not the case. We have to process other food items as well before consumption. Due to the way we have programmed it now we will have to add many more functions for each type of food item that needs processing. This can be avoided, however, by programming to an interface.
<pre>
public ProcessedFood processFood(FoodItem foodItem){
ProcessedFood processedFood = foodItem.getProcessedItem();
return processedFood;
}
</pre>

By doing so, we have eliminated the need to add new functions for each food type as already noted.

==Favor object composition over class inheritance==
'''Definitions''':
* ''[http://en.wikipedia.org/wiki/Object_composition Object Composition]'' is a way to combine simple objects or data types into more complex ones.
* Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behavior and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

'''Why do we need this?''' 
Both methods - object composition and inheritance provide a means for code reuse which is one of the fundamental principles of OO programming. With inheritance the subclasses are tightly coupled to the parent classes which reduces the flexibility. Each subclass knows the internal representation of the parent class which break encapsulation. This creates a dependency between the subclass and the superclass which is not a desirable trait. This is why inheritance is generally referred to as '''''white box''''' reuse. In most scenarios you do not want to expose the internal implementation of the super class and that is where composition comes into play.

Inheritance is good to represent ''is-a'' relationships but is not suitable for portraying ''has-a'' relationships. Many relationships between classes or components do not fall into the ''is-a'' category. (for example, a Car class is likely not a HashMap, but it may have a HashMap). In these scenarios it follows the composition is a better idea for modeling relationships between classes rather than inheritance.

Below is one simple example where composition is much suited than inheritance.

<pre>
Class Location {
String name;
...
}

Class Journey {
Location source, destination;
double getDistance() {...}
...
}

Class Flight extends Journey {...}
Class Bus extends Journey {...}

</pre>

In the above example, instead of having a sub-class for Flight, class Journey can have a new field which is TransportMode which represents different modes of transport such as flight, bus, train etc.

<pre>
Class Location {
String name;
...
}

Class TransportMode {
TransportType type;
double getCost(double distance) {...}
...
}

Class Journey {
Location source, destination;
TransportMode mode;
double getDistance() {...}
double getCost() { mode.getCost( getDistance() ) }
...
}
</pre>

However this is not to say that inheritance should not be used at all. Below is another example which shows that inheritance is the one which we should be using. Here the Human class represents a ''is-a'' relationship with Animal class which is quite natural and the proper way to look at the classes.

<pre>
abstract class Animal {
private String name;
public String getName(){
return name;
}
abstract String isIntelligent();
}

class Cat extends Animal{
public String isIntelligent(){
return "No";
}
}

class Human extends Animal{
public String isIntelligent(){
return "Yes";
}
}
</pre>

In short, one should use inheritance for behavioral purposes ie., subclasses should override methods to specialize the behavior of the method and the object itself.

'''Benefits of object composition''' 
* To favour composition over inheritance is a design principle that gives the design higher flexibility.
* Initial design becomes simple by avoiding hierarchical relationship among classes via inheritance and by identifying object behaviors in separate interfaces.
* Can easily accommodate future requirements without having to restructure large portions of code.

'''Drawbacks''' 
* All of the methods provided by the composed classes must be implemented in the derived class, even if they are only forwarding methods.
* In inheritance the derived class only need to implement methods whose behavior needs to be modified..
* Significantly less programming effort if only a handful of functions in the superclass needs to be overridden in the subclass.

==Consider what should be variable in your design==
The key to identifying what should be variable lies in anticipating new requirements and changes to the existing requirements. The system must be designed in such a way so that it can evolve accordingly. Designing a robust system is we must take into account unforeseen changes to avoid a major design overhaul in future. Those changes might involve class redefinition and re-implementation, client modification, and retesting.Redesign affects many parts of the software system, and unanticipated changes are invariably expensive.

Design patterns help you avoid this by ensuring that a system can change in specific ways. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Below are some common causes of redesign along with the design pattern(s) that address them: 
*'''Creating an object by specifying a class explicitly:''' Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype].

*'''Dependence on specific operations:''' When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command].

*'''Dependence on hardware and software platform:''' External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It's important therefore to design your system to limit its platform dependencies.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge].

*'''Dependence on object representations or implementation:''' Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy].

*'''Algorithmic dependencies:''' Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

*'''Tight coupling:''' Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can't change or remove a class without understanding and changing many other classes. The system becomes a dense mass that's hard to learn, port, and maintain.Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Observer_pattern Observer].

*'''Extending functionality by subclassing:''' Customizing an object by subclassing often isn't easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example,

Overriding one operation might require overriding another. An overridden operation might be required
to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce
many new subclasses for even a simple extension.

Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns
produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy].

*'''Inability to alter classes conveniently:''' Sometimes you have to modify a class that can't be modified conveniently. Perhaps you need the source code and don't have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.

'''Design patterns:''' [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor].

These examples reflect the flexibility that design patterns can help you build into your software. How crucial such flexibility is depends on the kind of software you're building.

'''Advantages:'''
*Enables large scale reuse of software.
*Helps in improving developer communication.
*Captures expert knowledge and design trade-offs and make expertise widely available

'''Disadvantages:'''
*Does not lead to direct code reuse and is complex in nature.
*They are validated by experience and discussion.
*They consume more memory because of generalized format.
*They are optimized to store any kind of data. This can degrade performance.

==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.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/ 
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 
http://stackoverflow.com/questions/3979581/disadvantage-of-object-composition-over-class-inheritance 
http://blog.fedecarg.com/2008/09/04/favour-object-composition-over-class-inheritance/ 
http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from 
http://www.kuro5hin.org/story/2002/7/14/81923/3656 
http://www.palserv.com/dp/DesignPatternsOverview.html

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:35:38Z

Karthi2: /* REFERENCES */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:29:55Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:20:01Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:15:37Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:08:27Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:02:31Z

Karthi2: /* REFERENCES */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T19:00:23Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-18T08:24:17Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T19:54:16Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T19:42:28Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T19:42:14Z

Karthi2: /* Favor object composition over class inheritance */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T19:11:46Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T18:31:16Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T18:30:16Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T18:29:12Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T17:19:02Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T17:17:38Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T17:15:39Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T17:12:25Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T16:18:09Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T16:17:46Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T16:15:09Z

Karthi2: /* Program to an interface, not an implementation */

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-17T15:38:59Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-15T19:16:49Z

Karthi2:

==Program to an interface, not an implementation==
This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java development tools like Eclipse even write this statement for you. Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial.

Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that's a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. Fortunately, with today's refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one 'extract interface' refactoring away.

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]

==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://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

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-15T19:16:17Z

Karthi2:

==Program to an interface, not an implementation==
This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java development tools like Eclipse even write this statement for you. Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial.

Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that's a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. Fortunately, with today's refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one 'extract interface' refactoring away.

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]

==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://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

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-15T19:13:00Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-15T19:09:59Z

Karthi2:

CSC/ECE 517 Fall 2012/ch2b 2w22 sk

2012-11-15T19:07:07Z

Karthi2: Created page with "==Program to an interface, not an implementation== ==Favor object composition over class inheritance== ==Consider what should be variable in your design=="

==Program to an interface, not an implementation==
==Favor object composition over class inheritance==
==Consider what should be variable in your design==

CSC/ECE 517 Fall 2012

2012-11-15T18:58:49Z

Karthi2:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-08T00:37:55Z

Karthi2: /* Concurrent Versions System (CVS)http://en.wikipedia.org/wiki/Concurrent_Versions_System */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* [[Branching (software)|Branching]] as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends [[diff]]s in both directions.
* Costs proportional to change size, not to data size.
* [[Parsing|Parsable]] output, including [[XML]] log output.
* [[Open source]] licensed — [[Apache License]] in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* [[Internationalization and localization|Internationalized]] program messages.
* [[File locking]] for unmergeable files ("reserved checkouts").
* Path-based authorization.
* [[Language binding]]s for [[C Sharp (programming language)|C#]], [[PHP]], [[Python (programming language)|Python]], [[Perl]], [[Ruby (programming language)|Ruby]], and [[Java (programming language)|Java]].
* Full [[MIME]] support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-07T23:50:00Z

Karthi2: /* Configuration Management Version Control (CMVC)http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC) */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis. Not scalable for larger projects.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* [[Branching (software)|Branching]] as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends [[diff]]s in both directions.
* Costs proportional to change size, not to data size.
* [[Parsing|Parsable]] output, including [[XML]] log output.
* [[Open source]] licensed — [[Apache License]] in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* [[Internationalization and localization|Internationalized]] program messages.
* [[File locking]] for unmergeable files ("reserved checkouts").
* Path-based authorization.
* [[Language binding]]s for [[C Sharp (programming language)|C#]], [[PHP]], [[Python (programming language)|Python]], [[Perl]], [[Ruby (programming language)|Ruby]], and [[Java (programming language)|Java]].
* Full [[MIME]] support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-07T23:43:10Z

Karthi2: /* File Sharing Models */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model''' <ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.

===='''Source Code Control System (SCCS)'''<ref>http://en.wikipedia.org/wiki/Source_Code_Control_System</ref>====
It is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
:SCCS was the dominant version control system for Unix until the release of the [http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System (RCS)]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including [http://en.wikipedia.org/wiki/BitKeeper BitKeeper] and [http://en.wikipedia.org/wiki/TeamWare TeamWare]. The latter is a frontend to SCCS. [http://en.wikipedia.org/wiki/Sablime Sablime] has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called [http://en.wikipedia.org/wiki/Interleaved_deltas interleaved deltas] (or the weave). This storage technique is now considered by many [http://en.wikipedia.org/wiki/Revision_control revision control] system developers as foundational to advanced merging and versioning techniques, such as the "Precise [http://en.wikipedia.org/wiki/Codeville Codeville]" ("pcdv") merge.
:'''What does a source code control system do?'''
:If you are creating or maintaining a text file---perhaps a document, or a script, or a program---a source code control system can do several things for you:
:*It can keep track of the changes made to the file: what was changed, when it was changed, and by whom.
:*It provides a version numbering scheme so you can tell which versions of a file are more recent.
:*It can retrieve previous versions of your file, so that you can retreat to an older version if you decide that the current version is a bad idea, or if you want to see some text that has since been changed or deleted.
:*If you accidentally delete the current file, you can get back the last version.
:*If several people are working with the same file, a source code control system can help you coordinate your work and keep track of who did what, and when.

SCCS is also known for the <code>sccsid</code> string, for example:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, this string can be found in binary and object files by looking for the pattern "@(#)" and can be used determine which source code files were used during compilation.

===='''Control System(RCS)'''<ref>http://en.wikipedia.org/wiki/Revision_Control_System Revision</ref>====
It automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
:RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
:Ref.[3] is a comprehensive book on CSSC and RCS.

==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram [http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html] provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]
===='''Concurrent Versions System (CVS)'''<ref>http://en.wikipedia.org/wiki/Concurrent_Versions_System</ref>====
It was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification. CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
#CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs '''cvs ci 1.c 3.c''' and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it could result in damage of existing project at repository.
#CVS only tracks modification on a file-by-file basis. Not scalable for larger projects.
#CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
#Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
#Slow

===='''Subversion (SVN)'''<ref>http://en.wikipedia.org/wiki/Subversion_%28software%29</ref>====
As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1].
[[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]

'''Features:''' <ref>http://en.wikipedia.org/wiki/Apache_Subversion#Features</ref>
* [http://en.wikipedia.org/wiki/Commit_(data_management) Commits] as true [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomic operations] (interrupted commit operations in CVS would cause repository inconsistency or corruption).
* Renamed/copied/moved/removed files retain full revision history.
* The system maintains [http://en.wikipedia.org/wiki/Software_versioning versioning] for directories, renames, and file [http://en.wikipedia.org/wiki/Metadata metadata] (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
* Versioning of [http://en.wikipedia.org/wiki/Symbolic_link symbolic link]s.
* Native support for binary files, with space-efficient binary-diff storage.
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] as network server, [http://en.wikipedia.org/wiki/WebDAV WebDAV]/[http://en.wikipedia.org/wiki/WebDAV#Extensions_and_derivatives Delta-V] for protocol. There is also an independent server [http://en.wikipedia.org/wiki/Process_(computing) process] called svnserve that uses a custom protocol over [http://en.wikipedia.org/wiki/Internet_Protocol_Suite TCP/IP].
* [[Branching (software)|Branching]] as a cheap operation, independent of file size (though Subversion itself does not distinguish between a branch and a directory)
* Natively [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client–server], [http://en.wikipedia.org/wiki/Abstraction_layer layered] [http://en.wikipedia.org/wiki/Library_(computing) library] design.
* Client/server protocol sends [[diff]]s in both directions.
* Costs proportional to change size, not to data size.
* [[Parsing|Parsable]] output, including [[XML]] log output.
* [[Open source]] licensed — [[Apache License]] in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
* [[Internationalization and localization|Internationalized]] program messages.
* [[File locking]] for unmergeable files ("reserved checkouts").
* Path-based authorization.
* [[Language binding]]s for [[C Sharp (programming language)|C#]], [[PHP]], [[Python (programming language)|Python]], [[Perl]], [[Ruby (programming language)|Ruby]], and [[Java (programming language)|Java]].
* Full [[MIME]] support — users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.
* Merge tracking - Merges between branches will be tracked, this allows automatically merging between branches without telling Subversion what (doesn't) need to be merged.

=====Eclipse Subversive - Subversion (SVN) Team Provider<ref>http://www.eclipse.org/subversive/</ref>=====
The Subversive project is aimed to integrate the Subversion (SVN) version control system with the Eclipse platform. Using the Subversive plug-in, you can work with projects stored in Subversion repositories directly from the Eclipse workbench in a way similar to work with other Eclipse version control providers, such as CVS and Git.

'''Subversive Features''': Subversive plug-in provides access to Subversion repositories from the Eclipse workbench.

*'''Full-Scale SVN Client'''
:Subversive is designed to be used as a full-featured SVN client, so you can update, commit, merge changes, work with SVN properties, view change history and perform other operations with SVN directly from the Eclipse environment.

*'''Advanced SVN Features'''
:Subversive includes several features that extend functionality of the standard SVN client. In particular, Subversive can show the SVN repository content grouped by the logical structures of trunk, branch and tag and display changes on a visual revisions graph.

*'''Seamless Integration with Eclipse'''
:Subversive is an official Eclipse project and an integral part of Eclipse Simultaneous releases. The project follows all Eclipse guidelines and requirements to deliver a quality SVN team provider plug-in similar to CVS and Git implementations.

*'''Support of the Latest SVN Versions'''
:Subversive evolves together with the Subversion project to provide Eclipse users with the features that appeared in new versions of the SVN implementation. You can use the new SVN functionality in Eclipse by installing the Early Access version of Subversive.

===='''Configuration Management Version Control (CMVC)'''<ref>http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC)</ref>====
It was developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.

::One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock. Some proprietary client-server based version control softwares are:
::*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
::*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
::*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
::*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
#[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
#[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

* Locking may cause unnecessary delay and is not desired when it comes to teams/projects which have a small cycle time between releases. For example: Suppose say, user A checks out a file (locks it) and some interrupt in his work causes him to switch to another task of higher priority. There is a possibility that he forgets completely about the file that he checked out. Now, if another user B wants to edit the same file, he cannot do so, without having the administrator unlock the file for him, his hands are tied!

* Locking may cause unnecessary serialization: What if two different users A and B want to edit different non-intersecting portions of the same file? With proper merging solution in place, they could have done it easily without bothering about what the other user does with the file.

* Locking may create a false sense of security: As with any model, lock-modify-unlock approach too allows two different users to work on separate files simultaneously. However the model does not define how dependencies between files are dealt with. For example: Suppose A locks and edits file f1, while B simultaneously locks and edits file f2. If there is a function call in f1 whose definition exists in f2 but the definition is removed or the function name is changed after editing f2, they don't work together anymore. Thus, locking files by itself does not provide security against such deliberate changes. Lot of manual synchronization is needed to avoid such situations which is only going to cause delay in the development of the project.

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==
<references/>

==Additional References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]

CSC/ECE 517 Fall 2012/ch1 1w1 rk

2012-09-07T04:21:56Z

Karthi2: /* File Sharing Models */

==Introduction==
A [http://en.wikipedia.org/wiki/Revision_control version control] system '''(VCS)''' is a process for managing software codes,files and directory structures and corresponding updates made to them during software development, web development etc. project or during subsequent project maintenances. Version control is also known as revision control, source control or [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM)[6].

Any software development project is a dynamic and fast paced environment. In a typical setting, development for a project is performed simultaneously by many developers. Thus, incorporating all the changes made, either simultaneously or at different times, poses a new type of challenge.

This wikibook chapter focuses mainly on the development history of different version control systems.

==Why version control systems are needed?==
The major issues in a dynamic development environment can be described as:
* Obviously, '''merging''' of a lot of files. If we consider somebody to do merging manually, The sheer volume of communication required is overwhelming. This communication can be among the developers themselves in a small team or between the team leader in charge of merging and the rest of the group.

* '''Accountability:''' if one of the developers breaks the code flow during development, It is tough to detect and naturally nobody steps forward to take the blame. A version control system can precisely indicate who caused the break in the code.

* If a certain code implementation doesn't work as expected, '''Reverting''' to last satisfactory state may be required.

* Development on stale code may result in '''Code loss'''. for example, two developers downloaded a certain file at 10AM. One of the developers modified foo_1() method and uploaded modified file at 10:30AM.The other developer modified foo_2() method and uploaded the same file at 10:45AM. Since the functions are in the same file, the second upload will overwrite the file uploaded by first developer at 10:30AM causing loss of his part of work.

* Even a lone coder might need to '''review''' why he or she made a certain change in code. Comments during code check-in can be a useful resource in such situation.

* Version control provides a form of '''documentation''' which makes tracking easy. i.e.-'''tagging''' is a kind of snapshot of all files and documents at a particular stage of development, usually during a stable release. This allows the developers to work with the exact files that were included in that release for bug-fixing purpose.

* '''Sandboxing / Branching:''' Version control makes it possible to perform temporary code changes in an isolated area, usually in branch folder, for testing purpose. If the outcome is satisfactory then the code can be merged with the existing code, otherwise it can be discarded without having any impact on the main code.

* Now a days, software development teams are spread across different countries and work at different time zones. Use of a version control system for project aggregation becomes unavoidable.

==Evolution of version control systems==

VCS' can be broadly categorized into three groups based on the repository model. The sequence below follows the evolution of version control systems as well:

==='''Local repository model'''===
Local version control systems had one storage location of the files. It was called local because it didn't support networked commands or access like the other later softwares. So, all the developers had to use same computer system to access or modify files.
#'''[http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)]''' is one of the pioneer source code revision softwares.[5] SCCS was developed at Bell Labs in 1972 by Marc J. Rochkind. Although it was originally developed for OS/MVT, SCCS was included in [http://en.wikipedia.org/wiki/Source_Code_Control_System some UNIX distributions.] SCCS ruled as the dominant VCS until ''Revision Control System'' was released.
#'''[http://en.wikipedia.org/wiki/Revision_Control_System Revision Control System(RCS)]''' automated storing, retrieval, logging, identification, and merging frequent revisions of texts. RCS was first released in 1982 by Walter F. Tichy as an alternative to SCCS. It quickly gained popularity and almost replaced SCCS.[9]
::RCS performed better by storing the most recent copy of file and then storing only reverse differences called "deltas".One of the shortcomings of RCS was that only one person at a time could edit the file. RCS could manage only single files, not a whole project or directory.
::Ref.[3] is a comprehensive book on CSSC and RCS.
==='''Client-server model'''===
The [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server model] utilizes a single centralized repository for the version control which is accessible to the developers through network or internet. The below diagram<ref>http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html </ref> provides a high level overview of the model.
[[Image:Client_Server_Model.png |center|]]

#'''[http://en.wikipedia.org/wiki/Concurrent_Versions_System Concurrent Versions System (CVS)]''' was one of the early client-server model based scheme. Dick Grune started developing CVS from 1984-1985 to allow his students to collaborate in a project according to their schedule. CVS was publicly released at 1986.The main improvement for CVS over RCS was that CVS could manage the whole project while RCS could only work on a file at a time.At the beginning, CVS was script based and called RCS at background. Later it was developed into a full fledged program. A lot of the IDE's (Emacs, Eclipse/aptana,Netbeans, Komodo, PHPEdit etc.) support CVS. CVSNT is a cross platform port of CVS with some modification.
::CVS, which was the defacto standard for version controlling for a long time is almost replaced today by SVN. There were many disadvantages of CVS which hindered its stay in the industry further. Prominent ones were
::*CVS check-in is not an [http://en.wikipedia.org/wiki/Atomic_commit atomic] operation. For example, given the files 1.c, 2.c, 3.c, 4.c and if someone runs 
                     cvs ci 1.c 3.c 
                 and someone else runs cvs update at the same time, the person running update might get only the change to `3.c' and not the change to `1.c'. So, if check-in process was disturbed, it                  could result in damage of existing project at repository.
::* CVS only tracks modification on a file-by-file basis. Not scalable for larger projects.
::* CVS was designed with only text files in mind. No native support for other formats. Extensive modification are necessary at the client and the server to support other file types.
::* Conflict resolution in CVS, if not absent, is definitely not good. Conflict markers used in CVS may go unnoticed and those file might find their way into the repository.
::* Slow
#'''[http://en.wikipedia.org/wiki/Subversion_%28software%29 Subversion (SVN)]''': As the complexity of projects increased, the shortcomings of CVS became more and more prominent. This led to the development of Subversion. CollabNet started developing svn as a successor of CVS with added [http://en.wikipedia.org/wiki/Subversion_(software)#Features functionality][2][7]. Different open source projects (i.e.-[http://en.wikipedia.org/wiki/Apache_Software_Foundation Apache Software Foundation],[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby],[http://en.wikipedia.org/wiki/SourceForge SourceForge],[http://en.wikipedia.org/wiki/Tigris.org Tigris.org], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/Python_(programming_language) Python] and [http://en.wikipedia.org/wiki/MediaWiki MediaWiki]) use Subversion. Subversion is an open source software due to it's Apache license[1]. [[Image:Subversion_project_visualization.svg.png|650px|thumb|center|Visualization of a very simple Subversion project. Source:wikimedia commons, Explanation of terms can be found at http://en.wikipedia.org/wiki/Apache_Subversion, "Branching and tagging" and at http://en.wikipedia.org/wiki/Revision_control, #"Common vocabulary"]]
#'''[http://en.wikipedia.org/wiki/IBM_Configuration_Management_Version_Control_(CMVC) Configuration Management Version Control (CMVC)]''' developed by IBM Corporation in the mid-late 1990s and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. CMVC was superseded by IBM Rational ClearCase and ClearQuest. The system was used to manage the IBM OS/2 and IBM AIX source code repositories in the 1990s. It is still widely used within IBM by various teams.
:One of the drawbacks of CMVC is that, once a file is checked-out by a user, it remains locked to all the other users until the either the new version is checked-in or the lock is released explicitly by the owner (user) of the lock.
# Some proprietary client-server based version control softwares are-
#:*[http://en.wikipedia.org/wiki/Autodesk_Vault Autodesk Vault] was specifically developed for Autodesk applications.
#:*[http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was developed by IBM Rational Software. It's a Source Code Control (SCC) compliant software.
#:*[http://en.wikipedia.org/wiki/Visual_SourceSafe Visual SourceSafe] is developed by Microsoft targeting small development team.
#:*[http://en.wikipedia.org/wiki/Visual_Studio_Team_System Visual Studio Team System] is also developed by Microsoft targeting larger groups.

===Distributed model===
'''Distributed Version Control (DVCS)''', or '''Decentralized Version Control''' systems can have many central repositories.This is a peer to peer approach. The concept started developing at late 90's. In DVCS. Each developer works with his or her local repository and the changes are synchronized between repositories upon commit. DVCS are better suited for large teams with partially independent developers. i.e.- opensource software development.[8]
##[http://en.wikipedia.org/wiki/Monotone_%28software%29 Monotone] and [http://en.wikipedia.org/wiki/GNU_arch GNU arch] were the first generation DVCS (release:2001-2003) followed by [http://en.wikipedia.org/wiki/Darcs Darcs] (stable release:2010).[http://en.wikipedia.org/wiki/Mercurial Mercurial] , [http://en.wikipedia.org/wiki/Git_%28software%29 Git] and [http://en.wikipedia.org/wiki/Bazaar_%28software%29 Bazaar] (2005-2007) are well adopted among developers.
##[http://en.wikipedia.org/wiki/BitKeeper BitKeeper],[http://en.wikipedia.org/wiki/Code_Co-op Code Co-op], [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] are some proprietary DVCS softwares.

It should be noted that many distributed version control softwares support client-server model too.One of the benefits of DVCS is that a developer can save the source code as long as he wants even if the central repository (in client-server model) is discarded at the end of a project.

[[Image:timeline.jpg|650px|thumb|center|A generalized timeline. Source:http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av]]

== File Sharing Models ==
Every system that implement version controlling have to address one fundamental problem: How will the files in the repository be safely shared across users but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Consider the scenario with two users A and B. Both of them check out the same file (same version). User A after making his modification, suppose, commits the file first. A few moments later B completes his modification. B does not have any clue about A's check-in and he happily commits his code to the repository. Now B has accidentally overwritten the changes made by A leaving the system in an inconsistent state. This problem can be solved in two different ways: 
* Lock-Modify-Unlock
* Copy-Modify-Merge 
While CMVC follows the lock-modify-unlock solution, svn follows copy-modify-merge allowing users to modify the same piece of code concurrently. 
The problem with the lock-modify-unlock model is that it's a bit restrictive and often becomes a roadblock for users:

Locking may cause administrative problems. Sometimes user A will lock a file and then forget about it. Meanwhile, because B is still waiting to edit the file, his hands are tied. And then A goes on vacation. Now B has to get an administrator to release A's lock. The situation ends up causing a lot of unnecessary delay and wasted time.

Locking may cause unnecessary serialization. What if A is editing the beginning of a text file, and B simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.

Locking may create a false sense of security. Suppose A locks and edits file f1, while Sally simultaneously locks and edits file f2. But what if f1 and f2 depend on one another, and the changes made to each are semantically incompatible? Suddenly f1 and f2 don't work together anymore. The locking system was powerless to prevent the problem—yet it somehow provided a false sense of security. It's easy for A and B to imagine that by locking files, each is beginning a safe, insulated task, and thus they need not bother discussing their incompatible changes early on. Locking often becomes a substitute for real communication. <REVISIT>

==Use of version control in other areas ==

Now a days, many document editing softwares have adopted version control. Wikis, GoogleDoc, Microsoft Office and OpenOffice.org suite are some example softwares that can save previous document editing history.

==Other considerations==

Most open source softwares have [http://linuxmafia.com/faq/Apps/vcs.html distributions for Linux] OS. In most open source cases, Linux and windows versions are released concurrently.
Many VCS' have plugins for common IDEs like Eclipse, Visual Studio, Oracle JDeveloper etc. NetBeans IDE and Xcode has integrated version control support.

==References==

1. [http://subversion.apache.org/news.html#news-20100217. Apache Software Foundation Announcements, "Subversion becomes Apache Subversion".(2010-02-17) Accessed:September 2010 ]

2. [http://svnbook.red-bean.com/ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. "Version Control with Subversion", an O'Reilly book available online. Accessed:September 2010]

3. [http://shop.oreilly.com/product/9781565921177.do Don Bolinger, Tan Bronson: Applying RCS and SCCS. O'Reilly Media. ISBN:978-1-56592-117-7]

4. [http://www.ericsink.com/scm/source_control.html Eric Sink: A collection of articles on source control and best practices, Accessed:September 2010]

5. [http://basepath.com/aup/talks/SCCS-Slideshow.pdf M. J. Rochkind: The Source Code Control System.] In IEEE Transactions on Software Engineering SE-1:4 (Dec. 1975), pages 364–370.

6. [http://onlinelibrary.wiley.com/doi/10.1002/bltj.2039/pdf Martin, Robert L. (2002). "Software configuration management for the 21st century". Bell Labs technical journal, Volume 2, Issue 1, page- 154.]

7. Mike Mason; Pragmatic Version Control Using Subversion; Pragmatic Bookshelf; ISBN 0-9745140-6-3 (1st edition, paperback, 2005)

8. [http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Noah Gift,Adam Shand: Introduction to distributed version control systems (compare how to use Bazaar, Mercurial, and Git) (Apr 2009), IBM Technical Library, Accessed:September 2010 ]

9.[http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150703/abstract Walter F. Tichy; Rcs - a system for version control; In Software: Practice and Experience. Volume 15, Issue 7,(July 1985) pages 637–654 ]

==See also==
[http://en.wikipedia.org/wiki/Revision_control Wikipedia: Revision control]

[http://en.wikipedia.org/wiki/List_of_revision_control_software Wikipedia: List of revision control software]

[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Wikipedia: Detail comparison of revision control softwares]

[http://www.nongnu.org/cvs/ CVS webpage]

[http://www.cs.vu.nl/~dick/ Dick Grune's website on CVS history]

[http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source The original usenet post on CVS] archived at google groups.

[http://linuxmafia.com/faq/Apps/vcs.html Linux availability of various version control softwares]