The OOTP is intended to get you thinking about how OO concepts are used in designing object-oriented systems. Note: not talking about OO technologies that are in a constant state of flux. These concepts generally include: encapsulation, inheritance, polymorphism, and composition. In OO design, the attributes (fields) and behaviors (methods) are contained within a single object, whereas in procedural, or structured, design the attributes and behaviors are normally separated. Figure 1.1 Black boxes. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.2 Using global data. We can state that when properly designed, there is no such thing as global data in an OO model. This fact provides a high amount of data integrity in OO systems. In OO terminology, data are referred to as attributes, and behaviors are referred to as methods. Restricting access to certain attributes and/or methods is called data hiding (or encapsulation) It is easy to create poorly designed OO classes that do not restrict access to class attributes. One can still design bad code. But by adhering to sound class design guidelines… Figure 1.2 Using global data. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.3 Object-to-object communication. Say myObject wants to access the sum of int1 and int2, it would communicate with Math via their methods. Calculating the sum is not the responsibility of myObject – it’s the Math object’s responsibility. As long as myObject has access to the Math object, it can send the appropriate messages and obtain the requested result. In general, objects should not manipulate the internal data of other objects. Figure 1.3 Object-to-object communication. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.4 Data transmitted over a wire. When transmitting data over a wire, procedural programming normally separates the data of a system from the operations that manipulate the data. Only the data need be sent when there is an understanding between client and server as to what to expect and how to handle the data. Figure 1.4 Data transmitted over a wire. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.5 Objects transmitted over a wire. The fundamental advantage of OO programming is that the data and the operations that manipulate the data are both encapsulated in the object. The entire object, including data and behavior are transmitted. In reality, often both sides will have copies of the behavior, so transmitting the methods may not be necessary. A good example of this concept is an object that is loaded by a browser. Often, the browser has no idea of what the object will do ahead of time because the code is not there previously. Once the object is loaded, the browser executes the code within the object and uses the data contained within the object. Figure 1.5 Objects transmitted over a wire. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.6 Employee attributes. The attributes contain the information that differentiates between the various objects. Figure 1.6 Employee attributes. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.7 Employee behaviors. The behavior of an object represents what the object can do. In procedural languages the behavior is defined by procedures, functions, and subroutines. In OO programming terminology, these behaviors are contained in methods, and you invoke a method by sending a message to it. We control access to the attributes. Figure 1.7 Employee behaviors. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.8 Employee and payroll class diagrams. UML diagram – missing constructors, has private (-) attributes and public (+) methods. Class name, line, fields, line, constructors and methods. Figure 1.8 Employee and payroll class diagrams. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Two instances of Employee objects Two instances of Employee objects. Note: these is not necessarily a physical copy of each method for each object. This is a compiler/operating platform implementation issue. Conceptually, you can think of objects as being wholly independent and having their own attributes and methods. Figure 1.9 Program spaces. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

What is a class. It is a blueprint for an object What is a class? It is a blueprint for an object. When you instantiate an object, you use a class as the basis for how the object is built. The class template is the Cookie Cutter, the instances of cookies are the objects themselves. Figure 1.10 Class template. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.11 The Person class diagram. Fields (java for attributes, data) and methods are separated. The interface (method to method) defines the fundamental means of communication between objects. Each class design specifies the interfaces for the proper instantiation and operation of objects. Any behavior that the object provides must be invoked by a message sent using one to the provided interfaces. Methods that are part of the interface are designated public. All attributes (fields) should be declared as private. Don’t confuse the interfaces used to extend classes with the interface of a class. The author equates the interfaces, represented by methods, as “signatures.” Figure 1.11 The Person class diagram. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.12 Power plant example. Any appliance can get electricity, as long as it conforms to the interface specification. The outlet is the interface with the power plant. Figure 1.12 Power plant example. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.13 The Square class. The user only has access to the public method. Figure 1.13 The Square class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.14 Mammal hierarchy. We can create new classes by abstracting common attributes via inheritance. Figure 1.14 Mammal hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.15 Mammal UML diagram. Inheritance can be a double edged sword. Figure 1.15 Mammal UML diagram. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.16 Mammal hierarchy. Consider a child that inherits from both parents. Which pair of eyes does the child inherit? Some languages (C++) allow multiple inheritance, many do not (Java, Python). Figure 1.16 Mammal hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.17 The shape hierarchy. The circle is-a shape, the star is-a shape, and the square is-a shape. They all implement the draw method. Send a draw message to each Shape object and each will draw itself differently. The drawing occurs when the draw method is called. We can either use the instance to invoke the method or we can pass the instance to another object which in turn will ultimately call the instance’s draw method. Ex. g2.draw(myShape); myShape.draw(g2); Figure 1.17 The shape hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 1.18 Shape UML diagram. When the parent class has a method of interest, we can rely on all children to have that method, regardless of the child’s type. We can have hundreds of different shape objects, all will have a getArea method. Figure 1.18 Shape UML diagram. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.6 An example of composition. Has-a Relationship The second mechanism for building objects –embedding objects We have covered many of the principle abstractions in OO programming, in particular: Encapsulation, Inheritance, Polymorphism, and Composition Figure 7.6 An example of composition. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.1 Power plant revisited. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.2 A Unified Modeling Language class diagram for the DataBaseReader class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.3 The interface. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.4 An abstract interface. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.5 A not-so-abstract interface. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.6 Providing services. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.7 The methods in a Cabbie class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.1 The components of a signature. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.2 The DataBaseReader class diagram. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.3 Creating a new object. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.4 Constructing an object. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.5 Catching an exception. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.6 Object attributes. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.7 Class attributes. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 3.8 Following object references. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 4.1 Our sample class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 4.2 Object memory allocation. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 4.3 The Cabbie object referencing a cab object. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 4.4 Asking for information. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 4.5 Method memory allocation. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 5.1 A cabbie and a cab are real-world objects. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 5.2 The public interface specifies how the objects interact. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 5.3 Objects don’t need to know some implementation details. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 5.4 Objects should request information. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 5.5 A serial port wrapper. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 5.6 Using stubs. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 6.1 The waterfall method. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 6.2 The competitive advantage. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 6.3 Wrapping structured code. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.1 A class diagram for the Dog class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.2 The GoldenRetriever class inherits from the Dog class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.3 The LhasaApso class inherits from the Dog class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.4 The Dog class hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.5 An expanded canine model. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.6 An example of composition. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.7 Representing composition in UML. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.8 The Car class hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.9 A UML diagram of the Cabbie class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.10 A UML diagram of the Cabbie/PartTimeCabbie classes. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 7.11 The Shape class hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.1 A word processing framework. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.2 API documentation. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.3 An abstract class hierarchy. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.4 A UML diagram of a Java interface. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.5 A UML diagram of the sample code. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.6 Applications on divergent paths. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 8.7 A UML diagram of the Shop model. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.1 An inheritance relationship. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.2 A composition relationship. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.3 Building, testing, and verifying a complete system one step at a time. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.4 An aggregation hierarchy for a car. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.5 Associations as a separate service. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.6 Convenience versus stability. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.7 Cardinality in a UML diagram. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.8 Checking all optional associations. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 9.9 A UML diagram for the Dog example. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 10.1 Model/View/Controller paradigm. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 10.2 Creating a factory for the Shape class. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 11.1 Using inheritance to create mammals. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 11.2 Using composition to create mammals. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 11.3 Using interfaces to create mammals. From The Object-Oriented Thought Process, 5/e by Matt Weisfeld (9780135767313) Copyright © 2019 Pearson Education, Inc. All rights reserved