01 December 2005

I’ve recommended David West’s

Object Thinking book to many people. I really like the book a lot, and think that his underlying message has tremendous value. But the trick with the Object Thinking book is to take the concepts and philosophy and to adapt it into existing tools.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

  David walks through examples assuming a clean slate. No pre-existing framework like .NET or the JDK. No data binding, nothing. And that's good for making his point, but is somewhat silly in the real world. It is hard to imagine ignoring data binding or all the other powerful plumbing built into .NET...   Likewise, he ignores the value of IDEs. Take away Intellisense and VS becomes pretty crippled. Yet building all objects as collections of field values basically means that they all become Dictionary objects with business rules attached. No more Intellisense or compile-time checking of anything. Ouch!   So in my mind the value of Object Thinking isn't in the idea of creating objects at such an incredibly low level that you lose the value of .NET or of VS.   Rather it is in the view that objects have a single responsibility. That they are defined by their behaviors, not by their data. It is in the understanding that no class should be overly complex. If it starts to become complex it is because you aren't factoring the behaviors properly, and aren't effectively leveraging collaboration between your objects.   You could look at CSLA .NET and wonder why I like Object Thinking. After all, CSLA .NET can help you build some very data-centric object designs. But CSLA .NET can also help you build some very behavior-centric object designs too. That’s really your choice!   From a behavioral perspective, CSLA .NET merely provides (in 2.0) six broad templates:   ·        Editable single objects ·        Editable collections of objects ·        Readonly single objects ·        Readonly collections of objects ·        Command objects ·        Name/value lists   All of which tap into a whole set of underlying concepts including data binding, mobile objects and object persistence.   But the goal is to allow a business developer to design a set of objects that have business-specific responsibilities that are better enabled by leveraging this pre-built functionality.   A Customer object’s responsibility may be to record valid customer data. By inheriting from BusinessBase, the business developer can focus purely on the behaviors necessary to fulfill that responsibility. The object automatically gets data binding, mobile object and object persistence concepts with essentially no effort. The focus is on the business responsibility and behaviors, not on plumbing.   But other objects won’t inherit from CSLA .NET. This, I think, is the biggest single hole in how people use my framework. A real business system has many objects that interact with data, true. But collaboration and behavioral OO modeling means that there should be a lot of objects that don’t interact with data. Rather they implement pure behavior!   These may be following the observer pattern or other design patterns. They may be business rule implementations, or implementations of business algorithms like pricing or taxing. There’s a whole ton of behaviors that often don’t belong in a BusinessBase-derived object, but rather belong in their own object. Then a BusinessBase-derived object will collaborate with these other objects to do its work.   To me that’s the value in West’s book. The philosophy of each object having a single, clear responsibility. Of objects collaborating with other objects to perform complex tasks, without being complex themselves.