1 / 43

CSC 422 Dr. Spiegel

Encapsulation Connascence (born together, dependence) Cohesion. CSC 422 Dr. Spiegel. Encapsulation: Review. Encapsulation separates the contractual interface of an abstraction from its implementation.

lyndon
Télécharger la présentation

CSC 422 Dr. Spiegel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Encapsulation Connascence (born together, dependence) Cohesion CSC 422 Dr. Spiegel

  2. Encapsulation: Review • Encapsulation separates the contractual interface of an abstraction from its implementation. • Levels of encapsulation:Level 0 - No encapsulation Level 1 - Encapsulation within a procedure Level 2 - Encapsulation within a class Level 3 - Encapsulation within a package Level 4 - Encapsulation within a component

  3. Class Interaction:Buttons and Lamps – The Use Case and the Model Name: Turn lamp on and off Actors: ButtonPusher Type: Primary Description: When the ButtonPusher presses the button, the lamp goes on if it was off, and goes off if it was already on. Button Lamp Turn on() or Turn off()

  4. Coding Directly from the Model Problems: Any change to Lamp will require a corresponding change to (or at least a recompilation of) Button It is very difficult to reuse either component alone, for example a button to start a motor and not to turn on a lamp

  5. A better solution Button Client {abstract} Button {abstract} Button Implementation Lamp

  6. Why is it better? • Underlying abstraction is to relay an on/off gesture from a user to a target object • Has removed implementation from the abstraction • Button knows nothing about implementation of detecting the user gesture • Button knows nothing about Lamp • Highly resistant to change and high level abstractions are easily reused elsewhere • Use case requirements are still easily traceable in the design

  7. Code Solution ---------button.cc---------------- #include button.h #include buttonClient.h Button::Button(ButtonClient& bc) : itsClient(&bc) {} void Button::Detect() { bool buttonOn = GetState(); if (buttonOn) itsClient->TurnOn(); else itsClient->TurnOff(); } ----buttonClient.h----- class ButtonClient { public: virtual void TurnOn() = 0; virtual void TurnOff()= 0; }; -------button.h-------- class ButtonClient; //external? class Button { public: Button(ButtonClient&); void Detect(); virtual bool GetState() = 0; private: ButtonClient* itsClient; }; -----------lamp.h---------------- class Lamp : public ButtonClient { public: virtual void TurnOn(); virtual void TurnOff(); }; ---------buttonImp.h------------- class ButtonImplementation : public Button { public: ButtonImplementaton(ButtonClient&); virtual bool GetState(); };

  8. OO Key Design Ideas - The Open/Closed Principle • Classes should be open for extension, but closed for modification • A class is open for extension if we can add functionality to it: e.g. expand the set of operations or add fields to its data structures • A class is closed for modification if it is available for use by other classes: i.e. it has a stable and well-defined interface • This is normally implemented with inheritance/polymorphism in OO systems

  9. Connascence • Definition • two modules (classes, or methods) are so intertwined that if you make a change to one it is likely that a change in the other will be required. • measure of how well encapsulation is applied within the system

  10. Connascence • Connascence between two software elements A and B means either • that you can postulate some change to A that would require B to be changed (or at least carefully checked) in order to preserve overall correctness, or • that you can postulate some change that would require both A and B to be changed together in order to preserve overall correctness.

  11. Connascence • a generalization of the notions coupling and cohesion from structured design for more complex encapsulation structures. • Fan-out is the measure for the number of references to other procedures by lines of code within a given procedure. • Cohesion is a measure of the “single-mindedness” of the lines of code within a given procedure in meeting the purpose of that procedure. • Coupling is a measure of the number and strength of connections between procedures.

  12. Types of Connascence

  13. Types of Connascence (con’t) • Static connascence – can be determined from the code/structure of the classes • connascence of name - int i; i := 7 • connascence of type or class - both i’s should have the same type • connascence of convention – for example, different ranges of account numbers have different meanings • connascence of algorithm - two elements that share the same algorithm • connascence of position • sequential – have to appear in the right order • adjacent – have to be next to each other • for example, actual parameters should have the same order as the formal parameters

  14. Types of Connascence (con’t) • Dynamic connascence - based on the execution pattern of the running code, i.e. more on the objects than on the classes • connascence of execution – for example, initialization of a variable before use • connascence of timing – for example, an instruction to stop a röntgen machine has to be given within 50 ms after the instruction to start it • connascence of value – for example, a arithmetical constraint: the 3 angles of a triangle are 180 degrees together • connascence of identity – for example, 2 objects (O1 and O2) that refer both to an other object, always have to refer to the same object O3 • contranescence - connascence of difference – for example, if a class C inherits from class A and B, then the methods of A and B should not have the same names

  15. Connascence and Encapsulation • Encapsulation can be used to manage connascence • Directives: • Minimize overall connascence by breaking the system into encapsulated components • Minimize any remaining connascence that crosses encapsulation boundaries • Maximize the connascence within encapsulation boundaries

  16. Connascence abuses in OO systems • The friend function of C++ • gives an other class access to the private/implementation aspects of a class - thus large connascence beyond encapsulation boundaries • Unconstrained inheritance • Gives subclasses access to the private/implementation aspects of the superclass • (Separate inheritance of abstract behavior from inheritance of the internal implementation of that behavior!) • Relying on accidents of implementation • Use of accidents of the implementation causes connascence of algorithm – for example, a class SET in which items are taken from the set in the same order as in which they where added to the set

  17. Domains, Encumbrance, Cohesion, & Coupling • Domains: regions where classes play a role • Encumbrance: burden, impediment, complexity of a class • Cohesion: coherence of a class • Coupling: Level of interdependence between entities

  18. Class Cohesion • Measures the interrelatedness of the features in the external interface of a class • How good is the cohesion of a class as an implementation of an abstraction • Low cohesion - bad! high cohesion - good! • No quantitative measure • Some people say: the higher the overlap in use of private variables by methods, the higher the cohesion, but • Cohesion has to be visible from outside • Private/implementation variables can change without influencing the interface, so the measure is instable

  19. Symptoms of low class cohesion • Mixed Instance Cohesion - the class has some features that are undefined for some objects of the class • Example: class Salesperson has an attribute commission-rate, but a Salesperson works either commission-based or not. In the second case commission-rate is irrelevant • Solution for Mixed Instance Cohesion is normally to split the class into subclasses • Salesperson splits into Commissioned_Salesperson and NonCommissioned_Salesperson

  20. Symptoms of low class cohesion • Mixed Domain Cohesion - where the class contains features that are not relevant for the domain of the class • Here domain is: • Application domain - contains classes important for an application • Business domain - contains classes important for an industry or company • Architecture domain - contains classes important for an implementation architecture • Foundation domain - contains classes important for all kinds of companies and architectures • Semantic subdomain - DATE, TIME, MONEY • Structural subdomain - QUEUE, SET, LIST • Fundamental subdomain - INTEGER, BOOLEAN

  21. Mixed Domain Cohesion • Example - Class REAL contains the method arctan • But arctan is not really an aspect of a REAL number, it is an aspect of a class ANGLE. • For example, does a class REAL need a method convert-temp, since this method converts a real number into an other real number? • Features have to be essential for a class. • Ask if the class can be built without the class of the other feature – for example, can REAL be built without ANGLE? ANGLE without REAL?

  22. Symptoms of Mixed Domain Cohesion • Mixed Role Cohesion - the class has a feature from the same domain, but is not part of the abstraction • Example: class PERSON has a method number_of_dogs_owned • But Dogs are not really part of the abstraction person, they are not an essential part • Do we have to add methods for cats, horses, parakeets, goldfishes, etc.? • Mixed Role Cohesion reduces the reusability of a class

  23. Class Cohesion

  24. Method Cohesion

  25. Encumbrance of a class • Quantitative measure for the complexity of a class. • The direct class-reference set of a class C consists of those classes to which C refers directly, i.e. classes D such that: • C inherits from D • C has an attribute of class D • C has an operation with an input argument of class D • C has a variable of class D • C has a method that sends a message with a return argument of class D • C supplies D as an actual class parameter to a parameterized class • C has a friend class D (in C++)

  26. Encumbrance of a class • Let the direct class-reference set of C comprise the classes C1, C2, ..., Cn. • Then the indirect class-reference set of C is the union of the direct class-reference set of C and the indirect class-reference sets of C1, C2, ..., Cn. • The direct encumbrance of a class is the size of its direct class-reference set. The indirect encumbrance of a class is the size of its indirect class-reference set.

  27. The class Rectangle and its indirect class-reference set with each class’s indirect encumbrance marked. Rectangle 4 Point 3 Length 2 Boolean 0 Real 0

  28. Coupling • What is Coupling? • how interdependent or interrelated modules(classes, objects, methods) are in a system • when one class depends on another we say they are coupled

  29. Types of Coupling • Inheritance Coupling • how tightly coupled the classes are in an inheritance hierarchy • Interaction Coupling • coupling among methods and objects through message passing

  30. Interaction Coupling

  31. Cohesion vs. Coupling • Goal: • High Cohesion • Low Coupling • Functions handle a single task completely, while depending on others as little as possible

  32. Law of Demeter Messages should be sent only by an object to itself to an object contained in an attribute of itself or a superclass to an object that is passed as a parameter to the method to an object that is created by the method to an object that is stored in a global variable

  33. Law of Demeter • Guideline to limit the direct encumbrance of a class (Lieberherr and Holland): • For an object obj of class C and for any operation op defined for obj each target object of a message within the implementation of op must be one of the following objects: • The object obj itself • An object referred to by an argument within op’s signature • An object referred to by a variable of obj • An object created by op • An object referred to by a global variable

  34. Subclasses and Subtypes • For class S to be a true subtype of class T, then S must conform to T • A class S conforms to class T, if an object of class S can be provided in any context where an object of class T is expected and correctness is still preserved when any accessor method is executed • Known as the Liskov Substitutability Principle • But we can have subclasses which are not subtypes.

  35. Subclasses and Subtypes (2) • In a sound OO system, all subclasses should also be subtypes, e.g. digit is a specific int subtype • This is not always possible ConicSection Ellipse But what happens when a circle gets a stretch_along_x_axis message? Circle Ellipse Circle

  36. Inheritance Pitfalls • Mistaken Aggregates - using inheritance where the relationship is actually aggregation Aeroplane Wing Tail Fuselage Engine

  37. Abusing Multiple Inheritance Wing Tail Fuselage Engine Aeroplane

  38. Board Member Employee Manager Manager Employee Board member Inverted Hierarchy

  39. Some design problems • Roles versus Inheritance • Example • Computer Science Conference wants a registration system • Conference members can be: • Organisers • Special Guests • Tutorial Presenters • Paper Presenters • Industrial Registrants • Academic Registrants • Student Registrants

  40. A simple solution Conference Member Organiser Special Guest Registrant Tutorial Presenter Paper Presenter Industrial Academic Student

  41. Some problems with the solution • What happens if we have an organiser who is also giving a tutorial? • What happens if a student registrant is also giving a paper? • What happens if a conference member withdraws their paper but still attends as an academic registrant?

  42. A partial solution - multiple inheritance Conference Member Organiser Special Guest Registrant Tutorial Presenter Paper Presenter Organiser Tutorial Presenter Student Paper Presenter Industrial Academic Student

  43. Another solution • In this particular case, multiple inheritance is not a particularly good solution • Roles are a much better solution as they are more flexible performs 1..* Conference Role Conference Member Paper Presenter Organiser Special Guest Tutorial Presenter Registrant Industrial Academic Student

More Related