Mysql, Java, Jsp, Servlet, Tomcat, Ssh, Shared Web Hosting Blog

Chapter 9 Object-Oriented Programming 529 Reading a set of subclass declarations can be confusing, because inherited superclass members are not listed in the subclass declarations, but these members are indeed present in the subclasses. With polymorphism, it becomes possible to design and implement systems that are more extensible. Programs can be written to process objects of types that may not exist when the program is under development. Polymorphic programming can eliminate the need for switch logic, thus avoiding the kinds of errors associated with switchlogic. An abstract method is declared by preceding the method s definition with the keyword abstractin the superclass. There are many situations in which it is useful to define classes for which the programmer never intends to instantiate any objects. Such classes are called abstract classes. Because these are used only as superclasses, typically they are called abstract superclasses. A program cannot instantiate objects of an abstract class. Classes from which a program can instantiate objects are called concrete classes. A class is made abstract by declaring it with the keyword abstract. If a subclass is derived from a superclass with an abstract method without supplying a definition for that abstract method in the subclass, that method remains abstract in the subclass. Consequently, the subclass is also an abstract class. When a request is made through a superclass reference to use a method, Java chooses the correct overridden method in the subclass associated with the object. Through the use of polymorphism, one method call can cause different actions to occur, depending on the type of the object receiving the call. Although we cannot instantiate objects of abstract superclasses, we can declare references to abstract superclasses. Such references can then be used to enable polymorphic manipulations of subclass objects when such objects are instantiated from concrete classes. New classes are regularly added to systems. New classes are accommodated by dynamic method binding (also called late binding). The type of an object need not be known at compile time for a method call to be compiled. At execution time, the appropriate method of the receiving object is selected. With dynamic method binding, at execution time the call to a method is routed to the method version appropriate for the class of the object receiving the call. When a superclass provides a method, subclasses can override the method, but they do not have to override it. Thus a subclass can use a superclass s version of a method. An interface definition begins with the keyword interface and contains a set of publicabstract methods. Interfaces may also contain publicstaticfinal data. To use an interface, a class must specify that it implements the interface and that class must define every method in the interface with the number of arguments and the return type specified in the interface definition. An interface is typically used in place of an abstract class when there is no default implementation to inherit. When a class implements an interface, the same is a relationship provided by inheritance applies. To implement more than one interface, simply provide a comma-separated list of interface names after keyword implements in the class definition. Inner classes are defined inside the scope of other classes. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

