Object-oriented Design

1. Object-oriented Design Chapter 16

2. Real Objects and Software Objects • “Real” objects are things that can be manipulated and used for different tasks. So, too, are software objects. • Real objects fit into general classes with the same general purpose and means of use: cars, televisions, microwaves, lawnmowers, dryers, etc. • In addition, there are very broad classes that include general classes. For instance, “appliances” would include microwaves, televisions and dryers.

3. What is a Software 'Object'? • Software objects are similar to real-world objects in that they can have general uses, and fit into classes. • There is also the capability to have “classes of classes” just like “appliances” for real world objects.

4. The Object Paradigm • With software objects, however, we don’t interact ‘directly’ with them (like turning on a television.) Instead, we ‘send the object a message’. • A software object can accept and understand any ‘message’ or messages we design it to accept. • The model (or ‘paradigm’) is that we ‘talk’ to objects and send it instructions about what to do. In turn, the object may send messages to other objects to help it with it’s task.

5. Object-oriented requirements • Object-oriented requirements definition lends itself to definition of ‘analog’ systems: systems designed on the basis of existing physical or manual systems (such as accounting ledgers, invoices, receipts, etc.) • There are techniques for extracting object requirements from unstructured requirements definitions (such as rambling prose) that work quite well!

6. Modeling the physical world • Since a major strength of the object-oriented approach is the object ‘paradigm’, it’s best to model the physical world when building object oriented systems. • For instance, since we can ‘post’ an entry to a ledger in an accounting system, it would perhaps be wise to create an object class called ‘ledger’ that understands a message named ‘post’ that contains a ledger entry in the message.

7. The role of requirements • In the instance of object-oriented systems, the requirements give the designer instructions about what objects should be constructed, and what messages they should understand. • In addition, the requirement must give the designer an idea of how the objects can be organized, and what other objects they must ‘collaborate’ with.

8. Booch method • One popular method, the Booch method, models objects on several levels: • a logical level • physical model • dynamic model • static model. • The Booch method is perhaps one of the most popular methods, and merits careful study by the serious object-oriented designer.

9. Shlaer-Mellor method • The Shlaer-Mellor method uses a slightly different approach from the Booch model in that it models three basic aspects of the system: • Object information • State • processing. • There are many different ways to model objects, but we shall examine a popular ‘pencil-and-paper’ approach.

10. Class-Responsibilites-Collaboration (CRC) Method • The CRC method uses `CRC’ cards that are essentially 3 by 5 index cards (or whatever is handy). • The approach is to `decompose’ the requirements to identify classes and patterns, then look at their responsibilities. • After the classes and responsibilities are identified, the next step is to look at how they need to work together: their ‘collaborations’ in other words.

11. Identification of classes and patterns • When looking for classes and patterns, scan the specifications for nouns and noun phrases (nouns or adjective/noun combinations). • These are ‘candidate classes’, and we create a CRC class to represent these classes. • We may, at a later time, change the name of the class, or discard it altogether. Remember, at this time the classes are merely ‘candidates!’

12. Identification of Responsibilities • Once we have these candidate class CRC cards, we look at the verb phrases (verbs or verb/adverb combinations) to identify possible responsibilities. • These candidate responsibilities are also entered on the respective CRC cards. Again, these responsibilities may later be modified or discarded! • We can begin to see ‘action on object’ potentials from the associated class names and verb/noun combinations (‘post and entry’ to a ‘ledger’).

13. Identification of collaborators • In looking for object collaborations, we need to look for possible relationships, such as: • Object A is like Object B • Object A knows about Object B • Object A shares information with Object B • These relationships are entered on the CRC card as candidate collaborations.

14. CRC Card Class: Superclass: Responsibilities Collaborators

15. CRC Card for Clock part of system Class: Clock Superclass: Timepiece Responsibilities Collaborators Display set clock Display, Perferences read clock

16. CRC Card for Slide Puzzle Class: Superclass: Responsibilities Collaborators

17. Polymorphism Designers may find that there are general classes of objects, such as ledgers and journals, who share similar messages (such as ‘post entry’) but have other unique messages that make them different. These objects are candidates for inheritance: a superclass can be created that accepts their common messages, and the ‘subclasses’ can `inherit’ these methods and add their own.

18. Polymorphism • Designers may likewise find that there are several different ‘forms’ of messages or objects that perform the identical functions, using different message values. • Object oriented programming languages provide features that permit these different forms (polymorphism.)

19. Checking an Object Design for Implementation • Object role playing is one of the best methods for checking. • Each object is assigned to an engineer to ‘play the part’ of that object. • The objects are then `walked through’ a cases in the system, and each object player checks to make sure that the information is available for proper execution of the object’s responsibilities.

