I wish I had one book of this type when I started learning design patterns back in the year 2000. Here by patterns I am referring to standard Gang of Four (GOF) design patterns in the book by Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Resuable Object-oriented Software. England: Pearson Education Limited, 1995.
Even today, despite there being some good online materials and other books on this subject, I still often find this subject being handled in a way which leaves much room for improvements. Most treatments suffer in one way or the other. In some treatments, the reader has to learn a new domain or has to learn a new API, while in others, the basic steps are missing or the conceptual essence is hard to decipher. The result is that in most cases new readers has to refer to more than one treatment to be able to gain sufficient understanding. In general, thereafter the reader often has a conceptual view of the pattern, however, unable to apply the pattern succinctly with a few lines of code and in the domain they are dealing with. So there exists a gap between the understanding and the ability to translate that into development. This book is written with the intention to bridge this gap.
The primary aim of this book is to help the reader understand the thought process behind design patterns so that the reader can easily apply the pattern for the problem the at hand. This book is written mostly as a dialog, as a list of questions and their answers. The reason for this is to use the questions as a guiding force towards creating a structured thought pattern which then can be applied to any scenario. For this reason, a lot of care and thought have been given to explain each design pattern using very basic constructs (only) such as class, interface etc. and not using any real world examples, as far as possible, hence, this is domain agnostic. The reason for this is because; often the examples narrow the situation and essence of the cases where the design pattern can be applied. Examples (as used traditionally) often introduces noise in the understanding of the design pattern. A core objective of the book is to remove the noise / unwanted information as far as possible from the signal. The purpose is to convey some information which is readily usable. The information may not be valid in every imaginable scenario, be very precise or have a rigorous theoretical background, or be unbiased.
To demonstrate this by an example let us start with our first question.
What is a design pattern?
It is a familiar way of designing!
A traditional definition would be much longer than this and comprehensive. This definition, however, tries to capture the essence of the question. It also reflects the way in which design patterns are discussed within the book. The above answer is not comprehensive as it does not deal with all the facets of design pattern or defines the field of application (software or embroidery?), it does not seem professional in the sense that all professional definition will have more content; if this was being asked in an interview, the candidate may be rejected as having less knowledge, it does not have a theoretical grounding as it does not reference a paper in the bibliography section; and it may not be valid in every imaginable scenario as it was never meant to be. While it may not be these, however, it is a small piece of information which is readily usable, succinct and also serves to show you how we shall be addressing this topic in this book.
What is not there in this book?
The following are not there in this edition.
1. Use of UMLTM diagrams to explain the design pattern. The intention is to make the understanding so clear that the reader can put together the required UML diagram. The UML diagrams on their own seldom conveys the whole picture and almost invariably requires the use of explanation, in which case the diagrams becomes superficial and/or deducible from the explanation.
2. Code fragments – The intention is to outline the steps in such a lucid way that the reader can easily implement the pattern in the required domain. Incorporating the code fragments in the book also makes it quite large and also the code with the book is not maintainable. All the codes are there in the GitHub for free use and the link is provided in each chapter.
What is there in this book?
When I first learned about design patterns (2000), I was tempted to use them, however, was faced with a lack of material that laid the few basic steps that I need to take to incorporate the pattern. That is the first motivation behind writing this book. This book intends to achieve the following
1. Experience the thought process - To take the user through the thought process behind each pattern, so that the reader can start applying this not only in the context of patterns but also in programming as a whole.
2. Domain Agnostic treatment of patterns – Achieving this was the hardest part of the book. This book explains the design pattern without using real world examples as much as possible. It does not use any specific domain and hence domain independent. This is because often the reader is often stuck with those specific examples to explain the design pattern or use them (an on/off button, for example, in the case of a command pattern). This book uses the basic constructs such as class, object and interface to explain the pattern. The aim is to enable the reader to apply the pattern in as broader context as possible. There are exceptions like for interpreter pattern where the challenge is in the context
3. Deduction of UML diagrams - Once this understanding is achieved the reader can themselves draw up the required UML diagram for the pattern.
4. Basic reference implementations - Finally, each chapter gives the few basic steps to implement the pattern. This can serve as the basic reference implementation. It is not intended that the steps will be correct in all extreme situations. For example, it is not the aim of this book to write a Singleton that will remain so in a clustered JVM.
Who is this book for?
For all fellow developers, who at least once, could not convince others that proper development takes time. This book is intended for the beginner in mind, however, suitable for others as well. The examples are primarily in Java.
The style followed in this book?
A one to one conversational style is used as if I were to show you in person. Further, what I am trying to do here is to give you the thought process that leads to the correct steps rather than the steps. The thought process is the main knowledge for you to take from this book. Once you understand the thought process, the steps will automatically be visible. However, if there is a manager standing beside your computer and breathing down your neck (humor intended), feel free to just do the steps.
Why another book?
There are about eight to ten books on design pattern; it is not a hot topic. Most of the books suffer one or the other problem. Some are very academic. Some assume that you have to know Java Swing API before you use design patterns; so you face another level of problem when you cannot distinguish which is noise and which is signal, for example, you may wonder if the code you are viewing is required due to inclusion of Java Swing API or if it is required by the pattern. Some have examples of creating a compiler which most of us do not do or perhaps have an example like a switching a light or a fan which does not fit your context. Most books are abundant with jargon so much that the meaning gets lost. Finally, I had always the frustration of reading ten different articles about a pattern and then boiling down to find out the residue. This residue is the basic steps outlined in this book, the attempt to capture its essence in practice.
Assumptions and Difference
The book supposes that the reader is familiar in Java. All the examples are in Java. The book has few UML examples where required. The book supposes the reader is familiar with creating UML diagrams. Also, as explained earlier, each pattern is explained without the use of any specific examples so that the information is in its most native state so that it can be made to fit in real solution with maximum benefit. The reader is also assumed to have an internet connection so as to be able to download the code from the internet.
When is design patterns studied in general?
In reality, design patterns are perhaps more studied when one has got an interview. I have been in the IT field for over a decade and have delved into many codes written by many. Quite often, I have found that there is little or no patterns are used in the code. Adoption of a visitor pattern or a memento pattern is a rarity. Singleton is the most commonly used pattern. Patterns are likely to be found in code written by experienced people. This, however, represents only 20 % of the code that is out there. Rest 80 % is written by programmers having varying degree of experience. In there, there is no easy way to understand the absence or presence of a pattern unless the pattern name is used. In many cases, I have found either there is an overuse or under use of patterns.
Do we need to adopt a pattern?
Of course yes, perhaps for an interview. While that may be a short term goal, there is indeed much long term goal and firstly it is to make your life easier in your job of (say) a developer and secondly to make others life easier who shall maintain the code.
Why so much less adoption of patterns?
A typical situation is you have to get the code done by the same day. You are perhaps working half-heartedly and do not even bother if it solves the end problem, all you care is the code has to pass some tests and produce the intended output. In this mode, out flies all modularity, reusability, and other –abilities. And even if you implemented these, that may not fetch you any extra marks or benefit in your appraisal[1].
So do you not implement any patterns? You try to, for you think that there should be a right way and you less care about what you have been instructed to do and only care about finding the best representation of the problem. Here comes the second problem. Assume that you are at least to some extent knowledgeable about design patterns. You know somebody must have solved this earlier, you also have an inkling as to which design pattern can be used, and still you are unable to implement that in the code for you know not yet, what are the basic ten steps to get a design pattern implemented.
Supporting content and correspondence
The code is available on GitHub under MIT license at
https://github.com/chirey/designPatternsThoughtsCode/tree/master/src
The above URL is referred using the expression [project_root] from within the book.
A homepage for the book is maintained at
http://www.designpatternsthoughts.blogspot.com.
The homepage has additional materials related to this book.
Trademark Notice
Product or corporate names in general are trademarks and are used only for identification and explanation, without any intent to infringe.
Mainak Biswas
Email – authormainak@gmail.com
London, Feb 2016
[1]I wish there was a company where the appraisal matrix had a metric that was partly based on a feed from a design pattern recognition system which iterates over the code that you put in the repository.
No comments:
Post a Comment