July 3, 2006 · 8 Comments
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. adobe.com 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. adobe.com'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 (adobe.com 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.