20. Object-oriented languages • There are many object oriented languages today. Many of these are modern languages with extensions to support the object-oriented concepts: Classes, Methods, Inheritance, and Polymorphism. • Still, thee of the major object oriented languages are still: Smalltalk, C++ and Java.

21. Smalltalk • Smalltalk was advanced as a language originally by Alan Kay, who was working at the Xerox Palo Alto Research Center (Xerox PARC). • Smalltalk was used as the fundamental language for programming the Xerox Star system, one of the early Object-oriented workstations.

22. C++ • In the mid-1980s C++ was developed as the object-oriented extension to the C programming language. • Bjarne Stroustrop was the major proponent of the C++ programming language. • Another major contender at the time was ‘Objective C’ which was used by the “Next” system built by Steve Jobs company.

23. Java • Java emerged from the “Oak” programming language at Sun Microsystems. • Java was well suited to providing small programs that could be downloaded quickly (‘applets’). This proved to be very useful for internet applications, and Java quickly became the language of choice for Web browser applet programming.

24. Java An exceedingly brief introduction

25. It's like • C++ • Smalltalk

26. How is Java different? • No preprocessor • No #define • No #ifdef • Strongly typed • No multiple inheritance • No operator overloading

27. How is Java different? (cont’d) • Interpreted (Virtual Machine) • Run-time error checking • Garbage collection • Standard class libraries • No pointers, only references • Scoping

28. Terminology Classes vs. Objects • A "Class" is a definition. • An "Object" is the instance. Methods • In C++, called “member functions"

29. Inheritance • Parent class defines common elements (data, methods) • Child class defines ONLY elements unique to that specific class. • Rule: Promote methods and data to the HIGHEST level of abstraction.

30. Public, Protected, and Private • private is visible only to the class. • protected is visible only to the class and child classes. • "super" allows reference to parent elements, providing overrides.

31. Defining Objects class Myclass { <object content> }

32. Data class Myclass { public int mypublicdata; private int myprivatedata; protected int myprotecteddata; }

33. Methods class Myclass { public int mypublicdata; private int myprivatedata; protected int myprotecteddata; public int get_myprivatedata { return myprivatedata; }; }

34. Constructors class Myclass { public int mypublicdata; private int myprivatedata; protected int myprotecteddata; public int get_myprivatedata { return myprivatedata; }; Myclass(int myarg) { mypublicdata = myarg++; myprivatedata = myarg++; myprotecteddata = myarg; } }

35. Instatiating Objects Myclass Myobject = new Myclass(arglist); System.out.println ("My public data = " + Myobject.mypublicdata); System.out.println ("My private data = " + Myobject.myprivatedata() );

36. Notation Dot notation • Instance.item • Instance.item() this and super • "this" insures self-reference. • "super" insures parent reference.

37. Built-in types • boolean (true or false) • char (16-bit Unicode) • byte (8-bits) • short, int, long (integers) • float, double (floating point)

38. Built-in objects and methods Arrays • length() Strings • Not mutable! (StringBuffer is!) • length(), indexOf(), lastindex()... • Concatenation ("+") Exceptions • throw • catch

39. Libraries java.lang - core language classes java.io - io package java.util - general utility java.text - date, I18N, L12N, sorting java.awt - abstract windows java.applet - applets java.beans - user composable code java.rmi - remote method invocation (distributed processing)

40. Libraries (cont’d) java.net - networking java.math - math routines java.sql - SQL (database) java.security - encryption, authentication, signatures

41. Control if-else switch (to define a “constant”: public static final int SOMECONST = 1; ) while for while (and do-while) break (and labeled break: break somelabel ) continue return

42. Inheritance class Otherclass extends Myclass { public int get_myprivatedata() { return myprivatedata-1; } } … Otherclass Oc = new Otherclass(4); System.out.println(“Otherclass private data = “ + Oc.get_myprivatedata(); }

43. But consider… class Otherclass extends Myclass { public int get_myprivatedata() { return super.get_myprivatedata()-1; } } … Otherclass Oc = new Otherclass(4); System.out.println(“Otherclass private data = “ + Oc.get_myprivatedata(); }