Archive for September, 2007

482 Object-Oriented Programming Chapter (My web server) 9 16 17 //

Monday, September 17th, 2007

482 Object-Oriented Programming Chapter 9 16 17 // set PieceWorker’s wage 18 public void setWage( double wage ) 19 { 20 wagePerPiece = ( wage > 0 ? wage : 0 ); 21 } 22 23 // set number of items output 24 public void setQuantity( int numberOfItems ) 25 { 26 quantity = ( numberOfItems > 0 ? numberOfItems : 0 ); 27 } 28 29 // determine PieceWorker’s earnings 30 public double earnings() 31 { 32 return quantity * wagePerPiece; 33 } 34 35 public String toString() 36 { 37 return “Piece worker: ” + super.toString(); 38 } 39 40 } // end class PieceWorker Fig. 9.19 PieceWorkerextends abstractclass Employee(part 2 of 2). Class HourlyWorker (Fig. 9.20) is derived from Employee. The public methods include a constructor that takes a first name, a last name, a wage and the number of hours worked as arguments and passes the first name and last name to the Employee constructor; set methods to assign new values to instance variables wage and hours; an earnings method defining how to calculate an HourlyWorker s earnings; and a toString method that forms a String containing the type of the employee (i.e., “Hourly worker:”) followed by the hourly worker s name. 1 // Fig. 9.20: HourlyWorker.java 2 // Definition of class HourlyWorker 3 4 public final class HourlyWorker extends Employee { 5 private double wage; // wage per hour 6 private double hours; // hours worked for week 7 8 // constructor for class HourlyWorker 9 public HourlyWorker( String first, String last, 10 double wagePerHour, double hoursWorked ) 11 { 12 super( first, last ); // call superclass constructor 13 setWage( wagePerHour ); 14 setHours( hoursWorked ); 15 } Fig. 9.20 HourlyWorkerextends abstractclass Employee(part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 481 25 // set (Web server on xp)

Sunday, September 16th, 2007

Chapter 9 Object-Oriented Programming 481 25 // set CommissionWorker’s commission 26 public void setCommission( double itemCommission ) 27 { 28 commission = ( itemCommission > 0 ? itemCommission : 0 ); 29 } 30 31 // set CommissionWorker’s quantity sold 32 public void setQuantity( int totalSold ) 33 { 34 quantity = ( totalSold > 0 ? totalSold : 0 ); 35 } 36 37 // determine CommissionWorker’s earnings 38 public double earnings() 39 { 40 return salary + commission * quantity; 41 } 42 43 // get String representation of CommissionWorker’s name 44 public String toString() 45 { 46 return “Commission worker: ” + super.toString(); 47 } 48 49 } // end class CommissionWorker Fig. 9.18 CommissionWorkerextends abstractclass Employee(part 2 of 2). Class PieceWorker (Fig. 9.19) is derived from Employee. The public methods include a constructor that takes a first name, a last name, a wage per piece and a quantity of items produced as arguments and passes the first name and last name to the Employee constructor; set methods to assign new values to instance variables wagePerPiece and quantity; an earnings method defining how to calculate a PieceWorker s earnings; and a toStringmethod that forms a Stringcontaining the type of the employee (i.e., “Pieceworker:”) followed by the pieceworker s name. 1 // Fig. 9.19: PieceWorker.java 2 // PieceWorker class derived from Employee 3 4 public final class PieceWorker extends Employee { 5 private double wagePerPiece; // wage per piece output 6 private int quantity; // output for week 7 8 // constructor for class PieceWorker 9 public PieceWorker( String first, String last, 10 double wage, int numberOfItems ) 11 { 12 super( first, last ); // call superclass constructor 13 setWage( wage ); 14 setQuantity( numberOfItems); 15 } Fig. 9.19 PieceWorkerextends abstractclass Employee(part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

480 Object-Oriented Programming Chapter 9 20 // get (Web design templates)

Sunday, September 16th, 2007

