Essential patterns books for today object-oriented developers

13 January 200929 September 2010 admin 2 Comments

The more patterns developers know, the most efficient they become within a team: it only takes one or two words (the pattern name) to communicate a design decision or proposal, instead of 10 mn of explanations. Communication also gets much more accurate and to-the-point (or less fuzzy).

Because patterns often form a pattern language, not only they offer a standard vocabulary but they also help structuring the mind by their relationships: patterns can be related as exclusive alternatives, or rather often-go-together, which is useful.

Patterns are not always supposed to be “tricks” to learn, or extra complication to introduce to a design; indeed even obvious and uninteresting pattern are worth reading in books, just for the social advantage of being able to reference them. Going further, sometime you can just go to the book to find out which is the pattern that you just did without knowing its name…

1. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) by Erich Gamma et al.


	The most essential book, a definitive must-have. Every experienced software developer must know these 23 design patterns.

2. Analysis Patterns: Reusable Object Models (Addison-Wesley Object Technology Series) by Martin Fowler


	The essential complement to the GoF, to extend the benefits of patterns from design to analysis (closer to the problem to solve in the domain). Each pattern will not necessarily teach you a new solution, but will always give you have a standard name for each solution, which is already worth the book.

3. Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans


	A book that can change the way you deal with software. Considering the domain as the main driver of the design is so powerful an approach! Works best together with the analysis patterns.

4. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) by Martin Fowler


	Other analysis patterns to solve many technical problems, useful complement to Analysis Patterns.

5. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series) by Gregor Hohpe


	Very complete pattern language (both test and visual vocabulary) about messaging, will improve the communication within a team a lot, both in efficiency and in accuracy.

6. Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects by Douglas Schmidt


	Important book, more specialized toward optimized low-level problems (web servers…). often quoted. The other volumes are less relevant for today software development on modern languages or virtual machines.

7. Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML, 2nd Edition, Volume 1 by Mark Grand


	The book I discovered design patterns in, quite affordable, but some colleagues do not like it that much.

Disposable code generation works great !

29 March 20054 January 2009 admin

In a recent project I was asked to parse massive XML document from a third party provider. We had two problems: the xml document definition was very massive, with about 120 groups of different elements, leading to a total of around 1500 different elements to parse into java objects. The other problem was that our only documentation was a massive Word document that described the Xml format using plain English and some rather consistent tables.

Fortunatly the Word document was rather consistent. Each table had a title, and a list of attributes, with their name, type and a comment. Names were ugly UPPERCASENAMEALLTOGETHER. Titles contained a name, with the XML element name within parenthesises: OVERALCREDITSCORE (XYZ78).

We had chosen using Jibx tool to parse Xml (also to generate Xml in other parts of the application) for efficiency reasons, since it is really lightning fast, and very flexible to map any XML structure into Java structures. Jibx requires to write a custom XML mapping file, and obviously we also had to create the Java classes to map to.

The total amount of work was huge: with 120 groups of 12 XML elements to map into 120 Java classes of 12 fields each, wa had to create the 120 corresponding Java classes, and the mapping file with 1500 mapping instruction (from XML element to Java class attribute). I could not imagine doing this by hand, this is horrible work even for a trainee

So I copy-pasted the Word document into Excel to convert it into a coma-separated file, fixed the little inconsistencies, then wrote a rustic parser to extract the XML meta model, using some dumb rules such as: “if the cells 3 and 4 are empty then it is a value from the enumeration of possible values”, “if every cell is set then it is an element”… Even the parenthesises were of interest to tell the enclosing element name ! Relying on such stupid criteria seemed frightening, but it worked, and worked quite well !

Then using a simple Java metamodel (class, field, constants as enumerations) and some dedicated Visitors I generated the binding file, the DtD, the java model, a sample XML document to use for testing… in 2 seconds. The complete work including testing took 2 days; I was happy the project manager trusted me on this, he could have decided it would not work and refused me to do it…

I havent told you how I converted the ugly UPPERCASENAMEALLTOGETHER into correct Java naming conventions; using some short business-dedicated dictionary of words, say {UPPER, CASE, NAME, TOGETHER ,ALL…}, a function tries to recognise the words from the dictionary inside the ugly names in order to split them into relevant parts for further camel case naming conversion. It did not work ok 100% of the time, but after a few tries, just add or remove words to solve conflicts, it did the whole job automatically !

Such a disposable, dedicated code generator works great, I dont care I wont reuse it, as long as I get the work done quickly…

Note: the design is actually very common and reusable: an object model (Composite pattern), a parser (Builder pattern) and some code generators (Visitor pattern).

Initially published on Jroller on Tuesday March 29, 2005

UML is a too low level language

15 March 20054 January 2009 admin

I recently taught design pattern to 20 of my co-workers in a kind of training session, here are some thoughts I had while preparing this presentation…

In OO you usually end up with many classes, especially when you correctly use design patterns; each class is also generally very simple and rather short. Thus classes are now in OO the equivalent of the “if-then-else-for” instructions in structured programming: low-level language elements.

Unfortunatly, UML is essentially about class-level static description (class diagram), dynamic objects interactions (sequence, object diagram). Even more OO-independent part of UML such as state diagram is still at the class level, as typical implementation using the State pattern (GoF) implies using a class for each state.

What is the higher level above the class-level ? In my opinion, it is the (design) pattern level, for at least three reasons:
– granularity: a design pattern usually deals with more than one class, so it is a natural way to talk about several classes as only one entity;
– patterns language: patterns may be solutions to solve recurrent problems, sure, but they first of all define a common language to talk about the entire solutions in a standard, shared way;
– patterns intent: patterns are always motivated by an explicit intent; this intent is the real high-level need of the developer, whereas the solution that uses classes, methods overriding, methods delegation, methods callbacks… is nothing but the best known way to meet the intent using OO language.

UML support for patterns is quite minimal (dash lined and named bubbles with links to every participant in the pattern), and adds nearly no value compared to simple UML comments. If you know the patterns, and you do if you’re reading this to this line, I’d better tell you “this package contains adapters from the third party financial instruments tree to our custom financial instruments tree” than show you a diagram with 35 classes in a package and 35 classes in another package, 35 interfaces and 35 bubbles showing the pattern Adapter is applied 35 times respectively for each class, class and interface…

In the business design (some say analysis), the same is true. It’s shorter and more accurate to say the model follows the Contract pattern (Fowler), than to show the UML diagram. But on the other side, there is no formal language, visual or textual, other than plain English to describe patterns at their full level. At this level, packages would would be first-class entities, not just boxes that contains classes. Code generation could also go one step further, since if the machine knows about our intent, it could also provide the solution to our intent, maybe by implementing the correct pattern automatically, using the best implementation tradeoff automatically, but now I’m dreaming…

Initially published on Jroller on Tuesday March 15, 2005