Session 2

As we continue with each session we will add to our existing knowledge set. We will call it "Bag".

So the "Patterns Bag" has the following collection now
- Factory (Creational)
- Strategy(Behavioral)
- Decorator(Structural)

The "OO Bag" has the following collection now
- SRP (Single Responsibility Principle)
- LSP (Liskov's Substitution Principle)
- OCP (Open Close Principle)
- ISP (Interface-Segregation Principle)
- High Cohesion (GRASP - General Responsibility Assignment Software Patterns)


END OBJECTIVE - To fill these bags to maximum extent as possible and to add as many bags as possible :)

Following is the summary of todays session:

OO Principles [Application Design Skill]
- SRP (Single Responsibility Principle)
A class should have only one reason for change.

- OCP (Open Close Principle)
Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification.
Look at open soruce projects like dotnetnuke, enterprise library etc., they wisely follow these principles.
Generally this means following something similar to strategy/template pattern or take the provider model example.

- ISP (interface-Segregation Principle)
Clients should not be forced to depend on methods that they do not use.
Very much related to "High Cohesion GRASP Pattern" - how stringly related and focussed the responsibilities of an object are.

- Many client specific interfaces are better than one general purpose interface
- The dependency of once class to another one should depend on the smalest possible interface
- Make fine grained interfaces that are client specific
- Clients should not be forced to depend upon interfaces that they don't use. THe principle deals with the disadvantages of fat interfaces. Fat interfaces are not
cohesive. In other words the interfaces of classes should be broken into groups of member functions.

- LSP (Liskov Substitution Principle)
Subtypes must be substitutable for their base types.
This principle wants you to think clearly about the expected behavior and expectations of a class before you derive new classes from it.
It could turn out that when subtypes are substituted for a parent, you may get unexpected results.

This helps us avoid messy class hierarchies.

Design Pattern:
Decorator (Structural)
- Attach additional responsibility to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Application of Decorator pattern in .net framework.
---------------------------------------------------------------------------
System.IO.Stream class
- Given any instance of Stream you can add the capability for buffered access by wrapping it in a BufferedStream, without changing the interface to the data. Sicne you are just composing objects, this can be done at runtime, rather than using a technique like inheritance, which is a compile-time decision. The core functionalities is defined either by an interface or by an abstract class (like Stream) from which all the Decorators derive. The Decorators themselves implement (or override) the methods in the interface (or base class) to provide the extra functionality.
BufferedStream, fo e.g., overrided Read to read from a buffer fed by the wrapped Stream, instead of reading from that Stream directly.