Untitled Document
Design Patterns Illustrated
A concise overview of all 23 “classical” design patterns:
By: Herman Peeren /
Illustrations: Nelleke Verhoeff, / Yepr company
Page 1
Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
|
Design Patterns are recipes for solutions to common problems with Object Oriented
Programming (OOP). The term“Design Patterns” is being used in computer science since the edition of the book “Design Patterns: Elements of
Reusable Object-Oriented Software” in 1994. This book was written by 4 persons (Gamma et al.); that group is often
shortly refered to as the “Gang of Four” (GOF). The 23 disign patterns that are described in their book form the basis
for later work in that direction. In this article we present drawings we have made to illustrate the principles behind the
patterns in the GOF-book.Design Patterns can be used to design software, to communicate about that design and to refactor code afterwards,
for instance after finding repetition or other “code smells”. The goal is that once code is written, it will not have to be
changed. Many used principles are:
• encapsulate what varies (make classes open for extension and closed for modification)
• one responsibility (task) per class
• program against an interface, not against a concrete implementation
• prefer composition over inheritance (“HAS A” is more flexible than “IS A”)
• loosely coupling: making it modular with “black boxes”
The 23 “classical” GOF-patternscreational patterns:
patterns that abstract the initiation of objects
Factory Method
An interface for the creation of objects. Concrete subclasses, that implement that interface, decide which classes to
instantiate. |
 |
It is a factory for objects, that is being used in stead of directly calling the constructor of an object. By using an abstract
form of the objects that are to be instantiated (an interface or abstract class), code can be made more generic for
variations of objects (polymorphism).
For instance: declare a TShape and instantiate a TRectangle or a TCircle;
you
can then apply the more generic method Area() in the code and don’t have to modify that when implementing another
shape.
For instance: when you use a database connection, but want to keep the code independent from the kind of database.
The artwork in this article is provided under the Creative Commons Public License for noncommercial use. http://creativecommons.org/licenses/by-nc/3.0/legalcode |
Next |
|

New Lazarus-support website http://www.lazarussupport.com/
|
 |
An English version of the recently published (German) Lazarus book is now going to be translated.
We'll keep you informed about the work of the authors: Michael Van Canneyt, Mattias Gaertner, Swen Heinig, Felipe Monteiro de Carvalho and Inoussa Ouedraogo..

|
| We are pleased to announce the
release of DeZign for
Databases V6.2,
an update to our easy-to-use
database design tool.
DeZign for Databases V6.2 introduces schema/owner mapping, a new feature that enables you to map schema names in your data model to schema names in your database when comparing (and synchronizing) your model with your database. The new version also adds support for case insensitive comparison of model and database. Version 6.2 offers several other enhancements, such as a improved generation of PDF reports and improved model-to-database synchro-nization scripts.
Visit our website for a complete list of changes: |
|
Short Privacy Declaration:
Blaise Pascal Magazine will not
provide
or sell any personal information
about
subscribers to any other party,
except in
the case of a verified judicial
request from
a recognised Government
Agency or to its
own related
organisations.
Click here for full details of our
Privacy Statement |
|