So I have read super famous book by the ‘Gang of Four’.
“Design Patterns: Elements of Reusable Object-Oriented Software”
The book was, and is, immensely influential in software development world. I believe, it was Gamma himself, who coined the word “Software Pattern”, although he wasn’t the one who invented the concept of patterns outside of textile industry, it was Alexander, who first applied the pattern terminology to real civil engineering, to making buildings.
This book was originally recommended to me by my former University teacher, although I believe, at that time, in 2011, not a single person actually ever opened even a single page of that book. Probably that happened because the context of the recommendation was learning UML, and because none of us understood what UML even was, we didn’t see any reason to learn it.
Meanwhile, as I now I am endorsed to learn graphical representation languages as in an attempt to promote the usage of the so-called Model-Based Systems Architecture, I have actually decided to find at least some way to make sense out of the UML thing. All the better that I actually am the person responsible for the architecture of the software system we develop.
So having read the book left me in a sense of slight confusion.
On the one hand, describing software patterns (with heavy commenting in a natural language), is actually, one of that few places where UML makes sense in its own right (not as a part of some general larger documentation system). Also, speaking of the software architecture in terms of patterns seems to really be the correct way of talking about large software (and not necessarily software) systems.
On the other hand, I did have a feeling that Gamma is, maybe, not really that much of a great programmer, as the whole way of expressing things in the book left me in a feeling of unease, and the code proposed there, although not bad, was always reminding me of a sort of a “pay per line” rewarding paradigm, used in some less technologically advanced companies.
Still, this is mostly emotional, not technological.
Right in the first chapter, Gamma admits that patterns may look very differently from one programming language to another. In particular, I can refer the reader to the essay by Norvig http://norvig.com/design-patterns/design-patterns.pdf , on how lots of these patterns are dramatically simpler in languages that are less strict towards type safety. On the other hand, perhaps, thinking in terms of patterns is usefult even with respect to dynamic languages, as although implementing them may be easy, still, thinking of them in a paradigmatic way is a different story. I even have a conjecture, that patterns ARE a way in which programming language syntax should be developed, as as language essentially is a way of transforming semantics to syntax.
Practically, many parts of languages actually share their names with patterns. Examples may be the ‘Template Method’ in C++ (which appeared actually earlier than the concept of a pattern), ‘Decorator’ in Python (which is a direct implementation), or a lot of factory classes in the Java standard library (an indirect implementation).
Still, the amount of ready to use patterns in the book is low, and most of them are relatively straightforward. Although the authors defend themselves by saying that they had only laid the foundation of the domain, not described it extensively, the development of the field doesn’t seem to be going in a too steady way, and the whole field, just as with the UML, resembles something existing for the sake of existing, not for the sake of making someone’s life much of a better place.
Maybe this is justified by the fact that the amount of programmers is high, and the amount of software architects is low, and especially low is the amount of software architects developing huge projects, and even lower is the amount of software architects who understand the need of consistently describing their designing approach. As a result, all the knowledge is being generated by ivory-tower academics, who don’t often have that much exposure to really huge projects.
Anyway, for those who got interested in how to describe in the most general terms “what is conceptually the stuff we are doing”, I think that Gamma’s book is a good place to start.
One of the greatest benefits for me personally was the subconsciously developed skill of only reading the substantial part of the text, while skipping the verbose details (and the book is very verbose).
The structure of every described pattern roughly follows the Alexander’s pattern language, and includes the essential description, the collaborations, the implementation details, and so on.
For those who are interested in software architecture more, there is a huge 5-volume series, called POSA: Pattern-Oriented Software Architecture, and there is also a large survey of open-source software (obviously, because it’s the only kind you can study yourself) http://aosabook.org
Do I recommend reading the book? Well, yes, but rather more of read through the first chapter (which is a case study), rather than the actual catalogue. That’s enough to grasp the language, but doesn’t bury you in the detail.