528 Object-Oriented Programming Chapter 9 SUMMARY One of the keys to the power of object-oriented programming is achieving software reusability through inheritance. Through inheritance, a new class inherits the instance variables and methods of a previously defined superclass. In this case, the new class is referred to as a subclass. With single inheritance, a class is derived from one superclass. With multiple inheritance, a subclass inherits from multiple superclasses. Java does not support multiple inheritance, but Java does provide the notion of interfaces, which offer many of the benefits of multiple inheritance. A subclass normally adds instance variables and methods of its own, so a subclass generally is larger than its superclass. A subclass represents a smaller set of more specific objects than its superclass. A subclass cannot access the private members of its superclass. A subclass can, however, access the public, protected and package access members of its superclass. The subclass must be in the superclass s package to use superclass members with package access. A subclass constructor always calls the constructor for its superclass first (either explicitly or implicitly) to create and initialize the subclass members inherited from the superclass. Inheritance enables software reusability, which saves time in development and encourages the use of previously proven and debugged high-quality software. An object of a subclass can be treated as an object of its corresponding superclass, but the reverse is not true. A superclass exists in a hierarchical relationship with its subclasses. When a class is used with the mechanism of inheritance, it becomes either a superclass that supplies attributes and behaviors to other classes or a subclass that inherits those attributes and behaviors. An inheritance hierarchy can be arbitrarily deep within the physical limitations of a particular system, but most inheritance hierarchies have only a few levels. Hierarchies are useful for understanding and managing complexity. With software becoming increasingly complex, Java provides mechanisms for supporting hierarchical structures through inheritance and polymorphism. Modifier protected serves as an intermediate level of protection between public access and private access. Superclass protected members may be accessed by methods of the superclass, by methods of subclasses and by methods of classes in the same package. A superclass may be either a direct superclass or an indirect superclass. A direct superclass is the class that a subclass explicitly extends. An indirect superclass is inherited from several levels up the class hierarchy tree. When a superclass member is inappropriate for a subclass, the programmer must override that member in the subclass. In a has a relationship, a class object has a reference to an object of another class as a member. In an is a relationship, an object of a subclass type may also be treated as an object of the superclass type. Is a is inheritance. Has a is composition. A reference to a subclass object may be converted implicitly to a reference for a superclass object. It is possible to convert a superclass reference to a subclass reference by using an explicit cast. If the target object is not a subclass object, a ClassCastException is thrown. A superclass specifies commonality. All classes derived from a superclass inherit the capabilities of that superclass. In the object-oriented design process, the designer looks for commonality among classes and factors it out to form superclasses. Then, subclasses are customized beyond the capabilities inherited from the superclass. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 527 Design Patterns www.hillside.net/patterns This page displays links to information on design patterns and languages. www.hillside.net/patterns/books/ This site lists books on design patterns. www.netobjectives.com/design.htm This site introduces the importance of design patterns. umbc7.umbc.edu/~tarr/dp/dp.html This site links to design patterns Web sites, tutorials and papers. www.links2go.com/topic/Design_Patterns This site links to sites and information on design patterns. www.c2.com/ppr/ This site discusses recent advances in design patterns and ideas for future projects. Design Patterns in Java www.research.umbc.edu/~tarr/cs491/fall00/cs491.html This site is for a Java design patterns course at the University of Maryland and contains numerous examples of how to apply design patterns in Java. www.enteract.com/~bradapp/javapats.html This site discusses Java design patterns and presents design patterns in distributed computing. www.meurrens.org/ip-Links/java/designPatterns/ This site displays numerous links to resources and information on Java design patterns. Design Patterns in C++ & Visual Basic journal.iftech.com/articles/9904_shankel_patterns/ This site provides insight to design patterns (the Iterator design pattern, in particular) in C++. mspress.microsoft.com/prod/books/sampchap/2322.htm This site overviews the book, Microsoft Visual Basic Design Patterns (Microsoft Press: 2000). Architectural Patterns compsci.about.com/science/compsci/library/weekly/aa030600a.htm This site provides an overview the Model-View-Controller architecture. www.javaworld.com/javaworld/jw-04-1998/jw-04-howto.html This site contains an article discussing how Swing components use Model-View-Controller architecture. www.ootips.org/mvc-pattern.html This site provides information and tips on using MVC. www.ftech.co.uk/~honeyg/articles/pda.htm This site contains an article on the importance of architectural patterns in software. www.tml.hut.fi/Opinnot/Tik-109.450/1998/niska/sld001.htm This site provides information on architectural patterns, design pattern, and idioms (patterns targeting a specific language). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

