Design Patterns I Hate

May 18, 2011


To be clear, I think Design Patterns have their place. When used properly, they can make our lives easier and our code better. When they're misused – "If the only tool you have is a hammer.." – then they can become the bane of our existence. Unfortunately, some Design Patterns seem more susceptible to this than others.

So maybe this is less "design patterns I hate" and more of "design patterns that have been abused beyond all sense of reason"… I'll let you decide.

First, we have Active Record. As the foundation of many of the MVC frameworks out there, this seems like an odd choice, but the explanation is simple. Somewhere along the way, people started pushing the idea of a row of the database as the Model. We mapped columns into properties, added some methods, and considered it complete. While that follows the OO principle of data encapsulation, it misses a key point in the definition of a Model:

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Source: Model-View-Controller from Wikipedia

The key point is simple. The Model describes the data based on the application domain, not based on the database structure. In fact, it says nothing about storage or persistence of any kind. The Model is an object that fully encapsulates one particular piece object and all of the business logic that goes with it. If it happens to map one-to-one with a database object, it's a useful coincidence, not a sign to combine the two.

Next, we have the Factory Pattern. A Factory Pattern is used when your code needs to figure out which type of class to instantiate at runtime. In concept, that's very powerful and when combined with other Object Oriented aspects – like uniform interfaces – you can build powerful structures that can be flexible and easily extensible. But – as we know – with great power comes responsibility.

A Factory has to make the decision on which class to instantiate. This decision can be as simple as an if/else but normally doesn't end there and becomes a switch/case statement. This in itself isn't bad, it's just more complex. Eventually, someone realizes that they have to load numerous common parameter, so they feed these parameters into the constructor. Since it's so easy to add parameters to a function, they add a few more. Somewhere along the line, some of the parameters conflict with one another and need additional validation and decision logic. At some point, someone realizes that passing in a configuration object would be easier, but often there are different types of configuration objects, so someone decides to build a Factory for that.

Lather, rinse, repeat.

With inappropriate use, we end up with a set of Factory Factories and layer upon layer of logic just to instantiate our classes.  BenjiSmith explains it in more painful detail here. It's somewhere between difficult and impossible to test every possible path.

And of course, the ever-hated Singleton. Somewhere along the line, we realized that global variables are bad. Of course, there are still some limited scenarios where they make sense, so we were faced with a problem. We needed something that looked like a global and acted like a global but wasn't really a global.

Enter the Singleton Pattern..

It is a simple pattern that makes sure there is only ever one and only one instance of itself. If you modify that instance, you're modifying it for anything and everything that might use it. This makes sense for resource-heavy objects like database connections but in practice, it's often just a global hiding out as OOP.

All of that said, I don't actually hate these Design Patterns. This particular patterns – and probably many others – have been misused and abused to the point of mangling what would otherwise be useful code. There are correct ways of applying these patterns and times to make use of them.. 

And no, not everything is a nail.

About Keith Casey

This should be something about myself. I've had suggestions that it should be "useful information" but I'm not sure about that.

View all posts by Keith Casey

9 Responses to “Design Patterns I Hate”

  1. maxpaine Says:

    Singleton is very powerful when known how and where to use it. Many problems came when you add singleton pattern to a class and then you realise that you’ll need more than one instance in some cases. And also this is not C – we don’t care a lot of the memory so, singleton should be rarely used, or very wisely.

  2. toma Says:

    I have disliked this pattern since I first laid eyes on it. Good example of a project using it is Cahaya where each model is inherited from Zend_Db_Table. Why someone would try to constrain a model to a table is beyond me.

    The up-and-comers are the ORM solutions with Doctrine2 poised to be the standard in the same way PHPUnit is the standard for unit testing. These provide an essentially pure active record model using Entities. The ORM and entities are accessed by the model layer to query data. It’s an important distinction to have this new service layer and I believe it’s the right way to develop new applications.

  3. tonymarston Says:

    I also hate ActiveRecord. In my own applications I have business/domain logic in one class (the Model) and all database access performed in a separate class (the Data Access Object, or DAO). As I have a separate DAO for each database engine (MySQL, PostgreSQL, Oracle and SQL Server) it also means that I can switch from one DBMS to another without having to change any Model.

    I never use the Factory pattern as I always know which class to use beforehand, so I don’t need any code to make the choice for me. Other programmers seem to use a factory for every object even though there is not a choice of classes.

    Your definition of the Singleton is not the one that I use. Your statement "makes sure there is only ever one and only one instance of itself" implies that each class must have its own singleton method, which strikes me as unecessary duplication. If you change "itself" to "any class" then you can create an abstract Singleton class with a single abstract getInstance method. You use it as follows:

    $object = singleton::getInstance("class");

    The singleton does its job, so what is there to hate about it?

  4. shayfalador Says:

    I totally agree with the main concept of your article.
    Wrong/over use of design pattern makes everything complex and inconsistent.

    I personally hate ORMs, they are way to heavy and big. I use NotORM which does about the same much easier.

    I believe that Singletons are required, for example my framework (which I use for small projects) uses Singleton for it’s main class, which makes everything much simpler.

    As for the Factory Pattern, I use a simple class for auto-loading class’ files (I use namespaces so locating them is easy), and I have a method for initializing models because models can be extended and still have the same name.

    Again, thank you for the article :)

  5. chimerafun Says:

    Doctrine is not a model class, it is an ORM which is one way to access the database and hence only part of the concept of a model.

  6. maxpaine Says:

    doctrine is one good example. in this orm you don’t have business logic separated from active records. Also you don’t have good service layer for records. You don’t have activeRowset, for example.

  7. gavin4p Says:

    Can you site some examples of active records being used as models?

    I would say most pattern abuse results from lack of time to refractor, rather than a misunderstanding of how patterns should be used.

  8. maxpaine Says:

    I really don’t like factory at all.. If they’re linked with some singleton features maybe.. but I think they’re more like vaunted.

    ActiveRecord is a MUST! And it’s more like service layer for the models for me not exactly the models itself. Cause the models use this layer which should be enough flexible. I think the best orm practice is Active record/records (Rowset class also) then facade and then Model class. For enterprise, ‘fcourse.
    Php culture and php devs are still young at the enterprise algorhitms and patterns. That’s why most of these are overused. It’s a matter only of time and enough reading of what you need.

  9. chimerafun Says:

    I’ve worked in several different languages and have recently taken a sabatical from PHP to work entirely in Objective-C. I find that PHP is the only culture where there is extreme bias over patterns, getters and setters, frameworks, and other best practices. Lessons that other language cultures learned years ago, PHP as a culture, is still disputing now.

    Singletons, while often used as a global repository of sorts enforce interface reducing the refactoring needed. Use a ton of them if you want, it’s better than letting your code access global variables directly.

    Active record, in most frameworks are a behavior of the ORM which is only part of the Model class.

    Factory patterns, meh… as long as their well documented, go ahead, it puts your decisions in one place.