Previous | Table of Contents | Next |
5.2.2.2. Dependencies and Event Frameworks
Exceptions are part of the API that an object in Smalltalk provides; events and dependencies are another. The concept of dependencies has been in Smalltalk for some time, and the event frameworks that are a logical extension of the dependency mechanism have become very popular in the past few years.
The dependency mechanism allows for a loose coupling between two or more objects. When one object changes, it does not have to include specific processing to notify other programs about the change. Instead, the object can simply declare, Ive changed, and the mechanism notifies all the objects that have registered interest in the change.
For example, a class Person has an instance variable called lastName. When lastName changes in an instance of Person, an instance of GovernmentAgency might be interested. The instance of GovernmentAgency might express interest in the changes to Person by sending the message addDependent: to Person with an argument of self (the GovernmentAgency). When Person has a change to the lastName, it sends the message changed: anAspect to self (Person now), and then GovernmentAgency is notified. An example of a dependency relationship between Jonathan and Victoria is shown in Figure 5.3. In the example, Jonathan and Victoria are both dependents of each other. They want to know about all the events that occur with each other. They are also dependents of the publisher, and they want to know about the progress of the book.
FIGURE 5.3. Jonathan and Victoria are dependents of each other and the publisher, and they want to know about the progress of the book.
Another example of this mechanism at work is two views of the same object. One can be a data entry screen, and the other a graph. When changes are made on one screen, those changes are made to a common model object. This model object then says, Ive changed, and all the views that are interested are notified. This is model, view, controller (MVC) in action.
The MVC paradigm was born in Smalltalk and deals with the GUI (also born in Smalltalk). As shown in Figure 5.4, the model refers to a data object that holds information (such as Person). The view is the graphical representation of this information that is presented to the user. The controller is the combination of the mouse (another Smalltalk concept) position and state of buttons that takes input from the user and sends messages to the model and view objects. In essence, the view displays information to the user, the controller responds to user input, and the model is the functional part of the application.
FIGURE 5.4. In the original MVC, the view and controller know about each other and the model, but the model does not know about either of them.
This paradigm does not exist in the popular modern GUIs today. The view and controller have been merged into one entity, known as a control or widget. In VisualWorks, the paradigm is still present and is applied to single controls as well as entire windows. A new twist to the MVC paradigm that is gaining popularity involves the model as it is in Figure 5.4, but in which the view encompasses both the view and controller, and in which a new definition of controller allows a single view to be reused with different behavior. An example of this is a window that appears the same to a user at all times but has drastically different code behind it based on any criteria desired by the system designers. One common use is for one controller that allows editing and stores to a database, whereas another simply allows browsing of the information. The definition of the word controller varies in implementations of Smalltalk, although it is really just a general term. Because the native GUIs today combine the original view and controller into one item, the word controller represents an interfacing mechanism that allows the same view to behave differently in some circumstances. This is illustrated in Figure 5.5.
FIGURE 5.5. GUIs today combine the original view and controller into one item.
The event framework is a logical extension of the dependency mechanism. Each use of the event framework includes an aspect of interest as well as a receiver object and selector. When an object changes, it can execute code such as
self signalEvent: #lastName with: self lastName
which causes all registered handlers to be called. This contrasts with the simpler dependency model of any changed message from an object, causing the dependents update method to be called for every reason (not just the aspect of interest). The event framework can be useful in directing specific behavior between the two loosely coupled objects without a lot of conditional logic in the update method to determine what aspect changed and how to deal with it.
5.2.2.3. Reflective Capabilities of Smalltalk
One of the greatest features of working with Smalltalk is the ability to write programs that analyze and can create other programs. Most Smalltalk development environments include the capability to generate some portion of source code of a Smalltalk application, most commonly the GUI source code from an editor, but also mappings between objects and relational databases.
Other development environments and languages also include the capability to generate source code, but few include the capability to query the running application about program structure. For example, you can ask any object for its class by sending the message class to the object. Because classes are themselves instances of MetaClass, you also can send messages to the class to find out things such as the superclass, the entire superclass chain, the instance variables, the class variables, the class instance variables, each or any of the compiled methods, the selectors for each of the methods (method names), or anything else.
You also can create new types of system servicessuch as conversions between objects and relational data setsand use these properties to break encapsulation to insert information into an instance of a class. For example, you can use system services to check the validity of certain types of methods, check the stack for previously selected methods, and create new types of development tools, as discussed in section 5.2.2. You can even create programs that create additional programs (classes or methods) as they run, provided that you include the compiler in the deployed application.
The numerous features available in Smalltalk (combined with what is provided by vendors, third parties, and freeware) make Smalltalk a continual learning experience.
Previous | Table of Contents | Next |