526 Object-Oriented Programming Chapter 9 tor, first floor or second floor of that person. Because a superclass reference can hold a subclass reference, the person s Location attribute references the appropriate Floor object when that person is on a floor and references the Elevator object when that person is inside the elevator. The elevator and floors contain buttons. (The elevator s button signals the elevator to move to the other floor, and the floors buttons summon the elevator to the floor of the request.) Because all locations in our simulation contain buttons, class Location provides abstract method getButton. Class Elevator implements method getButton to return a reference to the Button object inside the elevator, and class Floor implements method getButton to return a reference to the Button object on the floor. Using its Locationreference, the person is able to press the correct button i.e., the person will not press a floor s button when inside the elevator and will not press the elevator s button when on a floor. The State design pattern uses an abstract superclass called the State class which contains methods that describe behaviors for states that an object (called the context object) can occupy. In our elevator simulation, the State class is superclass Location, and the context object is the object of class Person. Note that class Location does not describe all states of class Person (e.g., whether that person is walking or waiting for the elevator) class Location describes only the location the Person and contains method getButtonso the Person can access the Button object at various locations. A State subclass, which extends the State class, represents an individual state that the context can occupy. The State subclasses in our simulation are classes Elevator and Floor. Each State subclass contains methods that implement the State class abstract methods. For example, both classes Elevator and Floor implement method get- Button. The context contains exactly one reference to an object of the State class this reference is called the state object. In the simulation, the state object is the object of class Location. When the context changes state, the state object references the State subclass object associated with that new state. For example, when the person walks from the floor into the elevator, the Person object s Location is changed from referencing one of the Floor objects to referencing the Elevator object. When the person walks onto the floor from the elevator, the Person object s Location references the appropriate Floor object. 9.24.4 Conclusion In Discovering Design Patterns Section 9.24, we listed the three types of design patterns introduced in the gang-of-four book, we identified 18 of these design patterns that we discuss in this book and we discussed specific design patterns, including Singleton, Proxy, Memento and State. In Discovering Design Patterns Section 13.18, we introduce some design patterns associated with AWT and Swing GUI components. After reading this section, you should understand better how Java GUI components take advantage of design patterns. 9.24.5 Internet and World-Wide-Web Resources The following URLs provide further information on the nature, importance and applications of design patterns. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 525 Mediator (not discussed) Memento (Section 9.24) Observer (Section 13.18) State (Section 9.24) Strategy (Section 13.18) Template Method (Section 13.18) Visitor (not discussed) Memento Consider a painting program. This type of program allows a user to create graphics. Occasionally the user may position a graphic improperly in the drawing area. Painting programs offer an undo feature that allows the user to unwind such an error. Specifically, the program restores the drawing area s state to that before the user placed the graphic. More sophisticated painting programs offer a history, which stores several states in a list, so the user can restore the program to any state in the history.The Memento design pattern allows an object to save its state, so that if necessary the object can be restored to its former state. The Memento design pattern requires three types of objects. The originator object occupies some state the set of attribute values at a specific time in program execution. In our painting-program example, the drawing area acts as the originator, because it contains attribute information describing its state when the program first executes, the area contains no elements. The memento object stores a copy of all attributes associated with the originator s state i.e., the memento saves the drawing area s state. The memento is stored as the first item in the history list, which acts as the caretaker object the object that contains references to all memento objects associated with the originator. Now, suppose the user draws a circle in the drawing area. The area contains different information describing its state a circle object centered at specified x-y coordinates. The drawing area then uses another memento to store this information. This memento is stored as the second item in the history list. The history list displays all mementos on screen, so the user can select which state to restore. Suppose the user wishes to remove the circle if the user selects the first memento from the list, the drawing area uses the first memento to restore itself to a blank area. State In certain designs, we must convey an object s state information or represent the various states that an object can occupy. Our optional elevator simulation case study in the Thinking About Objects sections uses the State design pattern. Our simulation includes an elevator that moves between floors in a two-story building. A person walks across a floor and rides the elevator to the other floor. Originally, we used an integer value to represent on which floor the person is walking. However, we encountered a problem when we tried to answer the question on what floor is the person when riding the elevator? Actually, the person is located on neither floor rather the person is located inside the elevator. We also realized that the elevator and the floors are locations that the person can occupy in our simulation. We created an abstract superclass called Location to represent a location. Subclasses Elevator and Floor inherit from superclass Location. Class Person contains a reference to a Locationobject, which represents the current location eleva Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

