CS112 Lecture: Reuse, Packages, Patterns

Transcription

1 CS112 Lecture: Reuse, Packages, Patterns Revised 4/20/05 Objectives: 1. To introduce the idea of re-use 2. To introduce some characteristics that make classes re-usable 3. To introduce Java packages. 4. To introduce the notion of patterns 5. To introduce the MVC Architectural pattern and the Observer Design pattern Materials: 1. Javadoc of javax.swing.joptionpane to project 2. Project 4 web site 3. MVC Spreadsheet Example 4. Gang of Four book I. Introduction A. One of the key ideas in modern software engineering is the idea of re-use - rather than building every software system from scratch, making as much use as possible of work that has been done previously. 1. This is quite common in other fields a) Example: when an architect designs a building, the overall structure of the building may be unique, but it makes use of standard components such as doors, windows, heating units, floor coverings, ceiling tiles, roof designs, etc. b) Example: mechanical engineers seldom design screws and nuts as part of systems they develop - they make use of existing off the shelf components. 2. Historically, this has not been nearly as typical of software. Many software systems are designed almost entirely from scratch.. a) Obviously, this results in increased costs and longer project times. b) It also results in decreased reliability, because software that is re-used typically has already had many of the errors in it discovered and corrected. 1

2 B. In OO systems, the basic unit of re-use is the class. We want to design our classes in such a way as to maximize the possibility of re-using them in other systems. Today, we will look at some factors that contribute to reusability of classes. II. Generality A. One thing that increases the likelihood of being able to re-use a class is giving some attention to making it as general as possible when it is first designed. B. Frequently, this takes the form of incorporating key values as settable instance variables, rather than wiring them in. EXAMPLE: The showconfirmdialog() method of JOptionPane, which allows you to specify how many buttons you want and what their labels should be. SHOW Javadoc documentation 1. In Project 4, when you implement the dodelete() method of AddressBookController, you will want to use the 2 button version when asking the user to confirm deletion ( Yes or No ) 2. When you implement the dooffersavechanges() method, you will need to use the 3 button version ( Yes meaning to save changes, then perform the operation; No meaning to not save changes but perform the operation nonetheless - thus effectively discarding the changes; Cancel meaning don t do the original operation at all). C. It is also desirable to provide methods that provide flexibility to a user of the class. EXAMPLE: Again, the various show... Dialog methods of JOptionPane come in a number of different flavors. SHOW in Javadoc 1. Note that it is possible for a Java class to have two or more methods (including constructors) with the same name provided each has a different signature. a) The signature of a method consists of its name and the number and 2

3 types of its parameters (but not any modifiers or the names of the parameters or the type of the return value) (1) EXAMPLE: The following are different methods because they have different signatures: foo(int x) foo(float x) foo(int x, int y) (2) EXAMPLE: The following are not different methods: public int foo(int x) private int foo(int x) static int foo(int x) int foo(int y) float foo(int x) As a result, at most one of them could appear in a given class. (3) The term prototype is used to refer to the complete specification of the method - its modifiers, return type, and signature. EXAMPLE: Each of the above has a distinct prototype b) Note that the rule that two methods with the same name must have different signatures applies to methods of the same class. Two different classes may have methods with the same signature without problem. c) When a class has two methods with the same name but different signatures, we say that the method is overloaded. EXAMPLE: In the JOptionPane class, the constructor is overloaded, as is the showconfirmdialog() method. (Show in Javadoc) 2. Another example: the MultiInputPane class given to you for Project 4. a) Discuss various methods in Javadoc b) Show how they are implemented by projecting code - note how the 3