480 Object-Oriented Programming Chapter 9 20 // get Boss’s pay 21 public double earnings() 22 { 23 return weeklySalary; 24 } 25 26 // get String representation of Boss’s name 27 public String toString() 28 { 29 return “Boss: ” + super.toString(); 30 } 31 32 } // end class Boss Fig. 9.17 Bossextends abstractclass Employee. Class CommissionWorker (Fig. 9.18) is derived from Employee. The public methods include a constructor that takes a first name, a last name, a salary, a commission and a quantity of items sold as arguments and passes the first name and last name to the Employee constructor; set methods to assign new values to instance variables salary, commission and quantity; an earnings method to calculate a Commission- Worker s earnings; and a toString method that forms a String containing the employee type (i.e., “Commissionworker:”) followed by the worker s name. 1 // Fig. 9.18: CommissionWorker.java 2 // CommissionWorker class derived from Employee 3 4 public final class CommissionWorker extends Employee { 5 private double salary; // base salary per week 6 private double commission; // amount per item sold 7 private int quantity; // total items sold for week 8 9 // constructor for class CommissionWorker 10 public CommissionWorker( String first, String last, 11 double salary, double commission, int quantity ) 12 { 13 super( first, last ); // call superclass constructor 14 setSalary( salary ); 15 setCommission( commission ); 16 setQuantity( quantity ); 17 } 18 19 // set CommissionWorker’s weekly base salary 20 public void setSalary( double weeklySalary ) 21 { 22 salary = ( weeklySalary > 0 ? weeklySalary : 0 ); 23 } 24 Fig. 9.18 CommissionWorkerextends abstractclass Employee(part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Web page design - Chapter 9 Object-Oriented Programming 479 21 // get

Saturday, September 15th, 2007

Chapter 9 Object-Oriented Programming 479 21 // get last name 22 public String getLastName() 23 { 24 return lastName; 25 } 26 27 public String toString() 28 { 29 return firstName + ‘ ‘ + lastName; 30 } 31 32 // Abstract method that must be implemented for each 33 // derived class of Employee from which objects 34 // are instantiated. 35 public abstract double earnings(); 36 37 } // end class Employee Fig. 9.16 Employeeabstractsuperclass (part 2 of 2). Class Boss (Fig. 9.17) is derived from Employee. The publicmethods include a constructor that takes a first name, a last name and a weekly salary as arguments and passes the first name and last name to the Employee constructor to initialize the firstName and lastName members of the superclass part of the subclass object. Other public methods include a setWeeklySalary method to assign a new value to private instance variable weeklySalary; an earnings method defining how to calculate a Boss s earnings; and a toString method that forms a String containing the type of the employee (i.e., “Boss:”) followed by the boss s name. 1 // Fig. 9.17: Boss.java 2 // Boss class derived from Employee. 3 4 public final class Boss extends Employee { 5 private double weeklySalary; 6 7 // constructor for class Boss 8 public Boss( String first, String last, double salary ) 9 { 10 super( first, last ); // call superclass constructor 11 setWeeklySalary( salary ); 12 } 13 14 // set Boss’s salary 15 public void setWeeklySalary( double salary ) 16 { 17 weeklySalary = ( salary > 0 ? salary : 0 ); 18 } 19 Fig. 9.17 Bossextends abstractclass Employee. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

478 Object-Oriented Programming Chapter (Web site design and hosting) 9 Software Engineering Observation

Friday, September 14th, 2007

478 Object-Oriented Programming Chapter 9 Software Engineering Observation 9.24 The ability to declare an abstract method gives the class designer considerable power over how subclasses will be implemented in a class hierarchy. Any new class that wants to inherit from this class is forced to override the abstract method (either directly or by inheriting from a class that has overridden the method). Otherwise, that new class will contain an abstract method and thus be an abstract class, unable to instantiate objects. Software Engineering Observation 9.25 An abstract can still have instance data and nonabstract methods subject to the normal rules of inheritance by subclasses. An abstract class can also have constructors. Common Programming Error 9.7 Attempting to instantiate an object of an abstract class (i.e., a class that contains one or more abstract methods) is a syntax error. Common Programming Error 9.8 It is a syntax error if a class with one or more abstract methods is not explicitly declared abstract. Let us consider the Employeeclass (Fig. 9.16). The publicmethods include a constructor that takes the first name and last name as arguments; a getFirstName method that returns the first name; a getLastName method that returns the last name; a toStringmethod that returns the first name and last name separated by a space; and an abstractmethod earnings. Why is this method abstract? The answer is that it does not make sense to provide an implementation of this method in the Employeeclass. We cannot calculate the earnings for a generic employee we must first know what kind of employee it is. By making this method abstract we are indicating that we will provide an implementation in each concrete subclass, but not in the superclass itself. 1 // Fig. 9.16: Employee.java 2 // Abstract base class Employee. 3 4 public abstract class Employee { 5 private String firstName; 6 private String lastName; 7 8 // constructor 9 public Employee( String first, String last ) 10 { 11 firstName = first; 12 lastName = last; 13 } 14 15 // get first name 16 public String getFirstName() 17 { 18 return firstName; 19 } 20 Fig. 9.16 Employeeabstractsuperclass (part 1 of 2). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Web host forum - Chapter 9 Object-Oriented Programming 477 certain uniformity. The

