7.1/108 Introduction To Objects 7.2/108 Modules Cohesion and low Coupling Data encapsulation...

7.1/108

Introduction

To

Objects

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

7.3/108Overview

• 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.

7.4/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,

• Inheritance, polymorphism and dynamic binding,


7.5/108Glossary …

• 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.6/108Glossary (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.

7.7/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.8/108Introduction 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?

7.9/108So, 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?

7.10/108What 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.

7.11/108Modularization 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),

7.12/108Computer Design (Cont’d) …

• Architect designs 3 silicon chips ,

There are few and distinguished interfaces between them.

7.13/108Computer 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.”:

7.14/108Computer 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:

Maximal relationships within (Cohesion) , Minimal relationships between (Coupling).

,

7.15/108Composite / 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.

7.16/108Function, 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.

7.17/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.18/108Cohesion

• Degree of interaction within a module,

• Seven cohesion categories (non-linear scale):

OOD,

CSD

7.19/1081. 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.”

7.20/1081. 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 ,

7.21/1082. 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.

7.22/1082. 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.

7.23/1082. 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 ,

7.24/1082. Logical Cohesion (Cont'd) …

• Assume a module that handles ALL I/O operations.It might look like this:

7.25/1082. 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? ,

7.26/1083. 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?

7.27/1083. 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.

7.28/1083. Temporal Cohesion (Cont’d)

• Consider sales region table,

It is initialized in this module, but actions like Update sales region table and Print sales sales region table, are located in other modules ,

Once the sales region table structure is modified, we will have to update ‘irrelevant’ modules – causing regression faults.

7.29/1084. 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.

7.30/1084. Procedural Cohesion (Cont’d)

• Why is Procedural Cohesion so bad?

• Actions are still weakly connected ,

• So module is not reusable.

7.31/1085. 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.

7.32/1085. Communicational Cohesion (Cont’d)

• Why is Communicational Cohesion so bad?

• Still lack of reusability.

7.33/1087.A Informational 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.

7.34/108Why Is Informational Cohesion So Good?

• Essentially, this is an abstract data type (see later).

7.35/1087.b Functional 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.

7.36/108Why 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)

7.37/108Why 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”.

7.38/108Cohesion Case Study (Cont’d) …

Functional

Coincidental

Logical

Functional Functional

Functional

Coincidental

Procedural?

Try to define the cohesion level of each module.

7.39/108Cohesion 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.

7.40/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.41/108Coupling

• Degree of interaction between two modules,

• Five categories or levels of coupling (non-linear scale):

7.42/1081. 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.

7.43/1081. 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.

7.44/1082. Common Coupling …

• Two modules are Common Coupled if both have write access to global data:

Example 1:Modules cca and ccb can access and change value of global variable.

7.45/1082. 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.


• Why is Common Coupling so bad?– Contradicts the spirit of structured programming, – – The resulting code is virtually unreadable:

Anyone can change global variable value!,

Who changes global variable?


• 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’.

7.48/1082. 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?…)

7.49/1083. 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.

7.50/1083. 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.

7.51/1083. 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.

7.52/1084. 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.

7.53/1084. 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.

7.54/1084. 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)!

7.55/1085. 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);

7.56/1085. 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.

7.57/108Coupling Case Study …

# In Out1 – A/C Type Status Flag2 – – A/C parts List 3 – Function code – 4 – – A/C parts List 5 – Part number Part Manufacturer6 – Part number Part name

__________________________A/C – Aircraft

7.58/108Coupling Case Study (Cont'd) …

• Define coupling between all pairs of modules,

Data -Data orStamp

Data orStamp

Control

-

Common Common

- -

Data -- Data

Common

7.59/108Coupling 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…

7.60/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.61/108Data 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.

7.62/108Data Encapsulation — Design 1

7.63/108Data 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!

7.64/108Data Encapsulation — Design 2

7.65/108Data Encapsulation

• Design 2:– m_encapsulation has 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.

7.66/108Data 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.

7.67/108Stepwise Refinement

• 1. Design in terms of high level concepts.– It is irrelevant how job queue is implemented,

– Assume existence of lower level,– Concern is the behavior of the data structure: Job_queue,

2. Design low level components.– Totally ignore what use will be made of them,

– Ignore existence of high level.– Concern is the implementation of that behavior (DB &

Functions) , In a larger product, there will be many levels of

abstraction.

7.68/108Levels 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.

7.69/108Levels 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!

7.70/108Levels 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,

• 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().

7.71/108Data 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.

7.72/108Implementation of Class JobQueue

C++

Java,

CommonCoupling,Or

Informational Cohesion?

7.73/108queueHandler – Using jobQueue

C++ Java

7.74/108Data 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

7.75/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.76/108Abstract Data Types (ADT)

• Problem with Java and C implementations:– 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.

7.77/108ADT Example 1 (Java) …class Scheduler{

…public void queueHandler(){ int job1, job2; JobQueue highPriorityQueue = new JobQueue ();

JobQueue mediumPriorityQueue = new JobQueue (); JobQueue lowPriorityQueue = new JobQueue ();

// some statements highPriorityQueue.initializeJobQueue();

// some more statements mediumPriorityQueue.addJobToQueue(job1);

// still more statements lowPriorityQueue.removeJobFromQueue(job2);

// even more statements } //queueHandler}// class Scheduler

7.78/108ADT 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.

7.79/108ADT 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 d0,

• We chose to represent rational as a class – data with the appropriate actions ,

• Problems caused by public attributes will be solved later.

7.80/108ADT Example 2 (Cont’d)

Redundantdata!

7.81/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.82/108Information 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!

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

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

7.85/108Information 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.

7.86/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.87/108Objects …

• 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.

7.88/108Objects (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.

7.89/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.90/108Inheritance …

• 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.

7.91/108Inheritance (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.

7.92/108Inheritance (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.

7.93/108Inheritance – Java Implementation

7.94/108Aggregation

• Aggregation refers to the components of class ,

• UML Notation: an empty diamond – “a part of”.

7.95/108Association

• 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.

7.96/108Equivalence 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.

7.97/108Polymorphism 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,

In OO – we define one class, with three derived classes.

7.98/108Poly. and Dynamic Binding (Cont'd) …

• Object-oriented paradigm,

• We cannot define open in the parent class, as other actions are needed for each media ,


• 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.


• Method checkOrder (b : Base) can be applied to objects of any subclass of Base.

7.101/108Poly 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 invokeat run-time,

– Might have a negative impact onmaintenance, as code might become very vague,

• Polymorphism and dynamic binding:– Strength and weakness of the object-oriented

paradigm ,

7.102/108

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.103/108Cohesion 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.

7.104/108Object-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.

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

7.106/108Advantages 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.

7.107/108Summary

• Glossary,


• Cohesion,

• Coupling,




• Objects,



7.108/108

Introduction

To Objects

The End

7.1/108 Introduction To Objects 7.2/108 Modules Cohesion and low Coupling Data encapsulation...

Documents

Transcript of 7.1/108 Introduction To Objects 7.2/108 Modules Cohesion and low Coupling Data encapsulation...