4 various convenience methods call the one basic method, and how the basic method is implemented. III. Cohesion and Coupling A. Two characteristics of a class that help to make it re-usable are that it has high cohesion internally and low coupling to other classes. B. A class has high cohesion when every feature of the class contributes to a single clearly defined purpose. (Wu calls this the STO - Single Task Object - principle). 1. It is tempting to design classes which perform multiple tasks. In such cases, the quality of the design - and the potential for re-use - can be increased by factoring the class into two or more classes, each of which has a single task. 2. EXAMPLE: The JList class in Swing. Every JList object is associated with another object - called its model - that contains the information it displays. SHOW: Code variables for AddressBookGUI for Project 4 - distinct variables for the list and its model. This distinction is made (in the design of Swing) because: a) If there are a lot of items, then at any given time, only a portion of the items are visible in the list - so there is a need to distinguish between the items that are displayed and the items that are present. Various operations (e.g. changing the size of the window or scrolling the list) affect what items are actually displayed, with no impact on the overall list itself. b) Changing the list of items in the model may or may not have any impact on the visible display - depending on whether or not the item that is changed is currently visible. c) The displayed list supports capabilities like size adjustment, scrolling, selecting an item etc, which are conceptually distinct from holding a list of items. C. Two classes exhibit high coupling when one one class depends on the other in such a way that changing one class requires changes to the other as well. What we want, of course, is low coupling, not high coupling. 4