Friday, September 14th, 2007

Chapter 9 Object-Oriented Programming 477 certain uniformity. The write message sent to a device-driver object needs to be interpreted specifically in the context of that device driver and how that device driver manipulates devices of a specific type. However, the write call itself is really no different from the write to any other device in the system simply place some number of bytes from memory onto that device. An object-oriented operating system might use an abstract superclass to provide an interface appropriate for all device drivers. Then, through inheritance from that abstract superclass, subclasses are formed that all operate similarly. The capabilities (i.e., the public interface) offered by the device drivers are provided as abstract methods in the abstract superclass. The implementations of these abstract methods are provided in the subclasses that correspond to the specific types of device drivers. It is common in object-oriented programming to define an iterator class that can walk through all the objects in a collection (such as an array). If you want to print a list of objects in a linked list, for example, an iterator object can be instantiated that will return the next element of the linked list each time the iterator is called. Iterators are commonly used in polymorphic programming to walk through an array or a linked list of objects from various levels of a hierarchy. The references in such a list would all be superclass references (see Chapter 19, Data Structures, for more on linked lists). A list of objects of superclass class TwoDimensionalShape could contain objects from the classes Square, Circle, Triangle and so on. Sending a draw message to each object in the list would, using polymorphism, draw the correct picture on the screen. 9.16 Case Study: A Payroll System Using Polymorphism Let us use abstract classes, abstract methods and polymorphism to perform payroll calculations based on the type of employee (Fig. 9.16). We use an abstract superclass Employee. The subclasses of Employee are Boss(Fig. 9.17) paid a fixed weekly salary regardless of the number of hours worked, CommissionWorker (Fig. 9.18) paid a flat base salary plus a percentage of sales, PieceWorker (Fig. 9.19) paid by the number of items produced and HourlyWorker (Fig. 9.20) paid by the hour and receives overtime pay. Each subclass of Employeehas been declared final, because we do not intend to inherit from them again. An earnings method call certainly applies generically to all employees. But the way each person s earnings are calculated depends on the class of the employee, and these classes are all derived from the superclass Employee. So earnings is declared abstract in superclass Employee and appropriate implementations of earnings are provided for each of the subclasses. Then, to calculate any employee s earnings, the program simply uses a superclass reference to that employee s object and invokes the earnings method. In a real payroll system, the various Employeeobjects might be referenced by individual elements in an array of Employee references. The program would simply walk through the array one element at a time, using the Employee references to invoke the earnings method of each object. Software Engineering Observation 9.23 If a subclass is derived from a superclass with an abstract method, and if no definition is supplied in the subclass for that abstract method (i.e., if that method is not overridden in the subclass), that method remains abstract in the subclass. Consequently, the subclass is also an abstract class and must be explicitly declared as an abstract class. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

476 Object-Oriented Programming Chapter 9 regardless of the (Web design online)

Thursday, September 13th, 2007

476 Object-Oriented Programming Chapter 9 regardless of the object s type, so the new Mercurian objects just fit right in. Thus, with polymorphism, new types of objects not even envisioned when a system is created can be added without modifications to the system (other than the new class itself, of course). Through the use of polymorphism, one method call can cause different actions to occur, depending on the type of the object receiving the call. This gives the programmer tremendous expressive capability. We will see examples of the power of polymorphism in the next several sections. Software Engineering Observation 9.19 With polymorphism, the programmer can deal in generalities and let the execution-time environment concern itself with the specifics. The programmer can command a wide variety of objects to behave in manners appropriate to those objects without even knowing the types of those objects. Software Engineering Observation 9.20 Polymorphism promotes extensibility: Software written to invoke polymorphic behavior is written independent of the types of the objects to which messages (i.e., method calls) are sent. Thus, new types of objects that can respond to existing messages can be added into such a system without modifying the base system. Software Engineering Observation 9.21 If a method is declared final, it cannot be overridden in subclasses, so method calls may not be sent polymorphically to objects of those subclasses. The method call may still be sent to subclasses, but they will all respond identically rather than polymorphically. Software Engineering Observation 9.22 An abstract class defines a common interface for the various members of a class hierarchy. The abstract class contains methods that will be defined in the subclasses. All classes in the hierarchy can use this same interface through polymorphism. Although we cannot instantiate objects of abstract superclasses, we can declare references to abstract superclasses. Such references can be used to enable polymorphic manipulations of subclass objects when such objects are instantiated from concrete classes. Let us consider more applications of polymorphism. A screen manager needs to display a variety of objects, including new types of objects that will be added to the system even after the screen manager is written. The system may need to display various shapes (the superclass is Shape), such as Circle, Triangle and Rectangle. Each shape class is derived from superclass Shape. The screen manager uses superclass Shape references to manage the objects to be displayed. To draw any object (regardless of the level at which that object appears in the inheritance hierarchy), the screen manager uses a superclass reference to the object and simply sends a draw message to the object. Method draw has been declared abstract in superclass Shape and has been overridden in each of the subclasses. Each Shape object knows how to draw itself. The screen manager does not have to worry about what type each object is or whether the screen manager has seen objects of that type before the screen manager simply tells each object to draw itself. Polymorphism is particularly effective for implementing layered software systems. In operating systems, for example, each type of physical device could operate quite differently from the others. Even so, commands to read or write data from and to devices can have a Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Make a web site - Chapter 9 Object-Oriented Programming 475 We could have

