Wednesday, May 19, 2010

The 3 biggies of D Patterns...

Continuing with where we left last time, the Design Patterns matterz, let us first peep into the broad classification of the Design Patterns. But before seeing through that, as I always used to say, take any practise in S/W engg., either be in OOPS or Design Patterns or MVC etc, they simply copycat the real life strategy. If you have 'felt' OOPS you will be one among the very few who accept with this... Ofcourse, I am one there!! ;-)

The reason for the above sentence being present in here is - anything, any object, any creature would suffer the following linear cycle stages - a) Creation, b) Growth, c) Behavior and ofcourse, d) Elimination (or Disposal). And know what? The categories of DP as well, follow these patterns strictly and the attire of them is as follows:
  1. Creational Pattern
  2. Structural Pattern.
  3. Behavioral Pattern
One of the great challanges of S/W architecture rite from the age of C till C# 4.0 would be on how do we take control over the object creation or how we gonna centralize the object creation. The reason for this is any real time project is good enough to be complicated and a complicated project might have good possibility of boasting to hold more than 500 functional / business classes!! And to flip them with the client code, wow, another 100+ classes we can easily target!

So once the client code starts accessing the Business classes by creating objects for each and every one of them... Just for an example, in a Teaching institution, the client code starts instantiating for the Student object, the Faculty Object, the Classroom object, Textbook object, Examination, Fees, Batches, and so on and on and on... The client code creating those objects, using the objects, closing the objects and disposing / releasing the objects - thus making itself too (we can even add a couple more o there) complicated to maintain and for the readability as well. Another well proven demerit in this approach is the client code is too heavily coupled with the Concrete classes. (A concrete class is one which can be instantiated directly).

So to solve these kind of issues, we have the saviour Creational Pattern. This category of patterns deals with Centralizing the object creation or to delegate the object creation.

Lets see Structural Pattern and Behavioral pattern in my next blog!!

0-0 (Love all) ;-)

No comments: