1. Lecture 13: Object- Oriented Concepts Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 7

2. CS540 Software Design 2Lecture 13 Object-Oriented Programming Objects can be used effectively to represent real- world entities Objects can be used effectively to represent real- world entities For instance, an object might represent a particular employee in a company For instance, an object might represent a particular employee in a company Each employee object handles the processing and data management related to that employee Each employee object handles the processing and data management related to that employee

3. 3 Objects An object has: An object has: state - descriptive characteristics state - descriptive characteristics behaviors - what it can do (or what can be done to it) behaviors - what it can do (or what can be done to it) The state of a bank account includes its account number and its current balance The state of a bank account includes its account number and its current balance The behaviors associated with a bank account include the ability to make deposits and withdrawals The behaviors associated with a bank account include the ability to make deposits and withdrawals Note that the behavior of an object might change its state Note that the behavior of an object might change its state

4. CS540 Software Design 4Lecture 13 Classes An object is defined by a class An object is defined by a class A class is the blueprint of an object A class is the blueprint of an object Multiple objects can be created from the same class Multiple objects can be created from the same class

5. CS540 Software Design 5Lecture 13 Objects and Classes Bank Account A class (the concept) John’s Bank Account Balance: $5,257 An object (the realization) Bill’s Bank Account Balance: $1,245,069 Mary’s Bank Account Balance: $16,833 Multiple objects from the same class

6. CS540 Software Design 6Lecture 13 Attributes Contain current state of an object. Attributes can be classified as simple or complex. Attributes can be classified as simple or complex. Simple attribute can be a primitive type such as integer, string, etc., which takes on literal values. Simple attribute can be a primitive type such as integer, string, etc., which takes on literal values. Complex attribute can contain collections and/or references. Complex attribute can contain collections and/or references. Reference attribute represents relationship. Reference attribute represents relationship. complex object: contains one or more complex attributes complex object: contains one or more complex attributes

7. CS540 Software Design 7Lecture 13 Methods and messages Method: Defines behavior of an object, as a set of encapsulated functions. Message: Request from one object to another asking second object to execute one of its methods. (a) (b) (a) Object showing attributes and methods (b) Example of a method

8. CS540 Software Design 8Lecture 13 Classes Class: Blueprint for defining a set of similar objects. Objects in a class are called instances.

9. CS540 Software Design 9Lecture 13 Inheritance One class can be used to derive another via inheritance One class can be used to derive another via inheritance Classes can be organized into hierarchies Classes can be organized into hierarchies Bank Account Account Charge Account Savings Account Checking Account

10. CS540 Software Design 10Lecture 13 Inheritance (contd) Inheritance allows one class of objects to be defined as a special case of a more general class. Special cases are subclasses and more general cases are superclasses. Generalization: process of forming a superclass Specialization: forming a subclass Subclass inherits all properties of its superclass and can define its own unique properties. Subclass can redefine inherited methods. All instances of subclass are instances of superclass. Principle of substitutability: instance of subclass can be used whenever method/construct expects instance of superclass. A KIND OF (AKO): Name for relationship between subclass and superclass

11. CS540 Software Design 11Lecture 13 Types of inheritance (a) (b) (c) (a) Single (b) Multiple (c) Repeated (b)

12. CS540 Software Design 12Lecture 13 Inheritance (contd) Define humanBeing to be a class Define humanBeing to be a class A humanBeing has attributes, such as age, height, gender A humanBeing has attributes, such as age, height, gender Assign values to attributes when describing object Assign values to attributes when describing object Define Parent to be a subclass of HumanBeing Define Parent to be a subclass of HumanBeing A Parent has all attributes of a HumanBeing, plus attributes of his/her own (name of oldest child, number of children) A Parent has all attributes of a HumanBeing, plus attributes of his/her own (name of oldest child, number of children) A Parent inherits all attributes of humanBeing A Parent inherits all attributes of humanBeing The property of inheritance is an essential feature of object-oriented languages such as Smalltalk, C++, Ada 95, Java (but not C, FORTRAN) The property of inheritance is an essential feature of object-oriented languages such as Smalltalk, C++, Ada 95, Java (but not C, FORTRAN)

13. CS540 Software Design 13Lecture 13 Inheritance (contd) UML notation UML notation Inheritance is represented by a large open triangle Inheritance is represented by a large open triangle

14. CS540 Software Design 14Lecture 13 Java implementation

15. CS540 Software Design 15Lecture 13 Overriding and Overloading Overriding: Process of redefining a property within a subclass. Overloading: Allows name of a method to be reused with a class or across classes. Overriding Example: Might define method in Staff class to increment salary based on commission method void giveCommission(float branchProfit) { salary = salary + 0.02 * branchProfit; } May wish to perform different calculation for commission in Manager subclass: method void giveCommission(float branchProfit) { salary = salary + 0.05 * branchProfit; }

16. CS540 Software Design 16Lecture 13 Aggregation UML Notation UML Notation

17. CS540 Software Design 17Lecture 13 Association UML Notation UML Notation

18. CS540 Software Design 18Lecture 13 Equivalence of Data and Action Classical paradigm Classical paradigm record_1.field_2 record_1.field_2 Object-oriented paradigm Object-oriented paradigm thisObject.attributeB thisObject.attributeB thisObject.methodC() thisObject.methodC()

19. CS540 Software Design 19Lecture 13 Example – Chapter 7 Schach (2002) Design of an operating system for a large mainframe computer. It has been decided that batch jobs submitted to the computer will be classified as high priority, medium priority, or low priority. There must be three queues for incoming batch jobs, one for each job type. When a job is submitted by a user, the job is added to the appropriate queue, and when the operating system decides that a job is ready to be run, it is removed from its queue and memory is allocated to it Design of an operating system for a large mainframe computer. It has been decided that batch jobs submitted to the computer will be classified as high priority, medium priority, or low priority. There must be three queues for incoming batch jobs, one for each job type. When a job is submitted by a user, the job is added to the appropriate queue, and when the operating system decides that a job is ready to be run, it is removed from its queue and memory is allocated to it Design 1 (Next slide) Design 1 (Next slide) Low cohesion—operations on job queues are spread all over product Low cohesion—operations on job queues are spread all over product

20. CS540 Software Design 20Lecture 13 Data Encapsulation — Design 1

21. CS540 Software Design 21Lecture 13 Data Encapsulation — Design 2

22. CS540 Software Design 22Lecture 13 Data Encapsulation m_encapsulation has informational cohesion m_encapsulation has informational cohesion m_encapsulation is an implementation of data encapsulation m_encapsulation is an implementation of data encapsulation Data structure ( job_queue ) together with operations performed on that data structure Data structure ( job_queue ) together with operations performed on that data structure Advantages Advantages Development Development Maintenance Maintenance

23. CS540 Software Design 23Lecture 13 Data Encapsulation and Development Data encapsulation is an example of abstraction Data encapsulation is an example of abstraction Job queue example Job queue example Data structure Data structure job_queue job_queue Three new functions Three new functions i nitialize_job_queue i nitialize_job_queue add_job_to_queue add_job_to_queue delete_job_from_queue delete_job_from_queue Abstraction Abstraction Conceptualize problem at higher level Conceptualize problem at higher level job queues and operations on job queues job queues and operations on job queues not lower level not lower level records or arrays records or arrays

24. CS540 Software Design 24Lecture 13 Stepwise Refinement Step 1: Design in terms of high level concepts It is irrelevant how job queues are implemented Step 2: Design low level components Totally ignore what use will be made of them In 1st step, assume existence of lower level In 1st step, assume existence of lower level Concern is the behavior of the data structure Concern is the behavior of the data structure job_queue job_queue In 2nd step, ignore existence of high level In 2nd step, ignore existence of high level Concern is the implementation of that behavior Concern is the implementation of that behavior In a larger product, there will be many levels of abstraction In a larger product, there will be many levels of abstraction

25. CS540 Software Design 25Lecture 13 Data Encapsulation and Maintenance Identify aspects of product likely to change Identify aspects of product likely to change Design product so as to minimize the effects of change Design product so as to minimize the effects of change Data structures are unlikely to change Data structures are unlikely to change Implementation may change Implementation may change Data encapsulation provides a way to cope with change Data encapsulation provides a way to cope with change

26. CS540 Software Design 26Lecture 13 Implementation of Class JobQueue C++ Jav a Jav a

27. CS540 Software Design 27Lecture 13 Implementation of queueHandler C++ Java

28. CS540 Software Design 28Lecture 13 Data Encapsulation and Maintenance (contd) What happens if queue is now implemented as a two-way linked list of JobRecord? What happens if queue is now implemented as a two-way linked list of JobRecord? Module that uses JobRecord need not be changed at all, merely recompiled Module that uses JobRecord need not be changed at all, merely recompiled C++ C++ Java Java

29. CS540 Software Design 29Lecture 13 Abstract Data Types Problem with both implementations Problem with both implementations Only one queue Only one queue Need Need We need: We need: Data type + operations performed on instantiations of that data type Abstract data type Abstract data type

30. CS540 Software Design 30Lecture 13 Abstract Data Type (contd) (Problems caused by public attributes solved later) (Problems caused by public attributes solved later)

31. CS540 Software Design 31Lecture 13 Information Hiding Data abstraction Data abstraction Designer thinks at level of an ADT Designer thinks at level of an ADT Procedural abstraction Procedural abstraction Define a procedure—extend the language Define a procedure—extend the language Instances of a more general design concept, information hiding Instances of a more general design concept, information hiding Design the modules in way that items likely to change are hidden Design the modules in way that items likely to change are hidden Future change is localized Future change is localized Changes cannot affect other modules Changes cannot affect other modules

32. CS540 Software Design 32Lecture 13 Information Hiding (contd) C++ abstract data type implementation with information hiding C++ abstract data type implementation with information hiding

33. CS540 Software Design 33Lecture 13 Information Hiding (contd) Effect of information hiding via private attributes Effect of information hiding via private attributes

34. CS540 Software Design 34Lecture 13 Polymorphism and Dynamic Binding Classical paradigm Classical paradigm Must explicitly invoke correct version Must explicitly invoke correct version

35. CS540 Software Design 35Lecture 13 Polymorphism and Dynamic Binding (contd) Object-oriented paradigm Object-oriented paradigm

36. CS540 Software Design 36Lecture 13 Polymorphism and Dynamic Binding (contd) All that is needed is myFile.open() All that is needed is myFile.open() Correct method invoked at run-time (dynamically) Correct method invoked at run-time (dynamically) Method open can be applied to objects of different classes Method open can be applied to objects of different classes Polymorphic Polymorphic

37. CS540 Software Design 37Lecture 13 Polymorphism and dynamic binding (contd) Method checkOrder (b : Base) can be applied to objects of any subclass of Base Method checkOrder (b : Base) can be applied to objects of any subclass of Base

38. CS540 Software Design 38Lecture 13 Polymorphism and Dynamic Binding (contd) Can have a negative impact on maintenance Can have a negative impact on maintenance Code is hard to understand if there are multiple possibilities for a specific method Code is hard to understand if there are multiple possibilities for a specific method Polymorphism and dynamic binding Polymorphism and dynamic binding Strength and weakness of the object-oriented paradigm Strength and weakness of the object-oriented paradigm

39. CS540 Software Design 39Lecture 13 Polymorphism and dynamic binding (contd) Polymorphism: Means ‘many forms’. Dynamic Binding: Runtime process of selecting appropriate method based on an object’s type. Example: With list consisting of an arbitrary no. of objects from the Staff hierarchy, we can write:list[i]. print and runtime system will determine which print() method to invoke depending on the object’s (sub)type.

40. CS540 Software Design 40Lecture 13 Cohesion and Coupling of Objects No such thing! No such thing! Object-oriented cohesion and coupling always reduces to classical cohesion Object-oriented cohesion and coupling always reduces to classical cohesion The only feature unique to the object-oriented paradigm is inheritance The only feature unique to the object-oriented paradigm is inheritance Cohesion has nothing to do with inheritance Cohesion has nothing to do with inheritance Two objects with the same functionality have the same cohesion Two objects with the same functionality have the same cohesion It does not matter if this functionality is inherited or not It does not matter if this functionality is inherited or not Similarly, so-called object-oriented coupling always reduces to classical coupling Similarly, so-called object-oriented coupling always reduces to classical coupling

41. CS540 Software Design 41Lecture 13 Object-Oriented Metrics (contd) Two types of so-called object-oriented metric Two types of so-called object-oriented metric Not related to inheritance Not related to inheritance Reduces to a classical metric Reduces to a classical metric Inheritance-related Inheritance-related May reduce to a classical metric May reduce to a classical metric No problem No problem Classical metrics work just fine Classical metrics work just fine But don’t mislead others by calling them object- oriented But don’t mislead others by calling them object- oriented

42. CS540 Software Design 42Lecture 13 Advantages of Objects Same as as advantages of abstract data types Same as as advantages of abstract data types Information hiding Information hiding Data abstraction Data abstraction Procedural abstraction Procedural abstraction Inheritance provides further data abstraction Inheritance provides further data abstraction Easier and less error-prone product development Easier and less error-prone product development Easier maintenance Easier maintenance Objects are more reusable than modules with functional cohesion Objects are more reusable than modules with functional cohesion

43. CS540 Software Design 43Lecture 13 Summary