Chapter 2 Object Orientation

1. Chapter 2Object Orientation

2. Process Phase Affected by This Chapter Requirements Analysis Design Framework Architecture Detailed Design Implementation Key: = less so Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

3. Before Object Orientation Real world concepts Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Software Design Entities Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

4. How Do We Express Ourselves? "Customers Montague and Susan entered the Ajax bank and were served by teller Andy ..... " AJAX BANK Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

5. How We Express Ourselves "Customers Montague and Susan entered the Ajaxbank and were served by tellerAndy ..... " CLASSES OBJECTS Note that Java code convention reverses this capitalization. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

6. Object Orientation Real world concepts Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Skljkvjkvjfkavjafkk saovjsdvjfvkfjvkfjk Direct correspondence Customer getFirstName() Transaction execute() Account getDetails() Software design entities Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Graphics reproduced with permission from Corel.

7. Key Concept: Benefits of OO Object orientation provides a direct mapping between concepts and code. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

8. Class Introduction Real world Class in Design (UML notation) Class in Source code (Java) class AjaxCustomer { . . . . } AjaxCustomer class PermissionToPay { . . . . } Mental concept PermissionToPay Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

9. The Members of a Class Objects of Auto Non-static variable: One version for every object Class model aliceBrownBMW:Auto … Auto public int vehicleID … protected int mileage … private myPrivateVariable … static int numAutosMade … 33024 mileage 12390924850984 Static variable: One version only numAutosMade Subclasses have these members too myToyota:Toyota … jaynesCar:Auto … 2105 83402 mileage mileage Toyota … Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

10. Attribute Types (Shlaer & Mellor) • Naming: • fixed for each object • distinguishes individuals • Descriptive: • varies through life of object • Referential: • ties instance of one class to instance(s) of another • == aggregation Auto vehicleID mileage owner Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

11. Key Concept: Classes and Objects A class expresses a concept such as “HondaCivic.” An object is an instance of a class such as “the Honda Civic with vehicle ID 89R783HJD894.”

12. The Clients of a Class class Customer { . . . String getName() { … } int computeBalance() { … } . . . } Class Customer class AjaxAssets { . . . int computeAssets() { . . . Customer c = customers[ i ]; assets += c.computeBalance(); . . . } . . . } class AjaxWebsiteGenerator { . . . void makeProfile( Customer c ) { … String name = c.getName() … } . . . } Client of Customer Client of Customer Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

13. Aspects of OO Useful for Application Development • Class Introduction (section 2.2.1) • basic motive of Object Orientation • identifying parts that corresponds to the real world • Instantiation(section 2.2.2) • creating instances of encapsulated concepts • Inheritance(section 2.3.1) • capturing the way concepts occur in hierarchy • Polymorphism(section 2.3.2) • capturing use of single action word to represent different things, depending on context Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

14. Requirements For e-Mail Creation Example Page 1 of 4 1. Summary: Produces e-mail text for various types of customers. 2. Detailed requirements 2.1 The application displays choices to the console, as shown in figure xx. 2.2 For customers delinquent more than 90 days, the e-mail message generated is the statement shown in figure xx. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

15. Typical Interaction for e-mail Creation Example Page 2 of 4 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

16. Requirements For e-Mail Creation Example Page 3 of 4 2.3 All non-delinquent customers receive a tailored e-mail messages as follows.  2.3.1 Mountain customers: This month we have a special on West Face tents. Only $700. ... lots more output specialized to mountaineering customers ... 2.3.2 Regular customers: All items are marked down 20% for this month only. ... lots more output for regular customers ... Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

17. Requirements For e-Mail Creation Example Page 4 of 4 2.4 The e-mail is to be displayed on the console. 3. Future enhancements We anticipate that the text is likely to change frequently, and that new kinds of customers are likely to be specified, each with its own new set of requirements. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

18. Disadvantages of Branching • Code for each case not cohesive (“cohesive”: forms a comprehensible unity) • All types of customers coded together in single class Expensive to … • … add new functionality • bloat switch or if - then code • … remove functionality • hunt for all parts that must be removed • … change functionality • hunt for all parts that must be changed Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

19. Aspects of the Customer Design Needing Improvement • We need to visualize the design • Code not an effective way to understand design • The design’s maintainability still has flaws • As the application grows, specialized class(es) will be required to interact with the user Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

20. Key Concept:  Polymorphism - the use of several versions of a method, one in each derived class. This enables objectOfBaseClass.theMethod() to be interpreted variously at runtime, depending on what derived class objectOfBaseClass belongs to. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

21. What’s Needed to Specify Functionality • Name of the function Example: add • Argument types(if any) Example: • First parameter: integer • Second parameter: float • Return type Example: double, reference type, void • Exceptions (if any) Example: IOException • More(?) • Are parameters inputs and/or outputs? • Describe what the function does (natural language) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

22. The Need For Interfaces: Simplify … • class Draw • { … • int setColor( String ) { … } • Pen getStandardPen() { … } • int getLogoStyle() { … } • void setColor( int ) { … } • void drawLogo( int, int ) { … } • void speedUpPen( int ) { … } • … • }

23. Interface Example: a Draw Class } • Functions dealing with the pen used • Pen getStandardPen() • void speedUpPen( int ) • . . . • Functions dealing with the colors available • void setColor( int ) • int setColor( String ) • . . . • Functions covering the drawing of the company’s logo • void drawLogo( int, int ) • int getLogoStyle() • . . . • . . .. . . . Pen interface } Color interface } Logo interface Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

24. Key Concept: Interfaces An interface is a set of function prototypes (each with name, parameter types, return type, exception type). Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

25. Issues to be Addressed • How do we visualize a set of classes? • How can classes relate to each other? • How should classes relate to each other? • How can we describe functionality occurring among several classes? • How do we describe the manner in which objects respond to events occurring on them? • Are there patterns of class usage that recur? • So we can existing design parts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

26. Summary of This Chapter • A Class represents a concept • Example: House • An Object is an instance of a class • Example: 23 Main Street, Springfield • Classes can relate in several ways: Mainly … • A Client of a class refers to that class in one of its methods • Inheritance: “kind of” relationship • Aggregation: “has a” relationship, explained in chapter xx • Polymorphism means “action depends on context” • Executing anObject.aMethod() actually executes the version of aMethod() in the subclass that anObject belongs to Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

27. Typical Interaction for Auto Description Exercise Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.