This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Reflections when modifying a complex program
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
As I mentioned in earlier posts, I'm modifying BottomFeeder to use a new domain model. This involves several phases of work, because it is a complex program. The original domain model isn't too complicated, but the viewer app does a lot with it, and it is affected by a lot of startup and communications code. And that leads to the original problem that got me started on this project, that much of the domain logic had migrated (over many mod cycles) out of the domain model. This is a normal occurrence in the life-cycle of any program, but eventually it has to be reined in.
Right now, I'm working on the viewer app class, with its 360+ methods. How does one deal with a monster like this? The first step is a heck of a lot of "orthogonalization" -- figuratively putting things at right angles. This means getting the names of variables, methods, protocols, resources, widgets, and symbols as consistent as possible; for example, getting the word "feed" into every name that relates to feeds, such as "deletedFeeds" for a collection of feeds that have been deleted. And it means making the name of every method that affects a feed say what it does to that object, such as "sendItemAsComment." These are fairly obvious concepts in literate programming, but they need to be done rigorously.
A second orthogonalization practice, is to organize methods into granular, consistently named protocols. It doesn't help to put a lot of methods into overly general protocols, such as "testing." If a class provides "action" methods for a variety of different objects, then put them into protocols with names qualified by the object class, such as "feed actions" or "folder actions," and align them with menus it provides for working with feeds or folders. This technique hopefully leads to a better understanding of what objects are affected by what methods, so that some of them can be refactored into the domain model, and some others can be moved into appropriate new classes. The whole point is to break down that 360+ method monster class into more manageable and understandable classes. And in this case, it means leaving the original class better focused on its main task, the wiring of a graphical user interface to domain objects.
What makes these changes possible is that the Smalltalk compiler is completely indifferent to what human-oriented names are used, and the Smalltalk development environment provides such powerful tools for changing names and reorganizing methods. The new refactoring browser is especially helpful, though I have had a number of transient problems with some of its operations.
By the way, can any of you Sci-Fi experts identify where I got this concept of "orthogonalization." As a hint, it is defined as "the process of bringing order to a messy room." A gold star goes to whomever can name the title and author.
Previous Topic