524 Object-Oriented Programming Chapter 9 Adapter (Section 13.18) Bridge (Section 13.18) Composite (Section 13.18) Decorator (Section 17.10) Facade (Section 17.10) Flyweight (not discussed) Proxy (Section 9.24) Proxy An applet should always display something while images load. Whether that something is a smaller image or a string of text informing the user that the images are loading, the Proxy design pattern can be applied to achieve this effect. This pattern allows one object to act as a replacement for another. Consider loading several large images (several megabytes) in a Java applet. Ideally, we would like to see these images instantaneously however, loading large images into memory can take time to complete (especially on a slow processor). The Proxy design pattern allows the system to use one object called a proxy object in place of another. In our example, the proxy object could be a gauge that informs the user of what percentage of a large image has been loaded. When this image finishes loading, the proxy object is no longer needed the applet can then display an image instead of the proxy. 9.24.3 Behavioral Design Patterns There are many different examples of behavioral design patterns, which provide proven strategies to model how objects collaborate with one another in a system and offer special behaviors appropriate for a wide variety of applications. Let us consider the Observer behavioral design pattern a classic example of a design pattern illustrating collaborations between objects. For example, GUI components collaborate with their listeners to respond to user interactions. GUI components use this pattern to process user interface events. A listener observes state changes in a particular GUI component by registering to handle that GUI component s events. When the user interacts with that GUI component, the component notifies its listeners (also known as its observers) that the GUI component s state has changed (e.g., a button has been pressed). Another pattern we consider is the Memento behavioral design pattern an example of offering special behavior for a wide variety of applications. The Memento pattern enables a system to save an object s state, so that state can be restored at a later time. For example, many applications provide an undo capability that allows users to revert to previous versions of their work. The gang-of-four book describes 11 behavioral design patterns (eight of which we discuss in this book): Chain-of-Responsibility (Section 13.18) Command (Section 13.18) Interpreter (not discussed) Iterator (Section 21.12) Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 523 19 // instantiate Singleton if null 20 if ( singleton == null ) 21 singleton = new Singleton(); 23 return singleton; 24 } 25 } Fig. 9.42 Class Singletonensures that only one object of its class is created (part 2 of 2). 1 // SingletonExample.java 2 // Attempt to create two Singleton objects 3 package com.deitel.jhtp4.designpatterns; 4 5 public class SingletonExample { 6 7 // run SingletonExample 8 public static void main( String args[] ) 9 { 10 Singleton firstSingleton; 11 Singleton secondSingleton; 12 13 // create Singleton objects 14 firstSingleton = Singleton.getSingletonInstance(); 15 secondSingleton = Singleton.getSingletonInstance(); 16 17 // the “two” Singletons should refer to same Singleton 18 if ( firstSingleton == secondSingleton ) 19 System.out.println( “firstSingleton and ” + 20 “secondSingleton refer to the same Singleton ” + 21 “object” ); 22 } 23 } Fig. 9.43 Class SingletonExampleattempts to create Singletonobject more than once. Fig. 9.44 Class SingletonExampleoutput shows that the Singleton object may be created only once. 9.24.2 Structural Design Patterns Structural design patterns describe common ways to organize classes and objects in a system. The gang-of-four book describes seven structural design patterns (six of which we discuss in this book): Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

