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.

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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) 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 ( ) Copyright © 2019 Pearson Education, Inc. All rights reserved

Figure 2.2 A Unified Modeling Language class diagram for the DataBaseReader class.

Figure 2.4 An abstract interface.

Figure 2.5 A not-so-abstract interface.

Figure 2.6 Providing services.

Figure 2.7 The methods in a Cabbie class.

Figure 3.1 The components of a signature.

Figure 3.2 The DataBaseReader class diagram.

Figure 3.3 Creating a new object.

Figure 3.4 Constructing an object.

Figure 3.5 Catching an exception.

Figure 3.6 Object attributes.

Figure 3.7 Class attributes.

Figure 3.8 Following object references.

Figure 4.1 Our sample class.

Figure 4.2 Object memory allocation.

Figure 4.3 The Cabbie object referencing a cab object.

Figure 4.4 Asking for information.

Figure 4.5 Method memory allocation.

Figure 5.1 A cabbie and a cab are real-world objects.

Figure 5.2 The public interface specifies how the objects interact.

Figure 5.3 Objects don’t need to know some implementation details.

Figure 5.4 Objects should request information.

Figure 5.5 A serial port wrapper.

Figure 6.1 The waterfall method.

Figure 6.2 The competitive advantage.

Figure 6.3 Wrapping structured code.

Figure 7.1 A class diagram for the Dog class.

Figure 7.2 The GoldenRetriever class inherits from the Dog class.

Figure 7.3 The LhasaApso class inherits from the Dog class.

Figure 7.4 The Dog class hierarchy.

Figure 7.5 An expanded canine model.

Figure 7.6 An example of composition.

Figure 7.7 Representing composition in UML.

Figure 7.8 The Car class hierarchy.

Figure 7.9 A UML diagram of the Cabbie class.

Figure 7.10 A UML diagram of the Cabbie/PartTimeCabbie classes.

Figure 7.11 The Shape class hierarchy.

Figure 8.1 A word processing framework.

Figure 8.2 API documentation.

Figure 8.3 An abstract class hierarchy.

Figure 8.4 A UML diagram of a Java interface.

Figure 8.5 A UML diagram of the sample code.

Figure 8.6 Applications on divergent paths.

Figure 8.7 A UML diagram of the Shop model.

Figure 9.1 An inheritance relationship.

Figure 9.2 A composition relationship.

Figure 9.3 Building, testing, and verifying a complete system one step at a time.

Figure 9.4 An aggregation hierarchy for a car.

Figure 9.5 Associations as a separate service.

Figure 9.6 Convenience versus stability.

Figure 9.7 Cardinality in a UML diagram.

Figure 9.8 Checking all optional associations.

Figure 9.9 A UML diagram for the Dog example.

Figure 10.1 Model/View/Controller paradigm.

Figure 10.2 Creating a factory for the Shape class.

Figure 11.1 Using inheritance to create mammals.

Figure 11.2 Using composition to create mammals.

Figure 11.3 Using interfaces to create mammals.

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

Similar presentations

About project

Feedback