Lesson 10.1 Organization
Program Organization
Why should we worry about program organization? Young programmers and the "lean and mean garage-shop" developers often deride what they see as the excessive "busy-work" that can accompany large-scale programming projects. "Stop talking about it, and start writing some code!" they think.
This is not a new phenomena; more than twenty-five years ago, Fred Brooks began his classic book, "The Mythical Man-Month" by explaining the difference between a program, which could be produced by one or two people working on weekends, and a software product, which requires organization.
Similarly, Nicholaus Wirth, the father of Pascal, Modula 3, and Oberon, wrote:
"The details are the jungle where the devil hides. Our only salvation lies in structure."
Programs need organization, and they need organization not because computers are incapable of keeping everything straight, but because we are. Human beings are "complexity challenged", and we use organization to provide the simplicity, clarity, and efficiency we need for understanding.
The Life of a System
If organization provides us with the ability to simplify and understand complex problems, then, from a purely pragmatic perspective, program organization allows us to:
- Solve larger problems
- Reduce errors in programs
That is not the greatest advantage of program organization, however. The greatest advantage of good organization lies in its ability to facilitate future maintenance. Today, the major software expense is not developing new software, but maintainng existing software systems. This expense includes both expansion and bug-fixing.
The history of programming, what there is of it, has shown that programs last much, much longer than expected. When I was in school, we learned about the "SDLC"--the System Development Life Cycle. We learned that programs have a life-cycle just like any other product; they are conceived, constructed, maintained, and are put to rest.
Unfortunately, those who wrote about the SDLC had no real empirical evidence to go on. Years ago, Fred Brooks likened a runaway software project to the Werewolf, who could only be slain by a silver bullet. Today, in hindsight, we know that software systems have more in common with Count Dracula than with the Werewolf.
Simply put, the SDLC is wrong. Software systems never die--they go on forever, both good and bad. Poorly organized programs join the ranks of the undead. You will be living with the software you write today for a very long time. Your children and grandchildren may grow up maintaining your programs. It makes sense to organize your programs in a way that makes this future as pleasant as possible.
Types of Organization
Before we begin looking at the organization of object-oriented programs, let's take a brief look back at traditional organization, which you met earlier.
Traditional Organization
The first real breakthrough in organizing programs came in the guise of functional decomposition. If you've ever studied ancient literature, you know that Jack Kerouak didn't invent the stream-of-consciousness style of writing. The books of the Bible, for instance, were not divided into chapters or verses but were simply one, uninterrupted narrative.
Ancient programmers, like these ancient writers, wrote their program in one big chunk. Start at the top--go to the bottom--end of story. But, while that may be the easiest way to write a program--going with the flow, so to speak--it makes it very hard to repair. The legendary Bell Telephone program "Big Bertha" is reputed to have had over 30,000 lines of uninterrupted assembly language source code. While such a program may work, it is not, in any sense, maintainable.
Functional Decomposition
The idea behind functional decomposition is simple:
- First, take groups of related statements and "package" them together. These groups of related statements are called subroutines, procedures, or functions.
- Now, take your procedures, and organize them based on the "chain of command" principle. One procedure--the mainline module--was put in control of the others. The mainline procedure had second-level "Vice-Presidents" which managed other procedures, and so forth.
This traditional program organization looks very much like the corporate organization that fueled much of America's post-war commercial success. Like that model, however, the traditional model of program organization has some weak spots.
The Problem With Data
Specifically, these early designs had no provision for bundling data with the operations that processed that data. The model was perfectly suited to "assembly-line" type applications such as payroll processing, but stumbled a bit when the nature of computing changed.
Specifically, it was very difficult to build reactive systems [we call these event-driven now] using traditional organization. In a reactive system, each of the subsystems is semi-autonomous, and keeping each procedure from "stepping on" the data of another became a gargantuan task.
The solution to this problem was a series of steps from records or structures, through abstract data types, and ending up with classes and objects as we know them now.
But, while classes and objects help to avoid problems of data corruption, they provide no help at all in determining how those classes should be combined.
What kind of organization should an object-oriented program have?
OOP Organization
There is no monolithic, widely accepted structure for an OOP program, like there is for traditional programs. Instead of a hierarchy, OOP programs are organized based on relationships. An OOP program will normally employ all three methods of organization. The trick is knowing what method to employ in which context.
Method 1: Communities
In a community-based program, autonomous objects offer their services, and request the services of other objects. The relationship between the various objects is called a USES or, sometimes, a client-server relationship.
Quite large programs can be built using just this organizational model, without any of the other trappings of object-oriented programming. Visual Basic, for instance, employs this model. You create a form and populate it with components. Each of the components communicates with the others by asking them to perform a method or change one of their attributes.
This relationship model can be made to appear quite similar to the traditional program organization if you have a "boss" object which controls all others. On the whole, however, the USES relationship is local, rather than global. Large programs built using this as the only organization scheme tend toward anarchy.
Method 2: Composition
You met composite objects in the last lesson where you saw that you could create new objects by combining existing objects. The composition organizational model works very much like functional decomposition, but from the "bottom up."
An automobile or a B2 Bomber, for instance, are both organized using composition. If you take your car to the repair shop, you'll see that the parts catalog is organized into subsystems such as electrical, drive-train, body work, engine, etc. Each of those subsystems is then further divided into sub-assemblies, until your get down to the individual nuts and bolts.
This is a much more effective way of organizing objects than simple community organization. The functional hierarchy makes it quite easy to find out which part of the system is misbehaving, and to locate the offending part.
The only difficulty with composition is that it makes no provision for similar, but different parts. To purchase a timing belt for your 1978 Pinto, you have to locate that particular component; you can't usually use a substitute.
If your job is to build a new timing belt for a new automobile, you usually can't just take an existing set of blueprints, and modify them slightly. You can reuse the knowledge you've gained about building timing belts, but you usually cannot modify the existing belts themselves.
With software, and the magic of inheritance, however, we can.
Method 3: Inheritance
A third method of creating object-oriented software begins with a process called classification. In traditional software development, the first step is to divide the problem into modules or procedures. In a similar way, the first step in OOP is grouping "related" objects together. This process is often called "finding" or "discovering" the classes in a problem.
That, of course, immediately leads to the question "How are objects related?" We say that two objects are related if they have the same attributes and behavior. Let's look at an example.
Here on campus, we have a problem providing student refreshment. We solve the problem in several ways:
- We have a cafeteria
- We have coffee vendors throughout the campus
- We have candy and soda machines
Each of these is an object that belongs to the same class of objects: the class of objects designed to supply food and drink to the students. Each of them is clearly different from the class of objects designed to provide instruction or the class of objects designed to see that you have a parking sticker.
Generalization
Once classes have been discovered, the second step in this organizational model is to employ the process of generalization. Generalization is a method for organizing and simplifying classes discovered during classification.
The process of generalization begins by:
- Identifying common traits in the different classes discovered during classification.
- Extracting common behavior and attributes in the different classes into new classes employing just the common portions.
This process is very similar to the "stepwise refinement" used in traditional programs. It is common is such programs to refine your procedures or functions by moving redundant operations to their own procedures so they can be reused.
In our example, we can generalize about the coffee, candy, and soda machines. All of them mechanically accept money. All of them allow the customer to select a product. All of them dispense a product of some sort, but the manner in which they extract and store the product differs.
Using generalization, this common behavior could be extracted into a new set of classes. The common operations of accepting money and selecting a product would be relegated to a Vending Machine class, and the product specific behavior--dispensing coffee or candy--would be relegated to different specialized versions of the Vending machine class.
![Inheritance hierarchy in the AWT [click to enlarge]](hierarchy_sm.gif)
You might wonder how this applies to software. In object-oriented software, the classes you use tend to be related via an inheritance hierarchy, such as that shown for the JDK in the illustration. [Click image to enlarge]. Such inheritance hierarchies have several advantages:
- For object users: Once you learn how to move or resize a Button, for instance, you know how to move and resize any of the AWT components, because that behavior is part of the Component class.
- For object creators: You no longer have to "reinvent the wheel." If you can find an object that does most of what you want, all you have to do is write the code that does your specialized piece of the job. You get the other stuff for free.
Of course, if you're past the age of eight, you realize that nothing is "free." There are costs implicit in OO systems based around inheritance as well as benefits. Many of these costs are as yet unknown. One drawback, however, is fairly obvious; inheritance-based systems are more highly coupled than systems built using composition. It is quite easy to create an OO system using inheritance, where one change to a superclass ripples through layers of subclasses, wreaking havoc in its wake.
Something to Talk About
Here are two short articles I think you'll enjoy. First read the article by Fred Brooks "No Silver Bullet", then read the article "What If There is a Silver Bullet?" by Brad Cox. [Brooks and Cox are both brilliant and justifiably lionized] Which do you think was most convincing? Why?
Please continue to the next section of this lesson.
|
![Inheritance hierarchy in the AWT [click to enlarge]](hierarchy_lg.gif)