Wednesday, September 12th, 2007

Chapter 9 Object-Oriented Programming 475 We could have an abstract superclass TwoDimensionalObject and derive concrete classes, such as Square, Circle, Triangle. We could also have an abstract superclass ThreeDimensionalObject and derive such concrete classes as Cube, Sphere and Cylinder. Abstract superclasses are too generic to define real objects; we need to be more specific before we can think of instantiating objects. For example, if someone tells you to draw the shape, what shape would you draw? Concrete classes provide the specifics that make it reasonable to instantiate objects. A class is made abstract by declaring it with keyword abstract. A hierarchy does not need to contain any abstract classes, but, as we will see, many good object-oriented systems have class hierarchies headed by abstract superclasses. In some cases, abstract classes constitute the top few levels of the hierarchy. A good example of this is the shape hierarchy in Fig. 9.3. The hierarchy begins with abstract superclass Shape. On the next level down we have two more abstract superclasses, namely TwoDimensionalShape and ThreeDimensionalShape. The next level down would start defining concrete classes for such two-dimensional shapes as Circle and Square and for such three-dimensional shapes as Sphere and Cube. 9.15 Polymorphism Examples Here is an example of polymorphism. If class Rectangle is derived from class Quadrilateral, then a Rectangle object is a more specific version of a Quadrilateral object. An operation (such as calculating the perimeter or the area) that can be performed on an object of class Quadrilateralcan also be performed on an object of class Rectangle. Such operations can also be performed on other kinds of Quadrilaterals, such as Squares, Parallelograms and Trapezoids. When a request is made through a superclass reference to use a method, Java chooses the correct overridden method polymorphically in the appropriate subclass associated with the object. Here is another example of polymorphism. Suppose we have a video game that manipulates objects of many varieties, including objects of class Martian, Venutian, Plutonian, SpaceShip, LaserBeam and the like. Each of these classes extends a common superclass, GamePiece, that contains a method called drawYourself. This method is defined by each subclass. A Java screen manager program would simply maintain some kind of collection (such as a GamePiece array) of references to objects of these various classes. To refresh the screen periodically, the screen manager would simply send each object the same message, namely drawYourself. Each object would respond in its own unique way. A Martian object would draw itself with the appropriate number of antennae. A SpaceShip object would draw itself bright and silvery. A LaserBeam object would draw itself as a bright red beam across the screen. Thus, the same message sent to a variety of objects would have many forms of results hence the term polymorphism. Such a polymorphic screen manager makes it especially easy to add new types of objects to a system with minimal impact. Suppose we want to add Mercurians to our video game. We certainly have to build a new class Mercurian that extends Game- Piece and provides its own definition of the drawYourself method. Then, when objects of class Mercurian appear in the collection, the screen manager need not be modified. It simply sends the message drawYourself to every object in the collection Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

474 Object-Oriented Programming (Cheapest web hosting) Chapter 9 9.13 finalMethods and

Wednesday, September 12th, 2007

