Functional Design Patterns

By Deane Barker on July 6, 2005

Applications have patterns — ways of doing things that have stood the test of time. These aren’t object modeling patterns, about which books and books have been written, these are…best practices for how to solve a particular type of functional problem.

Around my city, you see a certain style of house with the garage pushed forward toward the road so the architect could fit living space behind it. You see this home style coming from many different architects. Why? Because it has sufficient benefits to outweigh the drawbacks. It’s a pattern — a best practice that offered the most benefits with the fewest drawbacks and was thus repeated.

In content management, sufficiently mature systems tend to fall into patterns as well, no matter who makes them. An example —

When your content management app gets mature enough, you’ll probably end up with a content tree, or taxonomy — a recursive structure whereby an object can be a parent of another object. I’ve seen this same functional design pattern in systems from Interwoven, Documentum, eZ systems, Zope, etc. If you work with big content management systems long enough, you eventually come to realize that that’s just the right way to do it — the design that gives you the most benefits with the fewest drawbacks.

So over the years, I’ve learned to build content management systems this way from the start, because I knew I was going to end up in that pattern eventually. Why? Because a lot of people have been doing content management for a long time, and it’s become obvious that content just works well that way. (The underlying theory of a content tree is another post entirely — I promise I’ll write it next week.)

Here’s a more in-depth example —

I have a client right now who needs a Web-based calendar. Now, these things have been done to death. But did anyone…take notes? Did anyone examine how a calendar works from a language-independent standpoint and determine how to model the concept of events occuring across time?

Put another way: events and time have been with us since…well, forever. Before computers, certainly (yes, Dave, it’s true — time didn’t begin on February 24, 1955). So, we should be able to sit down and model an electronic calendar without any consideration of languages or platforms, right?

Joe and I did this for a few minutes over lunch. We discussed the concept of a calendar while waiting for our burgers, and we came up with these random considerations you need to be aware of before you start building an electronic calendar.

  • Events can be of two types: point and range. A “point event” is a singularity — it happens at a single moment in time (“applications are due at 5:00 p.m. on Friday”). A “range event” starts at a certain time and ends at another time.

  • You need to pick a base time unit for your calendar. This is the smallest unit of time into which you’re going to group events. For our purposes, we’ll take a day — when we hand our presentation code a bundle of events, the smallest unit will be a day.

  • Events cannot recur during the same unit. If you teach Computer Science 101 at 9:00 a.m. and 3:00 p.m., that’s not recurrence — that’s two separate events: a morning class and an afternoon class.

  • Now, the previous points mean that an event can have one of four states in relation to our base unit of time. An event can:

  • “happen” during that unit, meaning that the start and end of the event is within the unit

  • “start” during that unit, meaning it will begin on the current unit and end on another unit

  • “continue” during that unit, meaning it began on a previous unit and will end on a later unit

  • “end” during that unit, meaning that it started on a previous unit, and ends on the current unit

  • So when our calendar groups events into a unit of time, it will group them into events that (1) happen, (2) start, (3) continue, and (4) end during that unit.

What’s above barely scratches the surface. Just wait until you start to consider recurrence — the implications get overwhelming pretty quickly (we identified “tight,” “loose,” and “irregular” recurrence within a few seconds, not to mention “overrides,” “forces,” “suppressions,” etc. We could be here all day…).

But, this isn’t my point. My point is that the structure of a calendar as we discussed above has not changed because of computers. Events have been relating to time in the same way forever. And this relationship is not going to change. Ever.

So, what someone needs to do is create a comprehensive, all-encompassing data model explaining how events and time relate. Essentially, design the ultimate calendar, then separate the “eternal core” of a calendar from the implementation, and present a language independent description of how you create an electronic calendar. What pieces of data does an “event” expose, and how do they relate to the concept of “time”?

The idea is to stop re-inventing the wheel from a functional design standpoint. You capture this model, then let anyone implement it in whatever language they like (even ugly, procedural code), incorporating whatever depth of the model as they want. But no matter what language an implementer uses, or how deep he or she wants to go with it, the best practice of how a calendar is structured and works is unlikely to change much.

The bottom line is that developers fall into ruts. This isn’t a bad thing. More often than not, we fall into ruts because they’re the best way to do things. These ruts don’t care about languages or platforms — they completely transcend technical concerns. They’re more concerned with the eternal core of a problem.

