Previous Page Next Page

Chapter 11
OBJECT-ORIENTED DEVELOPMENT

The tutorials so far have shown you many strengths of the Smalltalk/V language and programming environment. Chapters 11 and 12 are about Smalltalk/V application development--the "how" rather than the "what" of OOPS. In Chapter 11, you learn the OOPS application development cycle, a methodology which guides you in designing and implementing your own Smalltalk/V applications. The process is demonstrated through a simple but complete example.

After working through the phone book example in this chapter, you will be ready for the more complex application in Chapter 12. There, a multi-window, multi-pane application involving state-transition data management is developed using Smalltalk/V in a case study of the development of an office information system.

The Smalltalk/V Application Development Cycle

Smalltalk/V application development involves defining objects, their interrelationships and their behavior. Together with the Smalltalk/V environment, these problem solving techniques support an incremental and evolutionary approach to software development.

The Smalltalk/V application development process can be generally divided into six phases:

State the Problem

Begin your Smalltalk/V application development project by making as explicit and cogent a problem statement as possible, describing what you are trying to get your software to do. For example:

As you think through and learn more about your problem, you can return to the problem statement to qualify or extend it, refining application goals as you go along. The purpose here is to have a short, understandable statement of the problem which points toward the kind of software solution that will address your need.

Your problem statement, like your Smalltalk/V application, will evolve. The act of bringing your initial design ideas to life will generate insights that enhance your appreciation for the original problem.

Draw the Window

Armed with your problem statement, ask yourself what a new window that helps solve your problem looks like, then draw it. Don't worry about the internal workings of the application and data structures involved. Concentrate on the appearance and interaction. What does the application look like? How does it behave? What existing Smalltalk/V windows have you seen that suggest an approach?

Figure 11.1
PhoneBook Window Model

Figure 11.1 shows a proposed phone book window and new phone book menu for the window's menu bar. Having an idea of the number, size and contents of the panes of the window in your application is obviously helpful, but thinking through the menu selections makes things come to life. Menu items are the means for you as user-object to send messages to your application which is, after all, a Smalltalk/V object.

You have now transformed your problem statement into a concrete window to be built. The drawing is a specification of the application user interface and is the starting point for specifying the rest of the application.

The next three phases consist of identifying classes, object states and object interfaces. They are by nature interrelated. Although they are described sequentially, it may be more productive to perform them in parallel or iteratively.

Identify the Classes

