Guido Stevens: Living Software for a Living World

I read the GoF (Gang of Four) book 'Design Patterns'. When I read what it says about the adapter pattern, which I use every day in Plone, it just takes the fun out of it. Overabstraction is wrong. If humans can't understand a pattern or architecture, it is wrong.

Book 'A Pattern Language', 1977. Much different from the GoF book. More inspired by Christopher Alexander. More human.

In 2000-2004 I was using PHP, with test driven development, full version control. 2007-2010: Plone 2.1, 2.5, with TTW skins, which had no tests and no version control, so a step back. But the ZCA (Zope Component Architecture) came. This has several of the Design Patterns: Interface, Adapter, Utility (Singleton), Subscriber (Observer). Some others might be useful, like Strategy.

I used to completely specify Interfaces, which is how it is intended. But nowadays they are mostly just marker interfaces, which work because they serve as hooks into the ZCA.

Before adapters there was excessive polymorphism. Just look at the CatalogTool in Products.CMFPlone, and try to follow its multiple inheritance. You can overdo it. With adapters you have separation of concerns. You create an adapter that gets the UID from an object. And you create a utility that resolves the UID into an object.

Subscriber (Observer): a subject broadcasts event. It has no knowledge of its subscribers. These subscribe to events, and execute some code on it.

We have actor, action, context: an editor publishes a news item. And this sends 5000 notifications via email, and the editor needs to wait. That does not scale. So we need a notifications sub system. Alessandro is the technical architect and lead developer here. We log the 'published' event in an SQL database, and then the transaction is done.

Then we schedule notifications. Here we use the Chain of Responsibility pattern: for each logged event, for each channel, for each category, for each recipient: if channel is active for category and recipient: store the notification in SQL.

Then we dispatch the notifications. For some we will send emails, for some we send them later in a digest email.

Christopher Alexander, mentioned before, wrote 'The Nature of Order'. There are lots of patterns, but you can condense it to 15 structural patterns. Structure preserving presentations, process, time. Inspired by nature, fractals.

How do we apply this to the software challenge we have? In Quaive we have a Calendar app. This has notifications. This is implemented in adapters and subscribers. Same for other apps. Same pattern. So we have the notifications framework that does the heavy lifting, this is the trunk. And then we have the apps (leaves or branches) that use the patterns. So developers can zoom in on the business logic in a single app, and forget about everything else.

Object reuse was the 1995 Patterns goal. But now we have frameworks, that coordinate reuse. It is not not import library, but you make you of the code flow in the framework.

Plone rocks. It is a community that makes a framework and a framework that makes a community.