474 Object-Oriented Programming Chapter 9 9.13 finalMethods and Classes We saw in Chapter 7 that variables can be declared final to indicate that they cannot be modified after they are declared and that they must be initialized when they are declared. It is also possible to define methods and classes with the final modifier. A method that is declared final cannot be overridden in a subclass. Methods that are declared static and methods that are declared private are implicitly final. Because a final method s definition can never change, the compiler can optimize the program by removing calls to final methods and replacing them with the expanded code of their definitions at each method call location a technique known as inlining the code. A class that is declared final cannot be a superclass (i.e., a class cannot inherit from a final class). All methods in a final class are implicitly final. Performance Tip 9.2 The compiler can decide to inline a final method call and will do so for small, simple final methods. Inlining does not violate encapsulation or information hiding (but does improve performance because it eliminates the overhead of making a method call). Software Engineering Observation 9.17 A class declared final cannot be extended, and every method in it is implicitly final. Software Engineering Observation 9.18 In the Java API, the vast majority of the thousands of classes are not declared final. This enables inheritance and polymorphic processing the fundamental capabilities of object- oriented programming. However, in some cases it is important to declare classes final typically for security1 or performance reasons. 9.14 Abstract Superclasses and Concrete Classes When we think of a class as a type, we assume that objects of that type will be instantiated. However, there are cases 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 as superclasses in inheritance situations, we will normally refer to them as abstract superclasses. No objects of abstract superclasses can be instantiated. The sole purpose of an abstract class is to provide an appropriate superclass from which other classes may inherit interface and/or implementation (we will see examples of each shortly). Classes from which objects can be instantiated are called concrete classes. 1. Class String is an example of a final class. This class cannot be extended, so programs that use Strings can rely on the functionality of String objects as specified in the Java API. Making the class finalalso prevents programmers from creating subclasses that might bypass security restrictions. For example, when a Java program attempts to open a file on your computer, the program supplies a String representing the name of the file. In many cases, opening a file is subject to security restrictions. If it were possible to create a subclass of String, that subclass might be implemented in a manner that enables it to specify one String to pass a security or permissions test, then specify a different name when the program actually opens the file. For more information on final classes and methods visit: java.sun.com/docs/books/tutorial/ java/javaOO/final.html [Note: Strings are covered in detail in Chapter 10 and file processing is covered in detail in Chapter 16.] Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Web server version - Chapter 9 Object-Oriented Programming 473 a program that

Tuesday, September 11th, 2007

Chapter 9 Object-Oriented Programming 473 a program that need modification are those parts that require direct knowledge of the particular class that is added to the hierarchy. We will study two substantial class hierarchies and will show how objects throughout those hierarchies are manipulated polymorphically. 9.11 Type Fields and switch Statements One means of dealing with objects of many different types is to use a switch statement to take an appropriate action on each object, based on that object s type. For example, in a hierarchy of shapes in which each shape has a shapeType instance variable, a switch structure could determine which printmethod to call based on the object s shapeType. There are many problems with using switch logic. The programmer might forget to make such a type test when one is warranted. The programmer might forget to test all possible cases in a switch. If a switch-based system is modified by adding new types, the programmer might forget to insert the new cases in existing switch statements. Every addition or deletion of a class demands that every switch statement in the system be modified; tracking these down can be time consuming and error prone. As we will see, polymorphic programming can eliminate the need for switch logic. The programmer can use Java s polymorphism mechanism to perform the equivalent logic automatically, thus avoiding the kinds of errors typically associated with switch logic. Testing and Debugging Tip 9.2 An interesting consequence of using polymorphism is that programs take on a simplified appearance. They contain less branching logic in favor of simpler sequential code. This simplification facilitates testing, debugging, and program maintenance. 9.12 Dynamic Method Binding Suppose a set of shape classes such as Circle, Triangle, Rectangle, Square, are all derived from superclass Shape. In object-oriented programming, each of these classes might be endowed with the ability to draw itself. Each class has its own draw method, and the draw method implementation for each shape is quite different. When drawing a shape, whatever that shape may be, it would be nice to be able to treat all these shapes generically as objects of the superclass Shape. Then, to draw any shape, we could simply call method draw of superclass Shapeand let the program determine dynamically (i.e., at execution time) which subclass draw method to use from the actual object s type. To enable this kind of behavior, we declare draw in the superclass, and then we override draw in each of the subclasses to draw the appropriate shape. Software Engineering Observation 9.16 When a subclass chooses not to redefine a method, the subclass simply inherits its immediate superclass s method definition. If we use a superclass reference to refer to a subclass object and invoke the draw method, the program will choose the correct subclass s draw method dynamically (i.e., at execution time). This is called dynamic method binding. Dynamic method binding is an important mechanism for implementing polymorphic processing of objects and will be illustrated in the case studies later in this chapter Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01