Knowing as much as you can about your problem and having a sketch of the application interface, you are ready to identify the classes of objects that implement the application. List both the new classes defined for the application and existing classes from the Smalltalk/V class hierarchy to be used. New classes will be either self-standing (a subclass of class Object), or a subclass of an existing class that implements some of the behavior needed by the new class. Existing classes used will generally include user interface classes (Menu, Window, and Window's subclasses), and subclasses of Collection, Magnitude and Stream.

In our example, we need a new ViewManager subclass, PhoneBook, whose instances are fully functional phone books. A menu and panes appear in your window sketch, so classes Menu, ListPane and TextPane are needed. After some consideration, it seems that a Dictionary is most appropriate for associating names with telephone numbers, and names and telephone numbers will be represented as Strings.

The classes identified so far seem like a natural breakdown of the problem statement and the window picture. But what if the choices aren't so obvious? It's important to make some choice, even if it's not the best. You may be wrong, but with an environment that allows you to make changes easily, you can change to better ones later. Any kind of progress on the application will enhance your understanding of the appropriate classes to be used.

Describe the Object States

Given the problem statement, the window drawing and the classes to be used, what instance variables are needed in the new classes you have defined? In this example, our only new class is PhoneBook, which is the application window class. No separation of the window class and an abstract related application class is needed. This entire simple application is contained in the class which also defines the application's window.

What state is appropriate to put in a phone book object? The standard window and pane classes already keep track of most of the states associated with the window. The window, an instance of class PhoneBook, needs the application specific data, which in this case are (1) the dictionary of phone numbers phones and (2) the name from the selected list pane entry selectedName. Look in file chapter.11 to see the resulting class definition.

Are there general rules for deciding what instance variables to use? The best guide is to look ahead to the object interface. What kind of questions (messages) will the object be asked? What will be the object's behavior?

List the Object Interfaces

Object interfaces are the messages that the object responds to. List the messages that the new classes must implement. A good starting point for this is to augment the window drawing with the messages that will be used for each pane.

Figure 11.2
PhoneBook Window

with Messages

In Figure 11.2, the message names are circled. In general, messages are used for (1) accessing non-standard menus defined by the application, (2) accessing the contents of panes for display purposes, (3) saving the contents of changed panes, (4) carrying out menu selections, and (5) opening the window. In our example we have the following:

Message Purpose

add Add a new name to phone book.

list: aListpane Fill aListPane with the names of people in the phone book.

listMenu: aListPane Set the name list menu.

nameSelected: aListPane Display the phone number for the just selected name in aListPane.

openOn: aDictionary Open a phone book window for aDictionary.

remove Remove selected name from phone book.

text: aTextPane Set the contents of aTextPane to the phone number for the selected name.

textFrom: aTextPane Get contents of the text pane as the phone number for the selected name and enter into dictionary.

Implement the Methods

All that remains to do is to implement the methods. A good starting point for a window application is to do the window opening message (in our case, openOn:). This method is generally the largest in your application. Here it is for the phone book:

openOn: aDictionary
"Open a phone book window on aDictionary.  Define the pane 
sizes and behavior, and open the window."
phones := aDictionary.
self label: 'Phone Book '. 
self addSubpane:
(ListPane new
when: #getMenu perform: #listMenu: ; 
owner: self;
when: #getContents perform: #list: ; 
when: #select perform: #nameSelected: ; 
framingRatio: (Rectangle leftTopUnit 
   extentFromLeftTop: 1/3 @ 1 ) ).
self addSubpane:
(TextPane new
owner: self; 
when: #getContents perform: #text: ; 
when: #save perform: #textFrom: ;  
framingRatio: ( ( Rectangle leftTopUnit 
      rightAndDown: 1/3 @ 0)  extentFromLeftTop: 2/3 @ 1 ) ).
   self openWindow

All open messages for a window are very similar. They generally initialize the window's instance variables, and create window panes by specifying the following for each pane:

The remaining methods for the phone book are small and are contained in the chapter.11 file. The following expression files in class PhoneBook.

(File pathName:'tutorial\chapter.11') fileIn; close

You will find it as the first expression in file chapter.11. To try it out, evaluate:

PhoneBook new openOn: Dictionary new

Knowing When to Stop

During the first round of a new application development project, you generally progress through the above six steps sequentially. Once you have your "first cut" at a proposed application, your increased understanding will generate new insights. You will find yourself jumping around the six steps in a non-sequential process. For instance, while writing a method you realize the need for a class instance variable which brings you back to state considerations.

Smalltalk/V's incremental compiling capabilities promote dynamic movement among these development steps. In fact, Smalltalk/V application development can be seductive. It is always easy to think about adding just a few more lines of code which will further polish the application's interface or performance. By design, Smalltalk/V is an open system; an application always has the potential for enhancement.

That is why it is important to refresh your memory as to the original design goals of your Smalltalk/V application development project. If the prototype meets your design criteria, stop. Use the application for a while and let experience guide subsequent enhancement.

What You've Now Learned

You have seen the Smalltalk/V application development cycle applied to a very simple example. You have seen that a Smalltalk/V application develops in a revolving process in which you:

The next chapter will showcase the Smalltalk/V application development cycle in a more involved case study. As always, if you want to review any of the topics covered in this tutorial, you can either repeat the corresponding section of the tutorial, or refer to the relevant topics in Part 3.

Previous Page Next Page