2. 7.1/108 Introduction To Objects

3. 7.2/108 Modules Cohesion and low Coupling Data encapsulation Abstract data types Information hiding Objects Objects with high Cohesion and low Coupling Towards Software Engineering

4. 7.3/108 Overview Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

5. 7.4/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

6. 7.5/108 Glossary … Cohesion: The degree of interaction within a module, Coupling: The degree of interaction between two modules, Abstraction: A means of achieving stepwise refinement by suppressing unnecessary details and accentuating relevant details, Abstract Data Type: a data type together with the actions performed on instantiations of that data type, Class: an abstract data type that support inheritance.

7. 7.6/108 Glossary (Cont’d) Encapsulation: The gathering together into one unit of all aspects of the real-world entity modeled by that unit, Data encapsulation: a data structure together with the actions performed on that data structure, Object: a instantiation of a class, Information hiding: structuring the design so that the resulting implementation details will be hidden from the other modules.

8. 7.7/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

9. 7.8/108 Introduction to Objects Background: OO concepts was introduced in … 1966 in the simulation language Simula 67. However, the technology was too radical for practical use, so it lay dormant till the ’80 when it was reinvented with the context of the theory of modularity, “It seems that we human beings adopt new ideas only when we are ready to use them, not necessarily when they are first presented.” [Schach], Ready for OR Need for?

10. 7.9/108 So, What Is a Module? … Try your own definition… “A set of contiguous program statement having a name by which other parts of the system can invoke it, and probably having its own distinct set of variable names”. [Stevens, Myers and Constantine, 1974], Covers procedures, functions, methods etc., What about assembler macro? Or #include files? Or an Ada package?

11. 7.10/108 What Is a Module? (Cont’d) A lexically contiguous sequence of program statements, bounded by boundary elements, with an aggregate identifier. [Yourdon and Constantine, 1979], Covers all the above ++: { } blocks, objects, methods etc.

12. 7.11/108 Modularization Ex. – HW Design … A computer architect decides to build an ALU, shifter and 16 registers using AND, OR, and NOT gates. (rather than NAND or NOR gates),

13. 7.12/108 Computer Design (Cont’d) … Architect designs 3 silicon chips, l There are few and distinguished interfaces between them.

14. 7.13/108 Computer Design (Cont’d) … But than … vaguely he recalls that someone at the bar… told him … Redesign with one gate type per chip. (thinking that this is the best way to do that), Resulting “masterpiece.”:

15. 7.14/108 Computer Design (Cont’d) The two designs are functionally equivalent, yet, the second design is: Hard to understand, Hard to locate faults, Difficult to extend or enhance, Cannot be reused in another product, Modules must be like the first design: l Maximal relationships within (Cohesion), l Minimal relationships between (Coupling).,

16. 7.15/108 Composite / Structured Design C/SD, Method for breaking up a product into modules for: –Maximal interaction within module, and. –Minimal interaction between modules, Module cohesion – אחדות Degree of interaction within a module, Module coupling – קשריות. Degree of interaction between two modules.

17. 7.16/108 Function, Logic, and Context of Module Module’s Action – What it does, Module’s logic – How it performs its action, Module’s Context – the specific usage of that module, In C/SD the name of a module is its action, Example: module computes square root (action) of double precision integers (context), using Newton’s algorithm (logic), Module’s name Compute_Square_Root.

18. 7.17/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

19. 7.18/108 Cohesion Degree of interaction within a module, Seven cohesion categories (non-linear scale): OOD, CSD

20. 7.19/108 1.Coincidental Cohesion … A module has coincidental cohesion if it performs multiple, completely unrelated actions, Example: –Print next line, reverse string of characters comprising second parameter, add 7 to fifth parameter, convert fourth parameter to floating point, Coincidental cohesion arise from rules like: –“Every module will consist of between 35 and 50 statements.”

21. 7.20/108 1.Coincidental Cohesion (Cont’d) Why is Coincidental Cohesion so bad? Degrades maintainability, Modules are not reusable, The good news: This is easy to fix, Break into separate modules each performing one task,

22. 7.21/108 2.Logical Cohesion … A module has logical cohesion when it performs a series of related actions, one of which is selected by the calling module, Example 1: –op_code = 7; new operation (op_code, dummy 1, dummy 2, dummy 3); // dummy 1, dummy 2, and dummy 3 are dummy variables, // not used if function code is equal to 7.

23. 7.22/108 2.Logical Cohesion (Cont’d) … Example 2: Module performing all input and output, Example 3: A module performing editing of insertions and deletions and modifications of master file records, Example 4: One version of OS/VS2 contained logical cohesion module performing 13 different actions. Interface contained 21 pieces of data.

24. 7.23/108 2.Logical Cohesion (Cont’d) … Why is Logical Cohesion so bad? The interface is difficult to understand, as it contains a real ‘junkyard’ data, out of which few are relevant to a specific call, Code for more than one action may be intertwined, Difficult to reuse,

25. 7.24/108 2.Logical Cohesion (Cont'd) … Assume a module that handles ALL I/O operations. It might look like this:

26. 7.25/108 2.Logical Cohesion (Cont'd) What will be the effect of adding a new tape? We might need to update 1,2,3,4,6,9, & 10. What is the effect on the laser printer?,

27. 7.26/108 3.Temporal Cohesion … A module has Temporal Cohesion when it performs a series of actions related in time, Example: –open old master file, new master file, transaction file, print file, initialize sales district table, read first transaction record, read first old master record (a.k.a. perform initialization), Is it good for real-time?, Is it necessary for real-time?

28. 7.27/108 3.Temporal Cohesion (Cont’d) … Why is Temporal Cohesion so bad? Actions of this module are weakly related to one another, but strongly related to actions in other modules, More chance to regression fault, a fault caused by a change to an apparently unrelated part of the product. Thus, when we will be debugging it, we won’t look at the error area, Not reusable.

29. 7.28/108 3.Temporal Cohesion (Cont’d) Consider sales region table, l It is initialized in this module, but actions like Update sales region table and Print sales sales region table, are located in other modules, l Once the sales region table structure is modified, we will have to update ‘irrelevant’ modules – causing regression faults.

30. 7.29/108 4.Procedural Cohesion … A module has Procedural Cohesion if it performs a series of actions related by the procedure to be followed by the product. That is implementing sequence of actions from the users’ viewpoint, yet – on different data, Example: Read part number and update repair record on master file.

31. 7.30/108 4.Procedural Cohesion (Cont’d) Why is Procedural Cohesion so bad? Actions are still weakly connected, So module is not reusable.

32. 7.31/108 5.Communicational Cohesion … A module has Communicational Cohesion if it performs a series of actions related by the procedure to be followed by the product, but in addition all the actions operate on the same data, Example 1: update record in database and write it to audit trail, Example 2: calculate new coordinates and send them to terminal, Communicational Cohesion is also known as Sequential Cohesion.

33. 7.32/108 5.Communicational Cohesion (Cont’d) Why is Communicational Cohesion so bad? Still lack of reusability.

34. 7.33/108 7.AInformational Cohesion … A module has Informational Cohesion if it performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure, A major difference between logical cohesion and informational cohesion is that the various actions of a module with logical cohesion are intertwined, whereas in a module with informational cohesion the code (program) for each action is completely independent, Informational cohesion is optimal for OOP.

35. 7.34/108 Why Is Informational Cohesion So Good? Essentially, this is an abstract data type (see later).

36. 7.35/108 7.bFunctional Cohesion … Module with Functional Cohesion performs exactly one action or achieves a single goal, Example 1: Get temperature of furnace, Example 2: Compute orbital of electron, Example 3: Write to floppy disk, Example 4: Calculate sales commission.

37. 7.36/108 Why Is Functional Cohesion So Good? … More reusable, More readable and understandable, Corrective maintenance easier: –Fault isolation, –Fewer regression faults, Easier to extend product. (Example: ALU design)(Example: ALU design)

38. 7.37/108 Why Is … ? (Cont’d) A module with functional cohesion can often be reused because the one action it performs will often need to be performed in other products, “ A properly designed, thoroughly tested, and well- documented module with functional cohesion is a valuable (economic and technical) asset to any SW organization and should be used as often as possible ”.

39. 7.38/108 Cohesion Case Study (Cont’d) … Functional Coincidental Logical Functional Coincidental Procedural? Try to define the cohesion level of each module.

40. 7.39/108 Cohesion Case Study (Cont’d) As of initialize sums and open files modules: –…Actions are related in time, –But, sum initialization is related to the problem while, –File opening got nothing to do with the problem!, Rule: when assigning cohesion level to a module: assign the lowest possible level.

41. 7.40/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

42. 7.41/108 Coupling Degree of interaction between two modules, Five categories or levels of coupling (non-linear scale):

43. 7.42/108 1.Content Coupling … Two modules are Content Coupled if one directly references contents of the other, Example 1: – Module a modifies statement of module b. Feasible in assembler and even high languages, Example 2: – Module a refers to local data of module b in terms of some numerical displacement within b, Example 3: – Module a branches into local label of module b.

44. 7.43/108 1.Content Coupling (Cont’d) Why is Content Coupling so bad? – Almost any change to b, even recompiling b with new compiler or assembler, requires change to a. – It is impossible to reuse module a without reusing module b as well.

45. 7.44/108 2.Common Coupling … Two modules are Common Coupled if both have write access to global data: l Example 1: Modules cca and ccb can access and change value of global variable.

46. 7.45/108 2.Common Coupling (Cont'd) … Example 2: Modules cca and ccb both have access to same database, and can both read and write same record, Example 3: FORTRAN common, COBOL common (nonstandard), COBOL-80 global.

47. 7.46/108 2.Common Coupling (Cont'd) … Why is Common Coupling so bad? – Contradicts the spirit of structured programming, – – The resulting code is virtually unreadable: l Anyone can change global variable value!, Who changes global variable?

48. 7.47/108 2.Common Coupling (Cont'd) … Why is Common Coupling so bad? (Cont’d), – Modules can have side-effects. This affects their readability. Example: Edit_This _Record( Record7) – what else does this module does? Entire module must be read to find out what it does. – A change to a global variable enforce ‘total code review’.

49. 7.48/108 2.Common Coupling (Cont'd) Why is Common Coupling so bad? (Cont’d), – Difficult to reuse. (The global variables list is to be scanned), – Security danger: module exposed to more data than necessary. (Can the payroll programmer access his own salary?) And yet, common coupling might be a preferable solution in some cases: –Consider a record with some 60 different fields, –Do we pass them all each time (With high potential of mismatch) or - –Do we declare the record as a global variable?, –(OR do we use information hiding?…)

50. 7.49/108 3.Control Coupling … Two modules are Control Coupled if one passes an element of control to the other, that is, one module explicitly controls the logic of the other, Example 1: –Operation code passed to module with Logical Cohesion.Logical Cohesion

51. 7.50/108 3.Control Coupling (Cont’d) … Example 2: – Control-switch passed as argument, – Assume module p call module q. Module q passes back a flag to module p. – Assume that flag meaning is “I’m unable to complete the task”. Module q passes data, – But if flag meaning is “I’m unable to complete the task, write an error message”. Then p and q are control-coupled.

52. 7.51/108 3.Control Coupling (Cont’d) Why is Control Coupling so bad? Modules are not independent; Module b (the called module) must know internal structure and logic of module a, Affects reusability, Associated with modules of logical cohesion.

53. 7.52/108 4.Stamp Coupling … Two modules are Stamp Coupled if a data structure is passed as a parameter, but the called module operates on some but not all of the individual components of the data structure, Many languages support passing of data structures: –Part record. –Satellite coordinates. –Segment table.

54. 7.53/108 4.Stamp Coupling (Cont’d) … Why is Stamp Coupling so bad? It is not clear, without reading the entire module, which fields of a record are accessed or changed. –Example: calculate withholding (employee record). Which records’ fields are altered? Accessed?, Difficult to understand, Unlikely to be reusable, More data than necessary is passed. –Uncontrolled data access can lead to computer crime.

55. 7.54/108 4.Stamp Coupling (Cont’d) Stamp Coupling – Bad? (Cont’d) –There is nothing wrong with passing a data structure as a parameter, provided all the components of the data structure are accessed and/or changed. Examples: Invert matrix (original matrix, inverted matrix); Print inventory record (warehouse record);, –Notice that passing a pointer might cause a stamp coupling (in case that only some of the pointed data is needed)!

56. 7.55/108 5.Data Coupling … Two modules are Data Coupled if all parameters are homogeneous data items [simple parameters, or data structures whose elements are all used by called module], Examples: –Display time of arrival (flight number); –Compute product (first number, second number); –Get job with highest priority (job queue);

57. 7.56/108 5.Data Coupling (Cont’d) Why is Data Coupling So Good? –The difficulties of content, common, control, and stamp coupling are not present. Maintenance is easier.

58. 7.57/108 Coupling Case Study … # In Out 1 – A/C Type Status Flag 2 – – A/C parts List 3 – Function code – 4 – – A/C parts List 5 – Part number Part Manufacturer 6 – Part number Part name __________________________ A/C – Aircraft

59. 7.58/108 Coupling Case Study (Cont'd) … Define coupling between all pairs of modules, Data- Data or Stamp Control - Common -- Data- - Common

60. 7.59/108 Coupling Case Study (Cont'd) Good design has high cohesion and low coupling. What else characterizes good design? How to achieve that? Out of the scope of that lecture…

61. 7.60/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

62. 7.61/108 Data Encapsulation — Example Design an OS for a mainframe computer, There must be a queues for incoming batch jobs, Assume that all submitted jobs are at same priority level, When a job is submitted by a user, the job is added to the queue, and when the OS decides that a job is ready to be run, it is removed from the queue and memory is allocated to it.

63. 7.62/108 Data Encapsulation — Design 1

64. 7.63/108 Data Encapsulation – Example Design 1, :What did we omit ? –Underflow (trying to remove a job from an empty queue), –Overflow (trying to add a job to a full queue), As for the design data encapsulation: — Low cohesion — operations on job queues are spread all over product, — If we change queue implementation (e.g. linked records list instead of linear list), we will have to change m_1, m_2, m_3 and m_123 as well (why?). (that is high coupling!), Yet, we encapsulated the data!

65. 7.64/108 Data Encapsulation — Design 2

66. 7.65/108 Data Encapsulation Design 2: –m_encapsulation has informational cohesion:informational cohesion –Data structure (job_queue) together with operations performed on that data structure, –Each action has its own entry and exit points, as well as independent code, –m_encapsulation is an implementation of data encapsulation. That is, a data structure together with the actions to be performed on that data, Advantages of data encapsulation: –Development, –Maintenance.

67. 7.66/108 Data Encapsulation and Development Data encapsulation is an example of abstraction, Job queue example: –Data structure: job_queue. –Three new functions: initialize_job_queue, add_job_to_queue & delete_job_from_queue, Abstraction (Stepwise refinement, again): –Conceptualize problem at higher level: job queues and operations on job queues. –not lower level: records or arrays.

68. 7.67/108 Stepwise Refinement 1.Design in terms of high level concepts. –It is irrelevant how job queue is implemented, –A ssume existence of lower level, –Concern is the behavior of the data structure: Job_queue, l 2.Design low level components. –Totally ignore what use will be made of them, –I gnore existence of high level. –Concern is the implementation of that behavior (DB & Functions), l In a larger product, there will be many levels of abstraction.

69. 7.68/108 Levels of Abstraction … Operating System Layers [Dijkstra]: – Level 5: Computer Operator, – Level 4: User Program, – Level 3: …, – Level 2: …, – Level 1: Memory Segment Controller, – Level 0: Clock interrupt handling and Processor allocation, Each of the higher level of abstraction is implemented using some of the functions of the levels below it.

70. 7.69/108 Levels of Abstraction (Cont’d) … Computer abstraction [Tanenbaum]: – Level 5: Problem-oriented language, – Level 4: Assembly language, – Level 3: Operating System, – Level 2: Machine code (Hex), – Level 1: Microprogramming, – Level 0: Digital Logic, It is possible to replace the microprogramming level with no interference to the levels above or below!

71. 7.70/108 Levels of Abstraction (Cont’d) There are different types of abstraction: Data Abstraction: Data structure together with the actions to be performed on that data, Procedural Abstraction: The C functions themselves, Example, Example Encapsulation: gathering together into one unit all aspects of the real world entity modeled by that unit, The effect is language extension. C now includes initialize_job_queue() as well as printf().

72. 7.71/108 Data Encapsulation and Maintenance Look Ahead: Identify aspects of product likely to change, Design product so as to minimize the effects of change: –Data structures are unlikely to change. –Implementation may change, Data encapsulation provides a way to cope with changes. Thus, data encapsulation is a technique.

73. 7.72/108 Implementation of Class JobQueue C++ Java, Common Coupling, Or Informational Cohesion?

74. 7.73/108 queueHandler – Using jobQueue C++ Java

75. 7.74/108 Data En. and Maintenance (Cont'd) 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, C++, Java

76. 7.75/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

77. 7.76/108 Abstract Data Types (ADT) Problem with Java and C implementations:Java C –Only one queue, we need high, medium and low priorities queues. We need: –Data type + operations performed on instantiations of that data type, On next example – ignore the public statement – it will be solved later.

78. 7.77/108 ADT Example 1 (Java) … class Scheduler { … public void queueHandler() { int job1, job2; JobQueuehighPriorityQueue = new JobQueue (); JobQueuemediumPriorityQueue = new JobQueue (); JobQueuelowPriorityQueue = new JobQueue (); // some statements highPriorityQueue.initializeJobQueue(); // some more statements mediumPriorityQueue.addJobToQueue(job1); // still more statements lowPriorityQueue.removeJobFromQueue(job2); // even more statements } //queueHandler }// class Scheduler

79. 7.78/108 ADT Example 1 (Cont’d) The statement highPriorityQueue.initializeJobQueue(); means: apply method initializeJobQueue() to data structure highPriorityQueue, Abstract data types support both data abstraction and procedural abstraction, In addition, when a product is modified it is unlikely that the abstract data types will be changed.

80. 7.79/108 ADT Example 2 … Suppose we need to perform action on rational numbers, A rational number can be written in the form of n/d where n and d are integers, and d  0, We chose to represent rational as a class – data with the appropriate actions, Problems caused by public attributes will be solved later.

81. 7.80/108 ADT Example 2 (Cont’d) Redundant data!

82. 7.81/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

83. 7.82/108 Information Hiding … Data abstraction: –Designer thinks at level of an ADT, Procedural abstraction: –Define a procedure — extend the language, These are instances of a more general design concept, information hiding (or – details hiding): –Design the modules in way that items likely to change are hidden, –Future change is localized, –Changes cannot affect other modules, In the scheduler implementation, one could execute highPriorityQueue.queue[7] = -5678 … changing priority without using any method!scheduler

84. 7.83/108 Information Hiding – C++ (Cont'd) …

85. 7.84/108 Information Hiding – Java (Cont'd) …

86. 7.85/108 Information Hiding (Cont’d) Information hiding can be used to obviate common coupling as well: If a product is implemented with private actions for initializing a descriptor and public actions for obtaining the value of a descriptor, then there is no common coupling.

87. 7.86/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

88. 7.87/108 Objects … First refinement: –Product is designed in terms of abstract data types (ADT). –Variables (“objects”) are instantiations of abstract data types, Second refinement: –Class: abstract data type that supports inheritance. –Objects are instantiations of classes.

89. 7.88/108 Objects (Cont’d) Nothing special about objects – ordinary ADT or modules with informational cohesion. They have all the properties possessed by their predecessors as well as additional properties of their own. informational cohesion

90. 7.89/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

91. 7.90/108 Inheritance … The basic idea behind Inheritance: new data types can be defined as extensions of previously defined types, rather than having to define them from scratch, In OO language we can define a class. A class is an abstract data type that supports inheritance, An object is an instantiation of a class.

92. 7.91/108 Inheritance (Cont’d) … Define humanBeing to be a class. –A humanBeing has attributes, such as age, height, gender. –Assign values to attributes when describing object, 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 inherits of humanBeing, The property of inheritance all attributes is an essential feature of object-oriented languages such as Smalltalk, C++, Ada 95, Java, but not in C, COBOL or FORTRAN. Nor do own these the class concept.

93. 7.92/108 Inheritance (Cont'd) UML notation: “isA” –Inheritance is represented by a large open triangle, Terminology: Specialization –Parent is a specialization of HumanBeing, Generalization –HumanBeing is a generalization of Parent.

94. 7.93/108 Inheritance – Java Implementation

95. 7.94/108 Aggregation Aggregation refers to the components of class, UML Notation: an empty diamond – “a part of”.

96. 7.95/108 Association Association refers to a relationship of some kind between apparently unrelated classes. (What is the relation between a radiologist and an artist?), UML Notation: solid pointing triangle.

97. 7.96/108 Equivalence of Data and Action Classical paradigm: –record_1.field_2; –That is, field_2 is a member of record_1. The period denotes membership, Object-oriented paradigm: –thisObject.attributeB; –thisObject.methodC (); –The period denotes membership, whether the member is an attribute or a method, Objects advantages are precisely those of ADT, In addition, classes inheritance provides another layer of abstraction.

98. 7.97/108 Polymorphism and Dynamic Binding … Suppose that the OS is called to open a file: but the file may reside on the disk, or a tape or a diskette, Classical paradigm: –Must explicitly invoke the correct version. –Thus, at run-time, my_file type is to be known or tested, so OS will use the correct procedure: open_disk_file, open_tape_file, or open_diskette_file, l In OO – we define one class, with three derived classes.

99. 7.98/108 Poly. and Dynamic Binding (Cont'd) … Object-oriented paradigm, We cannot define open in the parent class, as other actions are needed for each media,

100. 7.99/108 Poly. and Dynamic Binding (Cont'd) … A dummy method will be defined in the parent class. (Java notation is abstract), A specific implementation of the method appears in each derived class, yet each is given an identical name – myFile.open(), Method open can be applied to objects of different classes, At run-time the message is myFile.open() is sent and the OO system will determines, according with the myFile type, which method will be activated!, That is Dynamic Binding.

101. 7.100/108 Poly. and Dynamic Binding (Cont'd) … Method checkOrder (b : Base) can be applied to objects of any subclass of Base.

102. 7.101/108 Poly and Dynamic Binding (Cont'd) Can have a negative impact on maintenance: –Code is hard to understand if there are multiple possibilities for a specific method, –It is generally not possible to determine at compilation time which version of a polymorphic method will be invoke at run-time, –Might have a negative impact on maintenance, as code might become very vague, Polymorphism and dynamic binding: –Strength and weakness of the object-oriented paradigm,

103. 7.102/108 Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

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

105. 7.104/108 Object-oriented Metrics 1: Those who are not related to inheritance. –Reduces to a classical metric, 2: Inheritance-related, E.g.: The height of the inheritance tree. –May reduce to a classical metric, No problem! –Classical metrics work just fine. –But don’t mislead others by calling them object-oriented.

106. 7.105/108 Modules Modules with high Cohesion and low Coupling Data encapsulation Abstract data types Information hiding Objects Objects with high Cohesion and low Coupling Towards Software Engineering

107. 7.106/108 Advantages of Objects Same as the advantages of abstract data types: –Information hiding, –Data abstraction, –Procedural abstraction, Inheritance provides further data abstraction: –Easier and less error-prone product development. –Easier maintenance, Objects are more reusable than modules with functional cohesion.

108. 7.107/108 Summary Glossary, What is a module? Cohesion, Coupling, Data encapsulation, Abstract data types, Information hiding, Objects, Inheritance, polymorphism and dynamic binding, Cohesion and coupling of objects.

109. 7.108/108 Introduction To Objects The End