This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: A Fundamental Flaw
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
I have come to believe there is a fundamental flaw in the architecture of the typical Smalltalk application; namely, the primacy given to a subclass of UI.ApplicationModel (or its equivalent). This says that the user interface IS the application, and that everything else is secondary. The effect of this is to deemphasize the importance of the domain model, when in reality most key design decisions must flow from the requirements of the domain. Anything else is just putting the cart in front of the horse.
This emphasis on the UI stems from a desire to easily support the development of easy, tutorial-level examples of GUI programming where the domain model is trivial; but it does not scale well to complex applications. All kinds of logic gets dumped into the ApplicationModel subclass, such as domain logic, persistence logic, and both application start-up and termination logic, that really don't belong there. The ApplicationModel subclass bloats into something that cannot be reasonably considered object-oriented.
The programming task of wiring a GUI for a complex domain model is sufficiently challenging without this extra baggage. In fact, all by itself, the wiring code is all too often not very object oriented, and therefore difficult to both create and maintain. Just having a lot of small methods doesn't make a design object-oriented; that just makes it procedural.
Putting that aside for the moment, this leaves open the question of what would be a better application architecture. I would suggest that the answer lies in understanding that a complex application should consist of independent subsystems that interact through clearly defined interfaces. But this is hard to achieve without any support for the concept of subsystems from the programming language/environment (and I know of none that do support it).
Here is a list of some of the subsystems a complex application might have:
A startup subsystem.
A GUI widget painting and manipulation subsystem.
A subsystem for wiring the GUI to the domain model.
The domain model subsystem.
A domain object persistence subsystem (i.e., database).
A communications subsystem.
An external files subsystem.
A termination subsystem.
And beyond this, the application itself should be programmed as a subsystem composed of subsystems.
Yes, I admit that this would be a typically male, hierarchical approach to design. But realistically, this matches our modern scientific understanding of the real world; that it is composed of entities at various levels of what we characterize as a hierarchy, and that entities at higher levels exhibit emergent properties that are not apparent in lower levels. Our job, as computer programmers, is to create higher-level entities with specific emergent properties, from the lower level objects at our disposal. It is time we stop thinking only in terms of objects, and get serious about subsystems.
Now back to the original point of this note. I believe an application should consist of a collection of interacting subsystems, one of which is a domain model subsystem. Another is a GUI subsystem, which would still consist of instances of UI.ApplicationModel subclasses. But now, the application is started by sending #startup to the application subsystem, which then sends #startup to the GUI subsystem, which sends #open to the application's primary user interface. This probably isn't the best design for tutorials, but it would certainly bring a level of clarity to complex applications.
Previous Topic
