Class Management Versus Object Management

It occurred to me that ClassManagementVersusObjectManagement is one of the fundamental forces in software design. I was developing some code a while back that was heavily state-oriented, so I drew heavily on the State pattern. My design looked good: lots of state classes with encapsulated state-specific behaviour and properties, no conditional code in the 'context' class. Trouble was that I now had four objects (one context and three orthogonal states) where once I had one ... or rather I now had 400,000 objects where once I had 100,000. And because all these objects are stored in a replicated database it now had 4 times the locking and replicant synchronization work to carry out.

So I went back to the 'bad old way' of using flags and worried about how inelegant my design was. Except maybe it isn't all that inelegant because it solves a particularly hard force in the context of our system: lots of objects distributed over a network means performance is a big consideration (and we've found, with others, that MakeItFastBreaksMakeItRight in a distributed environment). It's really about balancing the forces for class management and the forces for object management to best meet the needs of your system:

Class Management: say something only once, choose polymorphism over flag checking, FavourObjectCompositionOverClassInheritance?. In other words, favour elegant code.
Object Management: reduce the proliferation of objects in your database, cluster related objects around network nodes. In other words, favour elegant runtime structures.

It may be a good OO heuristic to favour one over the other (depending on the context you develop in, I bet embedded systems developers lean towards ease of object management over class management) but we should always be aware of the times when we should break the heuristic and be prepared to do so at times.

-- PaulDyson

This is an interesting issue. One aspect that seems curious to me is a matter of normalization; we take pains to normalize our interfaces, but often the way we hook those interfaces together as runtime objects goes unplanned. Oh, we make a few collaboration/sequence diagrams, or we roleplay our CRC through some user stories (or a bit of both ...), but we rarely formalize our configuration of objects. We don't even have a common language to do that.

Some of the design patterns might form semantics in such a language. But is this something that can be planned and normalized? And what benefits might come from trying to do this up-front instead of at optimization time? Could a formal approach to this help prevent MakeItFastBreaksMakeItRight? And what are the most common ConfigurationPattern?(s)?

-- PeterMerel

What are collaboration diagrams missing?

Perhaps nothing. But I've never seen a collaboration diagram used as a configuration manifest - only as an explication of interface semantics. In my experience a collaboration diagram might correspond with a use scenario or a test harness ... but do you really use collaboration diagrams to describe the whole configuration of objects in an installed system? I wonder if something more like Coleman's Classic-Fusion lifecycle models might be more expressive for this - or something else with a regexp-like syntax. -- PeterMerel

I'm big on drawing pictures. [JeffGrigg] But whenever I start introducing instances into technical drawings, I quickly run into scaling issues: There can easily be thousands of object instances in any given running program. So I quickly resort to showing just a few "example" object instances, and leave the rest fuzzy, or hidden in stacks:

   +-----+
   |     |-+
   +-----+ |-+
     +-----+ |
       +-----+
           ...

TrygveReenskaug's OORAM is all about communicating pictures of a whole collaboration above and beyond any single message thread. See RoleModeling for more about this.