5 1. Obviously, it is not possible, or desirable, to eliminate all coupling between classes - otherwise they could not work together at all. Some coupling between classes is inherent in their need to work together on a common task. However, unnecessary coupling is a barrier to re-use. 2. What we try to do is to achieve a controlled form of coupling that minimizes the inter-dependency D. One factor that contributes to producing classes with high cohesion and low coupling - and thus candidates that have a good chance of being reusable - is to recognize that objects in a program play different roles, and we should generally avoid asking an object to play several different roles. We discussed this earlier, but it is good to review it now. 1. An entity object is used to model a thing in (concrete or abstact) in the domain of the program, with methods providing operations on it. EXAMPLE: What kind(s) of objects fulfill this function in Project 4? ASK a) Person b) AddressBook c) Within the GUI, the namelistmodel Entity objects are excellent candidates for re-use - if a given class is a good model of a particular type of real-world entity, then it is a candidate for re-use in any program that deals with that entity. 2. A boundary object is used to manage interaction between the program and the outside world (human user or another system). EXAMPLE: The GUI for Project 4. Overall, it is a boundary object that is actually composed of many widgets, which are themselves boundary objects. (Specifically, the list of names is a JList; there are 5 buttons; there is a File menu with6 options (8 objects in all including the menu and the menubar). Individual component parts of a GUI are good candidates for re-use (e.g. 5

6 IV. Packages the various kinds of Component/JComponent in awt and Swing). The GUI as a whole, however, may be necessarily tied so closely to a given application as to not be re-usable. (That s ok, as long as we build it out of reusable components.) 3. A control object is used to manage the flow of computation, using the other objects. EXAMPLE: The AddressBookController object for Project 4 fulfills this role. A control object is usually so tied to the requirements of a particular application as to not be re-usable. Therefore, we try to factor as much as possible of the re-usable part of a task out of a controller to make it as small as possible. EXAMPLE: In Project 4, the controller has methods for sorting the AddressBook by name and by zip; but the actual logic for doing the sorting is in the AddressBook class, not the controller class, because these operations might prove useful in some other context where the AddressBook class is re-used. The logic in the controller object basically hands off the work to the entity object. SHOW in sequence diagram. 4. SHOW special symbols used in Analysis Class Diagram on web site 5. Note: Wu uses a slightly different categorization into user interface objects, controller objects, application logic objects, and storage objects. A. Ideally, we try to maximize the cohesion of classes we create and minimize their coupling to other classes. Sometimes, though there are groups of classes that work together so closely that a high degree of coupling is unavoidable and not really undesirable. EXAMPLE: The AddressBook and Person classes are like this. Some of the methods in AddressBook depend on knowing the specific kinds of information stored in a Person object. This is a perfectly reasonable and proper form of coupling. 6

7 B. When we have a group of classes that are closely related to one another - and cohesive among themselves as a group - we can put them in their own Java package. 1. We have already made extensive use of packages of classes - e.g. kareltherobot, javax.swing, and the various java. packages. 2. It is possible to create one s own package by including a package statement as the first statement in the source file for each class in it: package mypackage; import... Note: if you create your own packages, you should avoid names that can be confused with standard packages - e.g. your packages should never have names like java.anything. Commercial packages produced by various companies typically have names like com.company.something - e.g. the AddressBookApplication class uses some Macintosh-specific classes in the package com.apple.eawt. SHOW code for AddressBookApplication 3. The Java system requires that the package structure be mirrored by the directory structure, both for source files and for class files - e.g. a class Foo in package mypackage.stuff must have a source file called Foo.java and will produce a class file called Foo.class, both of which must reside in a folder called stuff in a folder called mypackage. package mypackage.stuff;... public class Foo... implies 7

8 mypackage stuff Foo. java Foo. class (Actually, you could use two separate folder hierarchies having the same structure - one for the sources and one for the classes.) C. Classes belonging to the same package have certain privileges with regard to one another. V. Patterns 1. A feature that has no visibility specified is accessible only to the class in which it occurs and other classes in the same package. 2. To be accessible to classes in a different package, a feature must have public visibility. 3. Note that a class that does not have a package statement is considered to belong to a top-level, unnamed package. Thus all classes that are not declared as being in a package effectively belong to the same package - the package that has no name. A. One idea that has gotten a lot of attention in recent years is the notion of patterns. Basically, a pattern represents the structure of a good solution to a commonly-occurring problem. What is re-used is not the specifics of some particular solution, but the overall structure of the solution. B. We have already met the notion of patterns at one level - the level of code patterns. Where have we seen these? ASK 8

9 When we talked about loops, we looked at several patterns - e.g. the priming the pump pattern, the input validation pattern. 1. Let s look again at the priming the pump pattern. 2. The basic problem this pattern addresses is the following: we have to process an unknown number of items. The last item is followed by a phony item called the sentinel, which is not to be processed, but rather serves as an indicator that all the real items have been seen. 3. This problem is tricky because we need to use a loop to process all the items. Inside the loop, we need to read an item before we can decide whether it is a real item or the sentinel, but we don t want to process it if it is the sentinel. 4. The solution is to read one item before entering the loop ( priming the pump ) and to read the next item at the end of the loop. read first item while (the item just read is not the sentinel) { process the item must read; read another item; } This gives us the desired behavior - we read one more item than we actually process (the sentinel), and the item we skip processing is the last item we read 5. Note that the pattern has a distinctive name ( priming the pump ) which allows us to talk about it. If you use this name in a conversation with any knowledgeable person, he/she will immediately know what you mean. C. But patterns can be used at other levels of design as well. Patterns that affect the overall structure of a system are often called Architectural patterns, and patterns that affect interaction between objects within a system are often called design patterns. Like code patterns, patterns at other levels tend to have a well-known name (or, unfortunately, sometimes several of them), which facilitates talking about them. D. An example of an architectural pattern: Model-View-Controller 1. The MVC pattern describes the overall structure of a system. It has three kinds of component part (each of which may involve multiple 9

10 objects/classes). a) The model part represents the information that is stored/manipulated by the system. Typically, the model is stored long-term. (1) Example: In Project 4, the address book is the model. It is composed of a single AddressBook object which typically contains multiple Person objects. (2) Example: in a spreadsheet program, the spreadsheet itself is the model. It is conceptually a two dimensional array of cells, each of which is either empty or is of one of several types (text, number, formula) Thus, we might have a class Spreadsheet and a base class Cell, with subclasses like TextCell, NumberCell, and FormulaCell. We might also have various graphs as part of the model. The specifications for each graph (what cells it includes, what its labels are, etc.) might be represented by an object of a class like GraphSpecifications. (3) Typically, the model is largely constructed from objects that belong to various entity classes. b) A view is a way of looking at the information that is presented to the user. (1) Example: In Project4, the GUI is the one and only view. It typically presents only a potion of the model (if there are more people than the name list can display). The portion that is displayed can be changed by scrolling the list. (2) Often, an application will provide multiple simultaneous views of the same model. The views are all linked to the same model, so that any change to the model will be reflected in all the (relevant) views. Example: MVC Example SS - showing a model plus three views - raw data, two graphs. Note how changing an item of raw data that appears in all views changes all three views; but if an item is not reflected in a particular view, then that view is unaffected. c) The controller part allows a user gesture in a view to impact the underlying model appropriately, which in turn may result in the view 10