522 Object-Oriented Programming Chapter 9 Factory Method (Section 13.18) Prototype (Section 21.12) Singleton (Section 9.24) Singleton Occasionally, a system should contain exactly one object of a class that is, once the program instantiates that object, the program should not be allowed to create additional objects of that class. For example, some systems connect to a database using only one object that manages database connections, which ensures that other objects cannot initialize unnecessary connections that would slow the system. The Singleton design pattern guarantees that a system instantiates a maximum of one object of a class. Figure 9.42 demonstrates Java code using the Singleton design pattern. Line 5 declares class Singletonas final, so methods in this class cannot be overridden to handle multiple instantiations. Lines 11 14 declare a privateconstructor only class Singleton can instantiate a Singleton object using this constructor. The static method getSingletonInstance(lines 17 24) allows the one-time instantiation of a static Singletonobject (declared on line by calling the privateconstructor. If the Singleton object has been created, line 23 merely returns a reference to the previously instantiated Singletonobject. Lines 10 11 of class SingletonExample (Fig. 9.43) declare two references to Singletonobjects firstSingletonand secondSingleton. Lines 14 15 call method getSingletonInstance and assign Singleton references to firstSingletonand secondSingleton, respectively. Line 18 tests if these objects reference the same Singleton object. Figure 9.44 shows that firstSingleton and secondSingleton share the same reference to the Singleton object, because each time method getSingletonInstance is called, it returns a reference to the same Singletonobject. 1 // Singleton.java 2 // Demonstrates Singleton design pattern 3 package com.deitel.jhtp4.designpatterns; 4 5 public final class Singleton { 6 7 // Singleton object returned by method getSingletonInstance 8 private static Singleton singleton; 9 10 // constructor prevents instantiation from other objects 11 private Singleton() 12 { 13 System.err.println( “Singleton object created.” ); 14 } 15 16 // create Singleton and ensure only one Singleton instance 17 public static Singleton getSingletonInstance() 18 { Fig. 9.42 Class Singletonensures that only one object of its class is created (part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 521 Section Creational design patterns Structural design patterns Behavioral design patterns 13.18 Factory Method Adapter Chain-of-Responsibility Bridge Command Composite Observer Strategy Template Method 17.10 Abstract Factory Decorator Facade 21.12 Prototype Iterator Fig. 9.40Fig. 40 The 18 Gang-of-four design patterns discussed in Java How to Program 4/e (part 2 of 2). Section Concurrent design patterns Architectural patterns 15.13 Single-Threaded Execution Guarded Suspension Balking Read/Write Lock Two-Phase Termination 17.10 Model-View-Controller Layers Fig. 9.4141 Concurrent design patterns and architectural patterns discussed in Java Fig. How to Program, 4/e. 9.24.1 Creational Design Patterns Creational design patterns address issues related to the creation of objects, such as preventing a system from creating more than one object of a class (the Singleton creational design pattern) or deferring until execution time the decision as to what types of objects are going to be created (the purpose of the other creational design patterns discussed here). For example, suppose we are designing a 3-D drawing program, in which the user can create several 3-D geometric objects, such as cylinders, spheres, cubes, tetrahedrons, etc. At compile time, the program does not know what shapes the user will choose to draw. Based on user input, this program should be able to determine the class from which to instantiate an object. If the user creates a cylinder in the GUI, our program should know to instantiate an object of class Cylinder. When the user decides what geometric object to draw, the program should determine the specific subclass from which to instantiate that object. The gang-of-four book describes five creational patterns (four of which we discuss in this book): Abstract Factory (Section 17.10) Builder (not discussed) Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

520 Object-Oriented Programming Chapter 9 // method overriding getButton public Button getButton() {} { return elevatorButton; } // method overriding getDoor public Door getDoor() {} { return elevatorDoor; } } Using forward engineering provides a sound beginning for code implementation in any language. Thinking About Objects Section 11.10 returns to interactions and focuses on how objects generate and handle the messages passed in collaborations. In addition, we forward engineer more class diagrams to implement these interactions. Eventually, we present the Java code for our simulator in Appendix G, Appendix H and Appendix I. 9.24 (Optional) Discovering Design Patterns: IntroducingCreational, Structural and Behavioral Design Patterns Now that we have introduced object-oriented programming, we begin our deeper presentation of design patterns. In Section 1.17, we mentioned that the gang of four described 23 design patterns using three categories creational, structural and behavioral. In this and the remaining Discovering Design Patterns sections, we discuss the design patterns of each type and their importance, and we mention how each pattern relates to the Java material in the book. For example, several Java Swing components that we introduce in Chapters 12 and 13 use the Composite design pattern, so we introduce the Composite design pattern in Section 13.18. Figure 9.40 identifies the 18 gang-of-four design patterns discussed in this book. Figure 9.40 lists 18 of the most widely used patterns in the software-engineering industry. There are many popular patterns that have been documented since the gang-offour book these include the concurrent design patterns, which are especially helpful in the design of multithreaded systems. Section 15.13 discusses some of these patterns used in industry. Architectural patterns, as we discuss in Section 17.10, specify how subsystems interact with each other. Figure 9.41 specifies the concurrency patterns and architectural patterns that we discuss in this book. Section Creational design patterns Structural design patterns Behavioral design patterns 9.24 Singleton Proxy Memento State Fig. 9.4040 The 18 Gang-of-four design patterns discussed in Java How to Program Fig. 4/e (part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01