Blog: Should Developers Know Design Patterns?

Propel, like other ORMs, implements a lot of common Design Patterns. Active Record, Unit Of Work, Identity Map, Lazy Load, Foreign Key Mapping, Concrete Table Inheritance, Query Object, to name a few, all appear in Propel. The very idea of an Object-Relational Mapping is indeed a Design Pattern itself. 

Implementing a library like Propel implies that the library developers should be aware of existing solutions to the problems they are solving. They should also be aware of the common patterns in these solutions. Nobody wants to reinvent the wheel, or to spend time implementing a feature, just to have some random guy tell you one day: "Oh, but you've just reinvented ___". That's why the Propel developers spend quite some time reading CS books, watching the development of other ORMs, in PHP and in other languages, to learn from the efforts of others.

But the point of this post is to ask whether the developers of web applications using Propel should know about these design patterns, too. In other terms, should the Propel documentation assume that these concepts are well known, or explain the use of Propel without spending time explaining the reasons of a particular implementation?

 

On the one side, the manager inside me may think that a developer who is not aware of Design Patterns, and tries to solve every problem by himself, is not a good developer. Such a developer should not be considered for the projects I'm dealing with - it's too risky. I may end up with a feature developed in a week, while an applied Design Pattern would have given a better solution in only two days. Also, the feature developed using a naive implementation would probably be harder to maintain and to explain to another developer, while a solution following a Design Pattern would benefit from the general knowledge of this pattern.

On the other side, a library that guides developers into a particular type of coding might be enough to keep a good quality level. A Domain Model built with Propel implicitly contains all these common solutions to well-known problems. Even if the developer is not aware of Design Patterns, she applies them anyway. I have seen many inexperienced developers write code with Propel, and produce implementations of rather good quality. I remember asking one of them why he used Nested Sets rather than Materialized Path for a particular feature. He answered that he just needed a working tree implementation, and that it was apparently the best one provided by the library. He didn't know anything about the Nested Sets algorithmic. He had never heard of the Gang of Four or Martin Fowler or Eric Evans, but his lack of knowledge was compensated by a careful observance of the usage documentation.

Take this question to another domain: Do you have to know the theory of the reciprocating engine to drive a car? Do you need to know Chemistry to cook noodle soup? Should you learn Mathematical Finance prior to investing in the stock exchange? It's always better if you do, but you don't actually have to. And advocating that the theoretical knowledge is a requirement to a good usage of a library is just a way to drive potential users away from the library. 

Even better: by applying design patterns unconsciously, a developer actually learns them. If a library can allow the manipulation of such patterns even to non-expert developers, then the library will probably improve the developers' development skills.

So targeting people with no prior knowledge of Design Patterns opens a library to a broader audience, and educates this audience. This implies working more on the documentation to make it more accessible, but this effort is necessary anyway. The documentation should be more directive on the usage description, and less verbose on the implementation choice. Design Pattern names should probably be banned from the user documentation, to make it less intimidating. 

Somehow, this idea draws the limit between a library and a framework. You have to know the concepts to use a library; you just need to understand the usage to develop with a framework.

Propel bets that you don't need to know the theory behind the ORM to be comfortable with it. Propel provides improved productivity and better code quality to all developers, including inexperienced ones. Don't be afraid by the powerful engine; the driver's license is easy to get.