For long I had thought of Design Patterns as some kind of new technology which would magically make your project state-of-the-art, something high level and too much complicated to understand. One fine day I made the courage of dwelling deep into it, searched some good links and got hold of a few books. The realization was startling and I looked like a fool to myself.
What I learned after going through some of the design patterns (java, j2ee etc)
After catching hold of a good Design Pattern book, I made my way to the various projects that I had ever worked on, surprisingly or not so surprisingly I found that there were many Patterns/practices which I had already been following (though I did identify some space for improvement(s) ).
Now as I sit down to share my experience and possibly encouragement to use Design Patterns for all those fearless programmers, all I plan to do is brief a highlight into it and provide some good references (links, book etc). I won’t be dwelling deep into the subject (I am still fearful) as much theory and details have been written by various experts.
The big question: What are design patterns and where do they come from?
“A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture, and has been adapted for various other disciplines, including computer science.”
An excerpt from wikipedia definition of Design Patternshttp://www.patterndepot.com/put/8/JavaPatterns.htm
Design patterns have their roots from Christopher Alexander, a civil engineer who talked about his experience in solving design issues related to planning buildings and towns. Later on the idea was published in form of book for software professionals "Design Patterns: Elements of Reusable Object-Oriented Software" 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides also known as GoF book or simply GoF.
Which technology/software do they belong to?
The answer is not technology or software but rather domains or fields. Design Patterns apply to all fields, domains be it Computer Science, Housing, teaching, Healthcare et al. These are object of reusable solutions based on past experience or success/failure, time-tested and applicable everywhere. Though due to my limited knowledge I will be focusing on the ones for Object Oriented Software Development.
A sneak peek:
Describing Design Patterns
Pattern Name: It is a bookmark to identify a particular design problem, related solution(s) and consequences of using it. It is a part of design vocabulary.
Intent: Describes what the pattern does, what is its intent, what particular design problem it addresses.
Also Known As: all aliases for the pattern
Motivation: Provides a solution to the problem with some examples and scenarios as to how it solves the problem. Gives a abstract description of the design patter.
Applicability: Situations and Scenarios where the pattern can be applied, bad designs that the pattern can help solve.
Structure: Diagramatic/Graphical representation of classes which depict the pattern.
Participants: Classes and objects that participate in the design pattern and their responsibilities.
Collaborations: How the classes and objects interact to perform their responsibilities.
Consequences: Benefits and trade-offs that come with using a pattern.
Implementation: What pitfalls, hints or techniques you should be aware of when implementing a particular pattern.
Mainly there are 23 patterns that have been described in the GoF book and subdivided into 3 categories wiz Creational, Structural and Behavioral.
Some well known Books on Design Patterns
Design Patterns – Elements of Reusable Object-Oriented Software
(Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides)
Pearson Education
HeadFirst Design Patterns
Applied JAVA Patterns
Stephen Stelting, Olav Maassen
Prentice Hall
Design Patterns Java Companion
James W. Cooper
Free Download
What I learned after going through some of the design patterns (java, j2ee etc)
It is right-in-your-face same old techniques to write effective, maintainable, scalable programs.
Something you probably have already been doing for ages and now have a catalog to see which pattern you are following in developing pragmatic software applications.
A collection of tested and proved solutions for most common design problems
Not a fad anymore… as most of the industry is ga-ga over Design Patterns it should now be a big part of your skill set.
After catching hold of a good Design Pattern book, I made my way to the various projects that I had ever worked on, surprisingly or not so surprisingly I found that there were many Patterns/practices which I had already been following (though I did identify some space for improvement(s) ).
Now as I sit down to share my experience and possibly encouragement to use Design Patterns for all those fearless programmers, all I plan to do is brief a highlight into it and provide some good references (links, book etc). I won’t be dwelling deep into the subject (I am still fearful) as much theory and details have been written by various experts.
The big question: What are design patterns and where do they come from?
“A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture, and has been adapted for various other disciplines, including computer science.”
An excerpt from wikipedia definition of Design Patternshttp://www.patterndepot.com/put/8/JavaPatterns.htm
Design patterns have their roots from Christopher Alexander, a civil engineer who talked about his experience in solving design issues related to planning buildings and towns. Later on the idea was published in form of book for software professionals "Design Patterns: Elements of Reusable Object-Oriented Software" 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides also known as GoF book or simply GoF.
Which technology/software do they belong to?
The answer is not technology or software but rather domains or fields. Design Patterns apply to all fields, domains be it Computer Science, Housing, teaching, Healthcare et al. These are object of reusable solutions based on past experience or success/failure, time-tested and applicable everywhere. Though due to my limited knowledge I will be focusing on the ones for Object Oriented Software Development.
A sneak peek:
Describing Design Patterns
Pattern Name: It is a bookmark to identify a particular design problem, related solution(s) and consequences of using it. It is a part of design vocabulary.
Intent: Describes what the pattern does, what is its intent, what particular design problem it addresses.
Also Known As: all aliases for the pattern
Motivation: Provides a solution to the problem with some examples and scenarios as to how it solves the problem. Gives a abstract description of the design patter.
Applicability: Situations and Scenarios where the pattern can be applied, bad designs that the pattern can help solve.
Structure: Diagramatic/Graphical representation of classes which depict the pattern.
Participants: Classes and objects that participate in the design pattern and their responsibilities.
Collaborations: How the classes and objects interact to perform their responsibilities.
Consequences: Benefits and trade-offs that come with using a pattern.
Implementation: What pitfalls, hints or techniques you should be aware of when implementing a particular pattern.
Mainly there are 23 patterns that have been described in the GoF book and subdivided into 3 categories wiz Creational, Structural and Behavioral.
Some well known Books on Design Patterns
Design Patterns – Elements of Reusable Object-Oriented Software
(Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides)
Pearson Education
HeadFirst Design Patterns
Applied JAVA Patterns
Stephen Stelting, Olav Maassen
Prentice Hall
Design Patterns Java Companion
James W. Cooper
Free Download
No comments:
Post a Comment