{
    "href": "/post/2017/09/19/before-not-beyond-design-patterns/",
    "relId": "2017/09/19/before-not-beyond-design-patterns",
    "title": "\"Before\" (not \"Beyond\") Design Patterns",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/php/",
            "relId": "php",
            "title": "PHP",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/programming/",
            "relId": "programming",
            "title": "Programming",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2017-09-19 12:00:51 UTC",
    "updated": [
        "2017-09-19 12:00:51 UTC"
    ],
    "html": "<p style=\"font-size: 80%;\">(N.b.: This has been languishing at the bottom of my blog heap for years; time to get it into the sun.)</p>\n<p>The 2013 article <a href=\"http://blog.ircmaxell.com/2013/09/beyond-design-patterns.html\">Beyond Design Patterns</a> takes the approach of reducing all design patterns to a single pattern: \u201cAbstracting Communication Between \u2018Components\u2019.\u201d The author concludes, in part:</p>\n<blockquote>\n<p>Instead of focusing on design patterns, I would suggest focusing on understanding how communication between objects and components happens. How does an object \u201cdecide\u201d what to do? How does it communicate that intention to other objects.</p>\n<p>Are design patterns useful? Absolutely. But I\u2019ll assert that once you understand OOP and object communication, the patterns will \u201cfall out\u201d of the code you write. They come from writing OOP.</p>\n</blockquote>\n<p>This strikes me as misapplied reduction. Sure, it\u2019s <em>true</em> that, at a lower level or scope, it might be fair to say that \u201cthe pattern is \u2018communication.\u2019\u201d But it is also true that, at a somewhat higher level or scope, communication between \u201cwhich things\u201d in \u201cwhat way\u201d is also fair.  So the article might better be titled not \u201c<em>Beyond</em> Design Patterns\u201d but \u201c<em>Beneath</em> Design Patterns\u201d or \u201c<em>Before</em> Design Patterns\u201d.  The concepts illustrated are not consequences of or improvements on design patterns; they are priors to design patterns.</p>\n<p>The analogy that came to my mind was one of molecules and atoms. An imaginary article on chemistry titled \u201cBeyond Molecules\u201d might thus conclude ...</p>\n<blockquote>\n<p>Instead of focusing on molecules, I would suggest focusing on understanding how interaction between atoms happens. How does an atom \u201cdecide\u201d what to do? How does it communicate that intention to other atoms?</p>\n<p>Are molecules useful? Absolutely. But I\u2019ll assert that once you understand atoms and atomic interaction, the molecules will \u201cfall out\u201d of the formulas you write.</p>\n</blockquote>\n<p>... which is true enough for as far as it goes, but it is also revealed as a rather superficial and mundane observation when presented this way. Atoms are not \"beyond\" molecules.</p>\n<p>So: molecules are a proper unit of understanding at their level or scope. Likewise, design patterns are a proper unit of understanding at their own level. Reducing them further does not show you anything \u201cbeyond\u201d \u2013 it only shows you \u201cbecause.\u201d</p>\n"
}