Object interconnections

Transcription

1 Object interconnections

2 2 Roadmap In this chapter we move up a level of abstraction, and consider collections of objects working together Our focus will be on how objects are connected to each other, and how one can make those connections as loose as possible Our primary tool for analyzing connectedness will be the concepts of visibility and dependency

3 3 Connections - The Bane of Large Scale Programming Difficulties in developing large scale programs are often not so much a matter of algorithmic complexity As they are of communication complexity: If several programmers are working together on a project and need to control the amount of information One programmer must have knowledge about the code being developed by a second programmer We can express interconnections in terms of visibility and dependency

4 4 Visibility Visibility is an attribute of names: Names of variables, functions, fields, whatever Mark Visibility type + Public # Protected - Private If you can't name something, you can't manipulate it Languages already have a variety of mechanisms for the control of name visibility OOP languages introduce a few new twists

5 5 Dependency Dependency describes the degree to which one software component relies on another component to perform its responsibilities A high degree of dependency obviously limits code reuse - moving one component to a new project

6 6 Coupling and Cohesion Coupling refers to the extent to which one component uses another to perform actions Generally a goal is to reduce coupling between software components Cohesion refers to the extent to which the actions of a component seem to be tied together Generally a goal is to increase cohesion within a software component

7 7 Varieties of Coupling Arranged from Bad to Better: Internal data coupling Global data coupling Control (or sequence) coupling Component coupling Parameter coupling Subclass coupling

