The agenda for Session 4 is to understand the following Creational Patterns
- Abstract Factory
- Singleton
The idea is to get a working knowledge of the above two patterns and see how we could apply it in real life cases, what problem it solves and how it help keep our design simple and extensible and also elegant.
Stay tuned....
Thursday 27 December 2007
Wednesday 26 December 2007
Session 3
In this Session we will be discussing class diagrams. We will just scratch the surface.
Class diagrams are very important element in the design of any software। They serve as a common mechanism to understand the elements and it's
structure along with it's relationship to other elements.
Also, understanding class diagrams will allow us to represent almost all the design patterns in a standard way.
Summary of 3rd Session - {UML - CLass Diagram}
In this session we learnt about UML class diagrams and some basic notation that goes along with class diagram.
We learnt about tags {} (those cute curly braces which adds meaning to members of class).
We talked about Stereotype. Stereotype can be used as an alias. These are represented by not so cute double angled braces.<<>>
For e.g. to represent an interface the following stereotype can be used.
<>.
We have reiterated the importance of loose coupling and high cohesion.
We have created yet another bag of knowledge i.e. "The UML Bag" and we have added the following in this bag
- Class diagram
Incorrect use of relationships are always dangerous and you have to be careful in dealing with them :).
We have slightly touched upon the following types of realtionships while drawing class diagrams
- Association
- Generalization
- Realization
- Dependency
We will cover these subtle things in the future sessions.
You comments/suggestions are welcome.
Class diagrams are very important element in the design of any software। They serve as a common mechanism to understand the elements and it's
structure along with it's relationship to other elements.
Also, understanding class diagrams will allow us to represent almost all the design patterns in a standard way.
Summary of 3rd Session - {UML - CLass Diagram}
In this session we learnt about UML class diagrams and some basic notation that goes along with class diagram.
We learnt about tags {} (those cute curly braces which adds meaning to members of class).
We talked about Stereotype. Stereotype can be used as an alias. These are represented by not so cute double angled braces.<<>>
For e.g. to represent an interface the following stereotype can be used.
<
We have reiterated the importance of loose coupling and high cohesion.
We have created yet another bag of knowledge i.e. "The UML Bag" and we have added the following in this bag
- Class diagram
Incorrect use of relationships are always dangerous and you have to be careful in dealing with them :).
We have slightly touched upon the following types of realtionships while drawing class diagrams
- Association
- Generalization
- Realization
- Dependency
We will cover these subtle things in the future sessions.
You comments/suggestions are welcome.
Wednesday 19 December 2007
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.
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.
Session 1
Following is the summary and some applications of today's tech nirvana session.
Design Patterns [Application Design Skill]
- Factory [Creational] - Abstracts object creation
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
- Strategy[Behavioral]
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it
Applications of Factory pattern in .NET Framework
(1) System.Convert class
The System.Convert class is a good example of factory pattern.
For e.g. Convert.ToBoolean(int) - returns new Boolean set to true if the int was non-zero, false otherwise.
(2) System.Net.WebRequest
Similarly the System.Net.WebRequest class also is an excellent example of factory pattern.
- Pass in the URI to the Create method and it creates respective subclass i.e. HttpWebRequest, FtpWebRequest or FileWebRequest.
Applications of Strategy pattern in .NET Framework
(1) Array and ArrayList provides capability to sort object. By default they use QuickSort algorithm. The Sort method will use the IComparable implementation for each
element to handle the comparisons necessary for sorrting. To change the sortig strategy use the overload of Sort that takes an IComparer as a parameter.
ICompararer.Compare is then used for the comparisons.
The new List makes heavy use of the strategy pattern. In addition to the pdated Sort method, the find-related methods, BinarySearch and others all take
parameters that allow parts of the respective algorithms to vary based on the needs of the caller. The use of Predicate delegate in the FindAll method lets the
caller use any method as a filter for the List so long as it takes the appropriate object type and returns a boolean.
Terms introduced:
- OCP (Open Closed Principle).
Classes should be open for extension but closed for modification.
"Hope this nicely conjures up everything we discussed."
Design Patterns [Application Design Skill]
- Factory [Creational] - Abstracts object creation
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
- Strategy[Behavioral]
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it
Applications of Factory pattern in .NET Framework
(1) System.Convert class
The System.Convert class is a good example of factory pattern.
For e.g. Convert.ToBoolean(int) - returns new Boolean set to true if the int was non-zero, false otherwise.
(2) System.Net.WebRequest
Similarly the System.Net.WebRequest class also is an excellent example of factory pattern.
- Pass in the URI to the Create method and it creates respective subclass i.e. HttpWebRequest, FtpWebRequest or FileWebRequest.
Applications of Strategy pattern in .NET Framework
(1) Array and ArrayList provides capability to sort object. By default they use QuickSort algorithm. The Sort method will use the IComparable implementation for each
element to handle the comparisons necessary for sorrting. To change the sortig strategy use the overload of Sort that takes an IComparer as a parameter.
ICompararer.Compare is then used for the comparisons.
The new List
parameters that allow parts of the respective algorithms to vary based on the needs of the caller. The use of Predicate
caller use any method as a filter for the List
Terms introduced:
- OCP (Open Closed Principle).
Classes should be open for extension but closed for modification.
"Hope this nicely conjures up everything we discussed."
An Idea
Every thing begins with an idea. We all have a desire to learn and be informed. And we all have some common problems like lack of time, proper guidance, lack of information which keeps us from pursuing our desire.
The "30 Minutes to Tech Nirvana" was born out of the same desire. This concept is started with the help of my collegues to satisy the above desire. We spend 30 minutes a day to share our knowledge and experience with the team members. This helps us to understand certain things which we generally take for granted.
What follows rest is the summary of these sessions. This will serve as a single point of reference.
Our high lever agenda is to master these technologies
The following is the high level finalized agends [I finalized it :)]
Application Design/Architecture skills
- OOAD/ Design Patterns
- Unit Test
- Agile Methodology [Extreme Programming, Scrum]
Technology Skills
--.net 3 + [Technology Skills]
- ASP.net MVC
- Linq, Dlinq, Xlinq
- ADO.net Entity Framework
- AJAX
- WPF, Silverlight
Let's see, where this exercise leads to. May be we all may learn a lesson or two out of this little experimentation..
The "30 Minutes to Tech Nirvana" was born out of the same desire. This concept is started with the help of my collegues to satisy the above desire. We spend 30 minutes a day to share our knowledge and experience with the team members. This helps us to understand certain things which we generally take for granted.
What follows rest is the summary of these sessions. This will serve as a single point of reference.
Our high lever agenda is to master these technologies
The following is the high level finalized agends [I finalized it :)]
Application Design/Architecture skills
- OOAD/ Design Patterns
- Unit Test
- Agile Methodology [Extreme Programming, Scrum]
Technology Skills
--.net 3 + [Technology Skills]
- ASP.net MVC
- Linq, Dlinq, Xlinq
- ADO.net Entity Framework
- AJAX
- WPF, Silverlight
Let's see, where this exercise leads to. May be we all may learn a lesson or two out of this little experimentation..
Subscribe to:
Posts (Atom)
Posts