We need to identify and document these ruts, these best practices, these time-tested solutions. Being able to read a functional design pattern before you started a similar project would be like talking to a developer who has built 100 of the same type of systems, and listening to him tell you all the dead-ends he went down, all the false leads that failed him, and finally, all the functional patterns that worked so well that he found himself doing them again and again in successive projects.

My passion is content management, and I’m thinking it’s time for a public wiki so we can all have a big discussion on how content works from a functional standpoint.

What Links Here


  1. Wow. Even as a geek and programmer who makes his life out of this kind of detail, I was impressed by how well defined you made a calendar. Yes, many of these things are common sense or are something we think about when we think of a calendar, but I don’t remember ever defining anything as a property of a calendar. Impressive. Most impressive.

  2. I was impressed by how well defined you made a calendar

    Thanks. Actually, those were only about a fifth of the thoughts I had on the subject. It’s a deceptively complicated problem.

    I went for a long walk the other night, and modeled the “perfect” calendar in my head. It got so complicated and abstract that I had forgotten most of it by the time I got back to the car. However, I just need to get into the mode again, because most of it came rushing back to me when Joe and I were talking over lunch today.

    If (when?) I create this patterns discussion site, a Web calendar will be the first problem I’d want to tackle. It’s a great problem because it’s complicated enough to be interesting, yet the domain is so stable — events and time have been and are going to be related the same way for all eternity.

  3. Hey,

    Nice piece of analysis! One thing you should definitely do is define TESTS for all this functionality, so that people who implement these have lots of good fodder for the unit tests. Then it’ll be so much easier to implement. I’m a big fan of test-first programming (another concept with an infinite number of existing websites, so I won’t describe it :-), and I do find it makes better code, particularly forcing me to make the objects testable on their own, so they’re less coupled with other objects.

    Defining tests up-front will definitely help the quality of the code, and often help understand the problem as well.



  4. But when you start talking about unit tests and such, you’re talking about code. The functional design pattern is above the code — the code is an implementation of the pattern.

  5. I’m curious as to why you chose a day as the smallest unit of time and not a minute. I understand for display purposes it is better to see a month of events rather than a week or a day, but I’m wondering why that is not done at the display end rather than the code end of things.

  6. I’m curious as to why you chose a day as the smallest unit of time and not a minute.

    That’s the beauty of this being an abstract pattern rather than a specific implementation. It only requires you to pick a unit — it doesn’t dictate what that unit is. You could do minutes if you like.

    It’s just a question of managability — I think breaking things down to the minute would be awfully complicated, but for some applications requiring high accuracy (a prison guard rotation, etc.), it would be appropriate.

    Just use a hammer to hit a nail. Pick the unit of time that gives you to most benefits and the fewest drawbacks for your specific situation.

  7. But when you start talking about unit tests and such, you’re talking about code. The functional design pattern is above the code – the code is an implementation of the pattern.

    YAChris may have been describing unit tests, but when doing something like this you do need acceptance tests. These are tests that determine if the system produces what it should, and are often labeled compliance tests when associated with a particular specification or functional design.

    A nice framework exists for defining these acceptance tests within a wiki, and then once code has been written, tying them to an implementation – it is called Fitnesse. It was designed to allow a more business-level person (read: customer) to define how the system should response to inputs, but it could also be used to map a specification such as this calendar to a set of acceptance tests that verify the intent of a spec as well as an implementation.

  8. At first I was going to say that the iCalendar specification addresses what you are looking for, but then reread that you’re looking at it from a ‘functional design standpoint’. I think you’re proposing something different, since iCalendar is a specification for passing events, tasks, etc. but at the same time they are similar because in order to get into the detail or events, tasks, etc., very specific terminology to define the calendar domain has been created/documented. (And, as an added bonus, they even throw in tests (acceptance, whatever you want to call them) that can be performed to check for compliance (particularly in reference to recurrence).

    That said, I don’t know if there’s much need for a functional repository for the calendar domain. Two reasons: First, I believe that the repository already exists in the form of the current industry leading calendaring applications (Outlook, Yahoo,, iCal, etc.). Second, doesn’t encouraging everyone to follow the same model limit the creative evolutionary breakthrough, whether minor or monumental?

    Although, as I write this, I’m not quite sure whether I’m entirely off base, or just not quite on the same page. I think I’m partly thrown by your mixed examples. I would agree that a common language to describe a domain is valuable. However, your example about the garages, to me, doesn’t seem to be a domain description, but rather an implementation of something from the domain. The description of a house domain would be: door, window, walls, rooms, floors, cabinets, sinks, etc. The implementation is create a room (garage) in this location with these walls, windows, etc. While the guiding prinicple to put the garage forward works and probably has many benefits, it probably won’t work for everyone, whether because of personal functional requirement or just because of personal tastes.

    I’m actually involved in Yet Another Online Calendar (YAOC) effort. At first we were reluctant to go into that space because there are so many established and free players in the area. However, we believe that we have found a niche for a calendar that is targeted to a specific audience. As we got started on the project, it would have been nice to have a document that detailed the nuances of the domain, but at the same time, every stumbling block on how to implement something was solved with the question, ‘How does Outlook do it?’.

    And maybe here’s my third (bonus) point of why the repository might not be needed: You can’t really pigeon-hole everyone into the same implementation. Just look at weblog apps: WordPress does things differently than MovableType which does things differently than TextPattern which does things differently than .Text, etc. So could you really hope to capture everything? (Once again I think I’m hung up on your functional vs. implementation examples).

    Sorry for the long comment. Your post was good and thought provoking. Calendaring is near and dear to me at the moment, so I felt obligated to reply. If you had stuck to the CMS domain, we would have all been spared!

  9. Matt: I believe the idea Deane was trying to get across is to have a site for specifications, and the calendar is just the first one she thought of.

    Yes, industry leading calendaring software do create somewhat of an outline, but they aren’t clearly defined on their own, they are only inferred from using the software. The idea with this is to have a written specifcation with the common points clearly defined so that developers don’t always have to do that themselves. And, yes, you could say that using the same model potentially limits creativity, but I don’t see how saying that it should have a minimum unit of time is going to limit a breakthrough. The idea is only to put down the necessary components of a calendar, the ones it must have.

    There’s no attempt to pigeon-hole everyone, it’s an attempt to show everybody the things that must be done or that are most commonly done so as to ease the design process.

    I for one love this approach. If I weren’t a poor high school student without a shred of money, I would gladly pay for the hosting and domain but, alas, I remain without cash.

  10. A lot of this discussion is geting wrapped in in the Web calendar example. That was just an example.

    A lot of other things need to be patterned. A taxonomy for instance — if you’ve never built a parent-child tree of data, there are some things you need to consider —

    • Will items be allowed to exist in more than one category?
    • If so, will they have a primary category?
    • If not, how will you do crumbtrails?
    • How will you generate a list of ancestors without destroying performance? Will you cache it? If so, when do you re-write the cache?
    • Will you allow property overrides on separate assignments? (For instance, the title of this entry is one thing under this category, but another thing under this category…)
    • How will you let people “jump the tree,” or move from one branch to a related branch without going back to the trunk?
    • What will be your main facet of classification? For instance, do you primarily classify news articles by region or subject matter?
    • How will you ensure a category isn’t reassigned to one of its own children, thus setting up an infinite loop and logically impossible condition?

    Again, we’re just scatching the surface here, but these are all questions that “transcend the code,” so to speak. Whatever platform or application you’re using, these are questions you’re going to need to answer.

    So, let’s not fixate on the Web calendar thing until we set-up the actual patterns site — then you can fixate all you want.


    “ is a wiki site that aims to increase pattern sharing, dialog, and usage by bringing together people who want to learn proven solutions to common problems from people who have solved them before. The pattern format combined with the flexibility and community ownership of the wiki make the site ideal for this kind of community.”

  12. | We discussed the concept of a calendar while waiting for our burgers,

    The need for time-based computer applications is a old as computing. Look at the Unix Cal, at and Cron utilities. Understanding them is a key part of knowning Unix, and thus a part of how the Internet works. Unix and the Internet were developed together and complement each other in deep ways. “Traditional” programming has many languages, but they all have or eventually grow libraries of code to do time-based work like Cal at or Cron.

    | The idea is to stop re-inventing the wheel from a functional design standpoint.

    Not-Invented-Here syndrome is strong with the Corporate sector. Especially in small companies, it has to be built Just the Right Way(tm). Where Right is defined as what is in the head of the manager or customer.

Comments are closed. If you have something you really want to say, email and we‘ll get it added for you.