I've been using Spring Rich Client recently and it made me think of what makes a good design pattern as I go and implement the MVC pattern.
So with object-oriented programming I have to say that the most benefit I've seen is the combination of data and behaviour which enables large parallel development. As Alan Kay has said on his history of Smalltalk, "..."doing OOP right" would be to handle the mechanics of invocations between modules without having to worry about the details of the modules themselves." This is what the naked objects guys call behavioural completeness. They quote Riel by saying: "'Keep related data and behaviour in one place.','Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.', 'Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System or Subsystem.'"
As they also mention, the MVC pattern is frequently misunderstood and misused as the controllers "...take on the role of task-scripts, incorporating not only the optimized sequence of activities, but business rules also - thereby usurping what ought to be responsibilities of the core business objects." This is usually extended to MVCP (or Model-View-Controller-Peristence) where persistence is not hidden from the other layers.
So by taking this more procedural or subject-oriented view, clothing it in OOP and design patterns, it leads to an architecture that is brittle when subjected to change. This approach has been proven to be less able to adapt to changing business requirements than one that is behaviourally complete.
This also ties into the semantic web for object-oriented software developers where it says, "The key power of OWL is that classes can be defined by combining multiple restrictions and other classes. For that purpose, OWL provides logical operands to build intersections (and), unions (or) and complements (not) of other classes. For example, you could define "the class of all customers from France who have issued at least 3 purchase orders or at least one order consisting only of books, except those customers who have ordered a DVD". This is also an example of behaviour and data moving around together and being combined and types inferred - I don't see it as a contradiction between the two as long as you consider a dynamic typing system like Ruby or Java with AOP, reflection, proxies and annotations. I also see it as the killer application of things like Google's spreadsheet - in fact their spreadsheet is an almost ideal expression of this shared, global object that takes messages and performs operations.
As an aside, I went searching for where I first read about the "Design Patterns" book and it was from a review by Tal Cohen who said: "The concept of design patterns was first discussed by Christopher Alexander, an architect, back in 1977. If someone from the software industry would have considered Alexander's' words back then, perhaps the first book about design patterns in software would have dealt with patterns in FORTRAN programs. As it happens, software design patterns were first discussed in this era, when most software design is object-oriented in nature." And recently, although I don't have access to read it, someone has applied design patterns to Fortran 90/95 (might be as interesting as Object Oriented Javascript).
No comments:
Post a Comment