8 This is bad because it makes it difficult to understand a single class in isolation Changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. Can be mitigated by always making your data areas private or protected, and not exposing pointers to these areas 8 Internal Data Coupling class SneekyModifier { public: void sneeky () { // change my friends name myfriend->name = "Lucy"; Person * myfriend; {; class Person { public: Person () { name = "Larry"; string name; ; Occurs when one module (or class) modifies the local data values (instance variables) in another module (class).

9 9 Global Data Coupling double todaysdow class One { public: void setdow () { todaysdow = 9473; ; class Two { public: void printdow (){ cout << "Today the Dow hit " << todaysdow; ; Two or more classes that interact through a common global variable Again, makes it difficult to understand a single class in insolation Can be mitigated by making a class that manages the global area, thereby reducing global coupling to component coupling

10 10 Control, or Sequence Coupling This occurs when objects are linked by the fact that one must be manipulated before the other, but otherwise they have no connection Again, makes it difficult to understand a class in isolation Can be mitigated by making a controller class, that clearly indicates the sequence of operations: class MyClass { public: dostuff () { dofirst(); dosecond(); protected: dofirst() {... dosecond() {...

11 Control Coupling - control inversion reg_i read registration 1.1 read & check registration reg_i check 1 reg_flag registration 1.2 error_reason error-handler registration 1.3

12 11 Component Coupling Occurs when one class holds an instance of another class: class Set {... private: List data; Ideally, connection is one way Held component has no knowledge of holder This is a very weak and benign connection (weak is good)

13 12 Parameter Coupling Parameter coupling occurs when one object knows of another only through being passed as a parameter or a return value Another very weak (and therefore good) type of coupling class MyClass { public: void dosomething (Set aset) {...

14 13 Subclass Coupling Subclass coupling describes the relationship between a parent class and a child class Ideally the parent has no strong connection to the child, so the connection is one way Can understand the parent in isolation from the child class Parent {... class Child extends Parent {... A very weak form of coupling. Which makes it a good design choice

15 14 Varieties of Cohesion Also arranged from bad to better: Coincidental cohesion Logical cohesion Temporal cohesion Functional cohesion

16 15 Coincidental cohesion Coincidental cohesion is the lowest form of cohesion found in object oriented software development Methods appear to have been placed there randomly or without consideration of the proper concern of the method: public static class Utils { // A utility method that helps out with error logging. public static void LogError(String msg( { MyLogger logger = new MyLogger(); // Create instance of logger class logger.logit(msg); // A utility method that displays a message to the user. public static void ShowMsg(String msg( { MessageBox.Show(msg); This type of class necessarily leads to tight coupling as its varied functionality is used in many places

17 16 Logical Cohesion All elements of the module perform similar operations: Error handling, data input, data output, etc. An example of logical cohesion: A set of print functions to generate an output report arranged into a single module A crucial point is that only a specific subset of the functions is used in a specific context In general, logically cohesive modules should be avoided, if possible

18 16 Logical Cohesion

19 17 Temporal cohesion A temporally cohesive module is one whose elements are functions that are related in time Example: Consider a module called On_Really_Bad_Failure that is invoked when a Really_Bad_Failure happens The module performs several tasks that are not functionally similar or logically related, but all tasks need to happen at the moment when the failure occurs.: cut power to all assembly line machines notify the operator console of the failure make an entry in a database of failure records

20 20 Functional cohesion A functionally cohesive module performs one and only one problem related task. Examples of functionally cohesive modules are: Drag Drop an event triggered when a dragged object is dropped on a window Sum Elements in Array Convert Kilometers to Miles Read Customer Record Calculate Net Pay Assign Account Number Functionally cohesive modules may be simple and perform one task However, a complex module with numerous sub-modules may still be functionally cohesive if all of its subordinate modules are only performed to carry out the task of the parent module For example: Calculate Net Pay is functionally cohesive although it contains many different functions (e.g., calculate taxable deductions, calculate tax, calculate CPP deduction)

21 21 Data Cohesion Elements cooperate to present an interface to a hidden data structure: Stack Windows Communication Protocol Data Base Employee

22 22 Limiting Coupling The Law of Demeter The law of Demeter is an attempt to limit the way in which one component can interact with another component: In a method M attached to a class C, only methods defined by the following classes may be used: 1. The instance variable classes of C 2. The argument classes of method M (including C( Note that global objects or objects created inside the method M are considered arguments to M

23 23 Rewritten in terms of messages Law of Demeter (weak form). Inside a method, it is only permitted to access or send messages to the following objects: 1. The arguments associated with the method being executed (including the self object) 2. Instance variables for the receiver of the method 3. Global variables 4. Temporary variables created inside the method.

24 25 Class-Level versus Object-Level Visibility Here is another interesting way that objectoriented languages have chosen to differ from each other: Question: Are sisters and brothers allowed to look at each others private data fields? An answer of YES is class-level visibility (C++ and Java( And answer of NO is object-level visibility (Smalltalk(

25 27 Public, Subclass and Private Faces We have noted several times that object have a public and private face - inheritance introduces a third alternative, the subclass face: Public features are those aspects that users of the software component must have access to. Private features are those aspects that the implementor of the software component must have access to Protected features are those aspects that implementors of child classes can have access to There are two types of clients for the class developer: User clients (those who use an instance of the class( Subclass clients (those who will subclass from the class(

26 28 Control of Visibility The public/protected/private modifiers are the primary way to control visibility in most OO languages There are other mechanisms as well: (לא נלמד) C++ Friends in (לא נלמד ) C++ Inner classes in Java and Private Inheritance in C++ (inheritance for construction( Name Spaces, Units or Packages

27 31 Private Inheritance in C++ In a public inheritance the public features of a parent become public features of a child In a private inheritance, the public and protected features of the parent do not filter through the child; and only the public features of the child are visible The child class does not subscribe to the is-a rule We called this Inheritance For Construction

28 32 Name Spaces, Packages or Units Names Spaces (C++), Packages (Java) or Units (Delphi and Object Pascal) give the programmer another way to encapsulate names, and release only those names that are necessary: package foo; public class bar { // will be visible... class baz { // will not be visible outside package...

29 34 Chapter Summary In this chapter we have examined a variety of topics related to dependency: How classes and objects can depend upon each other How methods within a class can depend upon each other How to control visibility, as a means of controlling dependency How strong dependency can be weakened by using alternative designs