1. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. Chapter 3: Data Abstraction: The Walls Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano

2. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 2 C++ Classes: The header file /** @file Sphere.h */ const double PI = 3.14159; class Sphere { public: Sphere(); // Default constructor Sphere(double initialRadius); // Constructor void setRadius(double newRadius); double getRadius() const; // can’t change data members double getDiameter() const; double getCircumference() const; double getArea() const; double getVolume() const; void displayStatistics() const; private: double theRadius; // data members should be private }; // end Sphere

3. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 3 C++ Classes: Constructors A class can have several constructors –A default constructor has no arguments –The compiler will generate a default constructor if you do not define any constructors

4. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 4 C++ Classes: Constructors The implementation of a method qualifies its name with the scope resolution operator :: The implementation of a constructor –Sets data members to initial values Can use an initializer Sphere::Sphere() : theRadius(1.0) { } // end default constructor –Cannot use return to return a value

5. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 5 C++ Classes: Destructors Destructor –Destroys an instance of an object when the object’s lifetime ends Each class has one destructor –For many classes, you can omit the destructor –The compiler will generate a destructor if you do not define one For now, we will use the compiler’s destructor

6. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 6 C++ Classes: The implementation file /** @file Sphere.cpp */ #include #include "Sphere.h" // header file using namespace std; Sphere::Sphere() : theRadius(1.0) { } // end default constructor Sphere::Sphere(double initialRadius) { if (initialRadius > 0) theRadius = initialRadius; else theRadius = 1.0; } // end constructor

7. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 7 C++ Classes: The implementation file void Sphere::setRadius(double newRadius) { if (newRadius > 0) theRadius = newRadius; else theRadius = 1.0; } // end setRadius The constructor could call setRadius

8. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 8 C++ Classes: The implementation file double Sphere::getRadius() const { return theRadius; } // end getRadius... double Sphere::getArea() const { return 4.0 * PI * theRadius * theRadius; } // end getArea...

9. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 9 Abstract Data Types Modularity –Keeps the complexity of a large program manageable by systematically controlling the interaction of its components –Isolates errors –Eliminates redundancies

10. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 10 Abstract Data Types Modularity (Continued) –A modular program is Easier to write Easier to read Easier to modify

11. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 11 Abstract Data Types Functional abstraction –Separates the purpose and use of a module from its implementation –A module’s specifications should Detail how the module behaves Be independent of the module’s implementation

12. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 12 Abstract Data Types Information hiding –Hides certain implementation details within a module –Makes these details inaccessible from outside the module

13. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 13 Abstract Data Types Typical operations on data –Add data to a data collection –Remove data from a data collection –Ask questions about the data in a data collection

14. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 14 Abstract Data Types Data abstraction –Asks you to think what you can do to a collection of data independently of how you do it –Allows you to develop each data structure in relative isolation from the rest of the solution –A natural extension of functional abstraction

15. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 15 Abstract Data Types Abstract data type (ADT) –An ADT is composed of A collection of data A set of operations on that data –Specifications of an ADT indicate What the ADT operations do, not how to implement them –Implementation of an ADT Includes choosing a particular data structure

16. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 16 Abstract Data Types Figure 3-4 A wall of ADT operations isolates a data structure from the program that uses it

17. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-17 Object-Oriented Analysis and Design Object-oriented design (OOD) –Expresses an understanding of a solution that fulfills the requirements discovered during OOA –Describes a solution in terms of Software objects The collaborations of these objects with one another –Objects collaborate when they send messages (call each other’s operations) –Collaborations should be meaningful and minimal –Creates one or more models of a solution Some emphasize interactions among objects Others emphasize relationships among objects

18. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-18 Applying the UML to OOA/D Unified Modeling Language (UML) –A tool for exploration and communication during the design of a solution –Models a problem domain in terms of objects independently of a programming language –Visually represents object-oriented solutions as diagrams –Its visual nature is an advantage, since we are visual creatures –Enables members of a programming team to communicate visually with one another and gain a common understanding of the system being built

19. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-19 Applying the UML to OOA/D UML use case for OOA –A set of textual scenarios (stories) of the solution Each scenario describes the system’s behavior under certain circumstances from the perspective of the user –Focus on the responsibilities of the system to meeting a user’s goals Main success scenario (happy path): interaction between user and system when all goes well Alternate scenarios: interaction between user and system under exceptional circumstances –Find noteworthy objects, attributes, and associations within the scenarios

20. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-20 Applying the UML to OOA/D –An example of a main success scenario Customer asks to withdraw money from a bank account Bank identifies and authenticates customer Bank gets account type, account number, and withdrawal amount from customer Bank verifies that account balance is greater than withdrawal amount Bank generates receipt for the transaction Bank counts out the correct amount of money for customer Customer leaves bank

21. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-21 Applying the UML to OOA/D –An example of an alternate scenario Customer asks to withdraw money from a bank account Bank identifies, but fails to authenticate customer Bank refuses to process the customer’s request Customer leaves bank

22. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-22 Applying the UML to OOA/D UML sequence (interaction) diagram for OOD –Models the scenarios in a use case –Shows the interactions among objects over time –Lets you visualize the messages sent among objects in a scenario and their order of occurrence –Helps to define the responsibilities of the objects What must an object remember? What must an object do for other objects?

23. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-23 Applying the UML to OOA/D Figure 1-2 Sequence diagram for the main success scenario

24. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-24 Applying the UML to OOA/D Figure 1-3 Sequence diagram showing the creation of a new object

25. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-25 Applying the UML to OOA/D UML class (static) diagram –Represents a conceptual model of a class of objects in a language-independent way –Shows the name, attributes, and operations of a class –Shows how multiple classes are related to one another

26. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-26 Applying the UML to OOA/D Figure 1-4 Three possible class diagrams for a class of banks

27. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-27 Applying the UML to OOA/D Figure 1-5 A UML class diagram of a banking system

28. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-28 Applying the UML to OOA/D Class relationships –Association The classes know about each other Example: The Bank and Customer classes –Aggregation (Containment) One class contains an instance of another class Example: The Bank and Account classes The lifetime of the containing object and the object contained are not necessarily the same –Banks “live” longer than the accounts they contain

29. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-29 Applying the UML to OOA/D Class relationships (Continued) –Composition A stronger form of aggregation The lifetime of the containing object and the object contained are the same Example: A ballpoint pen –When the pen “dies,” so does the ball

30. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-30 Applying the UML to OOA/D Class relationships (Continued) –Generalization Indicates a family of classes related by inheritance Example: Account is an ancestor class; the attributes and operations of Account are inherited by the descendant classes, Checking and Savings

31. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-31 Applying the UML to OOA/D Notation –Association A relationship between two classes is shown by a connecting solid line Relationships more specific than association are indicated with arrowheads, as you will see Multiplicities: Optional numbers at the end(s) of an association or other relationship –Each bank object is associated with zero or more customers (denoted 0..*), but each customer is associated with one bank –Each customer can have multiple accounts of any type, but an account can belong to only one customer

32. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 1-32 Applying the UML to OOA/D Notation (Continued) –Aggregation (Containment) Denoted by an open diamond arrowhead pointing to the containing class –Composition Denoted by a filled-in diamond arrowhead pointing to the containing class –Generalization (Inheritance) Denoted by an open triangular arrowhead pointing to the ancestor (general or parent) class –UML also provides notation to specify visibility, type, parameter, and default value information

33. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. In class exercise: Parking Ticket Simulator For this assignment, you will design a set of classes that work together to simulate a police officer issuing a parking ticket. For each car we have the license number, model, make, color, and the number of minutes the car has been parked. Each car is parked at a parking meter who knows the number of minutes of parking time that has been purchased. A police officer inspects the cars parked at the meters, and determines whether the car's time has expired. He issues a parking ticket if the car's time has expired. The parking ticket reports the make, model, color, and license number of the illegally parked car, the officer who gave the ticket and the amount of fine ($25 for the first hour plus $10 every additional hour or part of an hour);

34. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 34 Design the UML class diagrams of this project.

35. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 35 Summary Data abstraction controls the interaction between a program and its data structures Abstract data type (ADT): a set of data- management operations together with the data values upon which they operate Define an ADT fully before making any decisions about an implementation

36. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 36 Summary Hide an ADT’s implementation by defining the ADT as a C++ class An object encapsulates both data and operations A class contains one destructor and at least one constructor The compiler generates –A default constructor if no constructor is provided –A destructor if none is provided

37. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver. 5.0. 37 Summary Members of a class are private by default –Data members are typically private –Public methods can be provided to access them Define and implement a class within header and implementation files Namespace: a mechanism to group classes, functions, variables, types, and constants You can throw an exception if you detect an error during program execution. You handle, or deal with, an exception by using try and catch blocks