Easy way to learn design patterns.

-
Reading any theorem ( in physics or mathematics) is a different game from solving thousands of tricky examples based on that theorem.

The same way we can read the standard definition of any design pattern and think we have understood it, but solving many real-life problems through that knowledge is a different ball game altogether. In other words, “learning theory is very different from solving many examples based on that theory.”

The very first rule of learning any design pattern is to solve (or think) many examples around it, as much you can, that will make you feel more confident on that particular topic.

There has to be some basic understanding of UML and OOPs before you go ahead. Just don’t jump into any design pattern which you have heard in some interview. Or through your seniors, or from any other source. Also, don’t go category by category, like I will finish all behavioral design patterns then I will read creational and then structural; it doesn’t work in that way.

Below mentioned list is one of the best sequence to learn patterns (it will not guarantee that you will understand all if you read in that sequence only, but it will build excellent understanding step by step, as it will start with subjects which are more common and easy to understand in software engineering field) –
  1. Basic understanding of OOPs (especially encapsulation, inheritance, polymorphism, abstraction, encapsulation violation, associations, and composition relationship).
  2. Basic understanding of UML (notably different relationships between classes).
  3. Basic understanding of SLDC (especially requirement gathering and conversion from requirement to high-level system modeling).
  4. Basic design principles (i.e., Black box, white box, system boundary, basic design parameters, functional requirements, non-functional requirements).
  5. Types of relationships in OOPS.
  6. MVC architecture.
  7. Proxy design pattern.
  8. Whole-part relationship, composite design pattern.
  9. Iterator design pattern.
  10. Front controller architectural pattern.
  11. Mediator design pattern.
  12. Observer design pattern.
  13. Chain of responsibility design pattern.
  14. Adapter design pattern.
  15. Command design pattern.
  16. State design pattern.
  17. Flyweight design pattern.
  18. Factory.
  19. Factory method design pattern.
  20. Abstract factory design pattern.
  21. Singleton design pattern. 
  22. Builder design pattern.
  23. Decorator proxy.
  24. Decorator design pattern.
  25. Visitor design pattern.
  26. Strategy design pattern.
  27. Template method design pattern.
  28. Bridge design pattern.
  29. Interpreter design pattern.
This list is for GoF design patterns.

Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post clean...
Read more

Factory method design pattern for beginners.

-
Image
Background - First, let me ask a simple question. Do you really think that "factory method design pattern comes because we had an issue with creating objects? Or it is only for creating objects? Or why we need a factory to create an object when we can create it through constructor? The answer is NO! Each class is capable of creating objects on its own. Through constructor (until and unless you have not put constructor in private).  Then why we need factory at all? Is there something like, without Factory method, I am not able to create my software? No, we can create objects without it, then why we are using it very extensively? Remember one thing, programming languages are very powerful . W e can build software without following any design principles. But then, it will be poor in some of these areas -  Maintainability. Extend-ability. Performance. Security. Robust. and many more... Developers have been developing...
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one...
Read more