An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Object Think

July 3, 2006 ·

The last session I attended at CFUNITED was Simon Horwith's talk on "object think". There was a lot of discussion about Simon's views on object-oriented design at the conference because of the "celebrity death match" with Hal. As some of the attendees know, Simon and I disagree vehemently on several issues - mostly around frameworks and the actual implementation of object-oriented designs - but what most people don't realize is just how many issues Simon and I agree on. Simon started out with an overview of what object think is about. The key concept is "object personification" which is the basic way that I teach people about object-oriented design: I make people play at being the various objects in the system. I make them write notes to each other to reflect the message passing that objects do. Object think is all about creating an expressive but accurate domain model where every object handles all of its own responsibilities - it sounds obvious but it has some deep implications.Then Simon went over the history of formalism versus semantic thinking, covering how CASE, waterfall and UML all came out of formalism whereas XP, prototyping and embracing change all came out of semantic thinking. The core belief here - one that Simon and I share - is that programming is really an artistic endeavor, where the few could create everything, although I think CASE and UML etc have their place, insofar as they assist us with our with our design work, rather than just become a set of processes we must go thru for every project. Probably the only tenet where we disagree is on the issue of self-organization. Object thinkers believe that objects should self-organize and therefore there should be no "managers" which really means no services and so on. I agree that in a "pure" object world, there are no external organizers but it's very hard to mimic that in objects in software. I think this might be where Simon and I part ways: he follows Object Think pretty literally and keeps everything to do with a particular concept in one big, fat object. On the other hand, I make the very convenient compromise that some of the stateless aspects of a model belong in a service object that coordinates the behavior of the "smart" objects. Simon drew parallels with XP and agile methods in general - where people are more important than processes and where emergence and evolution are favored over Big Up Front Design. Again, I tend to agree with this in general although sometimes it's very hard to work within an organization that is used to The Big Specification Documentation when you are trying to create an agile, iterative development approach. Then Simon moved onto some guidelines that are intended to help you design your domain model using object think. The number one guideline is that everything is an object. Given that the early object think pioneers were mostly Smalltalkers, this should be no surprise. What it means from a design p.o.v. is that there are no "free-floating" functions - all functions are associated with a concept and therefore inside the object that represents that concept. The next guideline is to think like an object - see above for my comment on how I teach object-oriented design. Next was a fairly vague guideline that essentially said two things: use language from the problem domain to describe the object; ensure that an object's behavior is context-free. The former fits in with "think like an object" but also keeps you focused on the business domain, rather than the technicalities of the implementation. The latter is about encapsulation, cohesion and reuse - objects should do their job in isolation, especially from the environment. The guideline is again the issue where I diverge from pure object think: they say there should be no central control, that objects should be autonomous and handle all of their own responsibilities. I think that's too dogmatic and needs to be tempered with the pragmatism of using controller objects and/or service objects at times. There are no black and white rules on this of course so you really just have to get experience and let your heart guide you at times. The next guideline was that simulation drives the design. In other words, by trying to simulate the domain model, on paper or thru people playing the part of objects, you will identify the details of the design. In particular, you are looking for responsibilities, e.g., "I know about / am aware of... (information or process)" and "I am responsible for... (information or process)". Then, keep functionality close to the data it operates on. This might seem obvious but it's key to which objects contain which methods. A good example is Milking an OO Cow (PDF). A sure sign that a function is in the wrong object is when it's full of obj.getXxx() calls (on the same external obj). Such a method probably ought to belong to obj where it has that data on hand. Next, remember that objects are behavioral not mechanical. I don't remember Simon digging into this guideline much so I'm not quite sure what he was getting at here. Finally, a controversial one: use design patterns as learning tools, not as solutions. Now the underlying intent is that you learn about design patterns - in particular when they are applicable and where they are not - rather than just trying to apply them willy-nilly to your program. However, Simon gives off the message that he doesn't want you to learn design patterns because, he argues, you will then just try to apply them mechanically. He would rather you were rather more fast and loose with your patterns and accept that they "just happen". This was particularly clear from Simon's "Practical Design Patterns" session (that he took over from Hal Helms). Simon presented a catalog of patterns, talked in very little depth about good uses for the patterns, and did not once touch on the forces involved that determine whether a given pattern is appropriate for a given solution. I actually think Simon has misunderstood the object think guidelines about design patterns - especially since the Nicola, Mayfield, Abney book he recommends (Streamlined Object Modeling) is a book about patterns, collaborative patterns. Moving onto the benefits of object think, Simon emphasized that you tend to have fewer objects and that those objects are more maintainable. He said the most objects in any large system he'd built was somewhere between 15 and 20 which I find unbelievable. The Fusebox 5 core files have 11 objects, there are 43 objects in the Mach II core files and around 70 in the Model-Glue: Unity core files. has around 800 objects. I can only deduce that Simon has either worked on systems that are mostly procedural or that his objects contain enormous amounts of code (he did at one point say his largest object had around 1,000 lines of code). For comparison, the Fusebox 5 CFCs contain about 3,400 lines (including at least 500 lines of copyright / license comments!), Mach II's CFCs about 5,000 and Model-Glue's around 6,000.'s 800 objects run to about 175k lines of code. I can't imagine a system of any size containing as few objects as Simon advocates, especially when he is claiming that there is no more than 20,000 lines of code in those objects and usually much less. I'd expect to see systems with an average of 200-250 lines of code per object ( is around 225, Fusebox around 260 excluding the license comments, Mach II around 120, Model-Glue around 85) and I would expect a relatively complex system to be somewhere upward of 50,000 lines (of object code alone). That's 200-250 objects in a typical complex system. Moving on, other benefits claimed were better maintainability and reusability (I think you get better reusability from smaller objects). Simon recommended as next steps that you actually try modeling your domain with object think and I'd heartily agree with him on this - there's no substitute for real world experience with object oriented design and it's OK to make a few mistakes and learn from them. Then he gave a copious list of references (four slides full!), including Christopher Alexander (the building architect who is essentially the father of patterns) and Adele Goldberg (creator of Smalltalk) as well as many others. Simon said he'd post his presentation on his site (or it'll appear on the CFUNITED site in due course). I highly recommend reading through Simon's presentation and, especially, following several of the references he cites.

Tags: architecture · coldfusion

8 responses

  • 1 Peter Bell // Jul 3, 2006 at 5:43 PM

    Hi Sean,

    Great job. I followed Simons presentation, but I think you've managed to abstract his key points and make them even more lucidly than he did (and Simon is a good speaker!).

    Best Wishes,
  • 2 Rob Gonda // Jul 3, 2006 at 5:57 PM

    Sean, great summary... it seems like Simon is a fan of hot super models :)
  • 3 Matthew Lesko // Jul 3, 2006 at 6:06 PM

    Sean, have you read Eric Evan's "Domain-Driven Design"? This book seems to be in keeping with your summary of Simon's presentation. I'm muddling my way through material to aid my thinking about how to build a domain model and this book seems to be the most focused on the subject. Are there any other books in particular you'd recommend on this topic? Or other resources for that matter (i.e. other than experience)? Regards.
  • 4 Edward T // Jul 3, 2006 at 6:28 PM

    Sean, great post - thank you for putting in the time to summarize these points. I have to admit that when I first learned OO back in '97, I felt cheated when I learned about service layers. I couldn't help thinking that those 'dispatchers' were nothing more than 'main' wrapped in fancy new clothes. But then I read Bjorn Stroustrup's now-famous quote, 'Good programming has always been object oriented,' and I felt much better :)
  • 5 Peter Bell // Jul 3, 2006 at 6:43 PM

    Hi Edward,

    Glad someone else felt cheated when they first learnt about service methods, although after some long chats with Dave Ross I've finally come to accept them as the least bad approach to implementing an OO project once you've got the domain objects figured out.

    Matthew, one great approach is Ward Cunningham's CRC cards. They were designed as a teaching aide, but I find them useful in modeling a domain. You might also want to consider use case and FLiP style screen prototyping. I find that screens tend to be describable as %EntityName% [form/list/view/import/export/report] so a domain model can often come out of the screens required to implement your use cases.

    You might also want to look into Streamlined Object Modeling - an interesting group approach I've not had the time to digest yet, but Paul Kenney though that along with ObjectThink it was well worth looking at.

    Best Wishes,
  • 6 Jon Wolski // Jul 11, 2006 at 6:29 PM

    While it is as you say "unbelievable" to think that any complex system could be built with 15-20 non-bloated objects, you have to consider that the complexity of the system arises from the behavior of and sundry interactions between the objects rather than the capabilities of the objects themselves. With 0..* instances of only 15 objects interacting with eachother, great complexity could arise. As Simon acquiesced, though, it also becomes very difficult to unit test (running counter to Agile/XP).
  • 7 Peter Bell // Jul 11, 2006 at 8:49 PM

    Hi Jon,

    I'd really like to see some code for a non-trivial enterprise application with notifications, workflows, database access, reporting, personalization, authentication, transaction management, import and export capabilities and a wide range of administrative capabilities that could be implemented in the number of objects mentioned.

    I create relatively simple sites for SME's, but even those have pages, articles, users, roles, products, master products, attributes, attribute options, discounts, sales taxes, gift certificates, tasks, notifications, orders, order items, cross sells and the like - that is 16 business entities right off the bat.

    I then need to be able to have list, view, admin list, search, add, edit, delete, validate, calculate and transform methods. I need the ORM methods for stuff like order items in an order. I often need import and export capabilities and then there are a number of reports the user usually requires. None of this includes tying in roles based security and personalization to the objects, transaction management, rollback, versioning and the like.

    I find that each business entity needs at least a service method, business object, validation object, a DAO and a transformation object to avoid bloat. Then there are the objects for handling HTML specific display issues and user controls which have their own class files and any objects used by the controller and for service orchestration purposes.

    This means that my relatively simple (non-enterprise) apps often have 60-100 objects - each with a few hundred up to a thousand lines of code. I'd love to see the code for a similar scope of app with less than 20 objects none of which would be considered bloated. Perhaps I'm writing an order of magnitude more code than I really need!!! :->

    Best Wishes,

  • 8 Sean Corfield // Jul 11, 2006 at 9:11 PM

    Peter, yes, I tend to agree. I just looked at a small application I built for the Macromedia ERP team (the scanners / processor / gateway application I blogged about some time back). It has about 40 objects (plus the Model-Glue framework for the "UI" portion). That was the Phase II version.

    The Phase I version - which was much simpler - had 22 objects (plus the Mach II framework for the "UI" portion).

    These are *small* applications.

    The Online Store has about 150 objects (plus Mach II). The entitlement application (which is essentially all the membership-gated downloads on has nearly 60 objects and it's not really a big app.