Firstly my apologies for replying so late.
I am always glad when people question the viability or practicality of technical matters. After all, why use something that does not add value. And indeed, design patterns do not necessarily add value in every scenario. I will briefly explain why one would want to study design patterns, why one would want to use design patterns, and why one would not want to use design patters.
As one embarks on ones quest to better understand design patterns, one will grow in terms of ones understanding, vigilance and maturity concerning the use of applying design patterns. One would typically find that developers that are new to design patterns will try and apply them everywhere they can. This is a mistake. The fact that you already question design patterns is good as I think that you will probably avoid this trap. As one learns to better understand design patterns, one will come to realise that design patterns emerge naturally from technical design that has applied good object oriented design principles. The idea of a design pattern simply allows one to give a good design facet (Concerned with actual use rather than theoretical possibilities) a name, a description and where this design may be applied and reused. After all, design patterns are tried and tested solutions to common and recurring problems. Therefore, when one is confronted with the task of designing a solution for a given context, one does not think "Cool, I know design patterns. Lets see how many of them I can use." This is very wrong. Instead one should think "Ok, based on the design principles that I know. How could I best apply those principles in order to solve the problem at hand." When one uses this approach, one will find that you come to identify things that look oddly familiar. These oddly familiar looking things are often the manifestation of a design pattern. As one grows in terms of ones understanding, one will come to realise that design patterns can be a very useful 'tool' in terms of refactoring code. Furthermore, imagine a design meeting. Maybe its just yourself and a colleague discussing possible technical designs. It is far easier to refer to design concepts by name than by trying to explain them in detail. So, if you say "Lets use a strategy for X." Your colleague, provided that he is also familiar with design patterns, will know exactly what you mean. A design pattern speaks a thousand words. And whats more, once one learns a pattern, one has increased ones understanding of design and more importantly what works and what does not work for a given pattern.
To summarise then.
What are the uses?
It is important to understand that each design pattern has a specific intent in terms of the problem or challenge it tries to solve. Therefore, in terms of the Facty Method for example, it's intent is to allow us developers to code against an interface or abstraction. Therefore, when creating objects, one can create an object without specifying the implementation class. This gives us the advantage of decoupling our instantiation from the implementation class. Therefore, one can add additional implementation classes and provided that they implement an interface or abstraction, we don't need to change our client code in terms of the instantiation code. What this all means is that the factory method allows one to avoid 'hard-coding' our instantiation. Factory methods and indeed Factories and Abstract Factories provide a point of indirection in terms of the classes we instantiate. Maybe one is creating classes based on a config file. One can change this to rather create classes based on what is in a database table. The client code doesn't care. All the client code cares about is that the method signature (method name and arguments) or the factory method remain the same.
In more general terms,
They are tried and tested technical design concepts for common and recurring design challenges. Therefore, in order to use them one must have solid design experience to understand where it is practical to use them.
They may be useful to a refactoring exercise. In other words, use them to improve existing designs. Design patterns are often found to effectively replace complex and convoluted code with a more succinct and easily understandable solution.
Use them to communicate design ideas without specifying the details (A pattern says a thousand words). They provide a lingua franca or common language in terms of communicating technical design concepts.
Use them to help improve maintainability and flexibility of ones code.
Use them to impress your peers ;-)
In terms of what design pattern is more efficient. One must understand that a design patterns is either suitable to a given scenario or not. The art comes in determining what is suitable and what is not. This comes with knowledge (in terms of the intent of various patterns) and experience. GOF patterns are for me, foundational in terms of understanding patterns. There are GOF patterns that are for the most part no longer applicable or relevant. This is because technology has moved on. It is still important however to be aware of where it all started by and large. GOF patterns primarily address solving design challenges at a development level. Many of the Fowler patterns do the same. Architectural or Enterprise design patterns tend to focus at higher abstractions of implementation. In other words, a typical Architecture design pattern would be the 'Three-Layered Architecture'. This simply means that one tries to separate ones implementation in terms of three focused areas or layers (Presentation, Business Logic, and Data Access). At the Enterprise level, one would start looking at Integration Patterns and understanding what patterns are useful in terms of connecting disparate systems in a hybrid environment.
Learning design patterns is a long road. One actually never stops learning as design patterns evolve and new ones emerge all the time. I encourage you to continually critically analyse the patterns that I will bring to this series.
If I could recommend a really good book to someone that is starting to learn about design patterns it is Head First Design Patterns (the examples are in java but it is the concepts that are important). Find more information here
http://www.oreilly.com/catalog/hfdesignpat/
Well, hope that helps. Feel free to ask any other questions.
|