11 being updated to reflect the changes to the model (1) Example: In Project 4, a user gesture such as clicking a button or choosing a menu option can result in a change to the model such as adding or removing a person, sorting the people, or creating an empty address book or opening an existing one. All of the above have an impact on the model. A user gesture can also initiate editing of a person, which has no direct impact on the view (since the person s name cannot be edited. (2) Example: in the spreadsheet, only the raw data view allows editing of data. But any change to the raw data can affect other views as well. (3) The reason distinguishing the controller from the views becomes more apparent in situation where it is possible to change the underlying model through more than one view - with the changes being reflected in all the views. Example: System Preferences / Appearance / Highlight color - choose other to get color picker. Note various views the color picker supports (though not simultaneously), and how a change to the color in one view affects all the others. (Set highlight color back to light blue at end!) (4) Not surprisingly, the controller portion of an application is generally constructed using control classes (plus sometimes entities as well.) 2. The MVC architectural pattern is appropriate to many applications, though certainly not all. Because is it so pervasive, the Java API includes some direct support for it, which we will discuss shortly. The API also itself uses this paradigm: for example, the relationship between the visible display of a list and the underlying model reflected in the design of the Swing class JList. E. By far the most common level at which patterns are found is at the Design Level - hence Design Patterns. There are scores of well-known patterns. We will look at only one here, which is very relevant to the MVC architecture and is used in your project 4. (We talk about others in CS211). 1. The standard book on Design Patterns is a book titled Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (colliquially called the Gang of Four book ). In 11

12 the introduction, the authors describe the notion of a design pattern this way: Design patterns capture solutions that have developed and evolved over time. Hence they aren t the designs people tend to generate initially. They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form. (page xi) 2. When describing a design pattern, it is common to introduce it in terms of its Motivation (what problem it is intended to solve). The example pattern we will discuss is one called the Observer Pattern. The Gang of four book introduces it with the following Motivation: A common side effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects You don t want to achieve consistency by making the classes tightly coupled, because that reduces their reusability. For example, many graphical user interface toolkits separate the presentational aspect of the user interface [ called the view in MVC ] from the underlying application data [ called the model in MVC ]... (page 293) The Observer pattern describes how to establish these relationships. The key objects in this pattern are the subject and the observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change of state. In response, each observer will query the subject to synchronize its state with the subject s state. (page 294) 3. Java provides support for this pattern in the form of the class java.util.observable (which is used for what the description I just read called the subject) and the interface java.util.observer. The subject class extends java.util.observable. The observer class implements java.util.observable. a) An Observer registers itself with an Observable by calling the addobserver() method of the Observable. SHOW in code for AddressBookGUI, method setaddressbook(). This registers a desire on the observer s part to be notified whenever the subject changes. (The observer will then query the subject to find out about its new state in order to update its own state appropriately.) 12

13 b) Whenever the subject undergoes a change, it calls the methods setchanged() and notifyobservers(). This requirement is behind the note in the project handout that asks you to add code to these call these methods to the setfile() and setchangedsincelastsaved() methods of class AddressBook. c) This method (which is inherited from the base class java.util.observable then causes the update() method of each registered observer to be called. SHOW in code for AddressBookGUI, method update(). NOTE that this method updates the grayed out status of the Save menu option, and the title displayed in the title bar of the window. (They are always updated, even though they may not have changed - there is no simple way to know what s changed.) d) In this particular example, we are not using this mechanism to handle changes to the actual content or ordering of the address book. Instead, we are using it with the namelistmodel that is behind the list. SHOW in code for AddressBookGUI, methods corresponding to the add, delete, and sort buttons. (The pattern is used internally by the Swng classes JList and ListModel.) 13