+ All Categories
Home > Documents > Object Interconnections

Object Interconnections

Date post: 24-Feb-2016
Category:
Upload: menora
View: 66 times
Download: 0 times
Share this document with a friend
Description:
Object Interconnections. CMPS 2143. Object Interconnections. Past few chapters: focused on individual classes in isolation or classes in parent/child relationships This chapter: focused on relationships between groups of classes or objects working together - PowerPoint PPT Presentation
Popular Tags:
37
Object Interconnections CMPS 2143
Transcript
Page 1: Object Interconnections

Object InterconnectionsCMPS 2143

Page 2: Object Interconnections

Object Interconnections•Past few chapters: focused on individual classes in

isolation or classes in parent/child relationships

•This chapter: focused on relationships between groups of classes or objects working together

•Concern is on visibility and dependency

Page 3: Object Interconnections

Visibility•Characterization of names▫or handles by which objects are accessed▫Related term is scope of an identifier

•Visibility is related to connectedness ▫If an identifier is not visible, it cannot be accessed

▫Smalltalk for example: identifiers cannot be accessed/modified outside the class, without calling one of the class’ methods

▫Apple Object Pascal: all instance variables are visible if class is visible

Page 4: Object Interconnections

Dependency

•Relates one object or class to another▫If an object cannot exist meaningfully without another, it

is dependent▫A child class is almost always dependent on its parent

class

•Dependency can be more subtle though.

Page 5: Object Interconnections

Coupling and Cohesion•Good modular design that requires▫Low coupling ▫High cohesion

•Coupling – describes the relationships between classes•Cohesion – describes the relationships of the members

within a class

•Well-designed classes ▫Should have a purpose▫All elements should be associated with a single task

Page 6: Object Interconnections

Varieties of Coupling (Worst to Best)• Internal Data Coupling▫Instances of one class can directly modify instance

variables in an instance of another class

•Global Data Coupling▫Two or more classes rely on some common global data

structure▫Solution – create another class to hold and manage this

data

•BOTH of these BAD – because it complicates ability to understand class in isolation

Page 7: Object Interconnections

Varieties of Coupling (Worst to Best)•Control (or Sequence) Coupling▫An instance of one class must perform operations in a

fixed order, but that order is controlled elsewhere▫When unavoidable, object assures ops performed in

correct order

•Component Coupling▫An instance on a class has-a member data field that is an

instance of another class▫Ideally the relationship should be only one way▫Examples: Set used a List and Bag used a Dictionary

Page 8: Object Interconnections

Varieties of Coupling (Worst to Best)•Parameter Coupling▫An instance of one class must invoke services (methods)

from another and the only relationships are the number and type of parameters supplied and the type returned

▫Common, easy to see, easy to verify statically▫Example: void List::insertInOrder (String s);

Will have to call String equals method

•Subclass Coupling▫Particular to OOP▫Relationship a class has with its parent class

Page 9: Object Interconnections

Varieties of Cohesion (Weakest to Best)•Coincidental▫When elements of a class are grouped for no apparent

reason▫Often result of “modularizing” a large program arbitrarily

• Logical▫When there is a logical connection among elements, but

no actual connection in either data or control▫Example: Math class

Page 10: Object Interconnections

Varieties of Cohesion (Worst to Best)•Temporal▫When elements are bound together because they all must

be used at approximately the same time Example: program initialization or finalization

•Communicational▫When methods in a class are grouped because they all

access the same I/O data or devices▫Class acts as a “manager” of the data or device

Page 11: Object Interconnections

Varieties of Cohesion (Worst to Best)•Sequential▫When elements in a class are linked by the necessity to be

activated in a particular order▫Usually the result of avoiding sequential coupling

•Functional▫Desirable type of binding of elements when they all relate

to the performance of a single function

•Data▫Class defines a set of data values and makes public

methods that manipulate the data abstraction

Page 12: Object Interconnections

Give-a-ways for estimate degree of coupling•Purpose statement of class is a compound sentence▫Containing commas or more than one verb▫Probably sequential or communicational coupling

•Purpose statement of class refers to time▫First, next, then, after, when, start▫Probably sequential or temporal coupling

•Purpose statement does not contain a single, specific object following a verb▫Edit all data logical binding▫Edit source data functional binding

•Purpose statement contains words initialize, clean-up▫Probably temporal binding

Page 13: Object Interconnections

Style Guidelines for Modular Programming

•Style guidelines range from abstract to direct▫“Modules should exhibit low coupling and high cohesion”▫“No method should contain more than 60 lines”

•Direct guidelines easier to follow, but they lull you into a false sense of security and direct attention away from real problem

•Are there any good guidelines for OOP?

Page 14: Object Interconnections

Law of Demeter• In any method, M, in a class, C, only methods defined by

the following classes may be used▫The instance variables classes of C (has-a relationships)class C { public void M ( ) { s.somemethod();} private SomeClass s;}

▫The argument classes of method M (including C)class C { public void M (Someclass s) {

s.somemethod();}}

Page 15: Object Interconnections

Law of Demeter – Weak Form• In a method, M, permitted to access or send messages

only to the following objects▫Arguments associated with method M (including self)class C { public void M (Someclass s) {

s.somemethod();}}

▫Instance variables for the receiver of the method This data members and parent data members Allows for protected

▫Global variables▫Temporary variables created inside the method

Page 16: Object Interconnections

Law of Demeter – Strong Form• In a method, M, permitted to access or send messages

only to the following objects▫Arguments associated with method M (including self)

▫Instance variables defined in the class containing M Cannot access instance variables of parent classes except

through their accessor functions Does not allow for protected Eliminates subclass coupling

▫Global variables▫Temporary variables created inside the method

Page 17: Object Interconnections

Class-level versus Object-level Visibility•Classes can have multiple instances

•Class-level visibility▫C++ control visibility on this level▫Treats all instances of a class in the same manner▫Provides range of visibility controls▫Even with private data fields, an instance of a class

permitted access to data fields in other instances of class Example: Copy constructors

Page 18: Object Interconnections

Class-level versus Object-level Visibility•Object-level visibility▫Smalltalk – no object is permitted access to inner state of

another object, even if they are instances of the same class

Page 19: Object Interconnections

Subclass clients and User clients

•Subclass clients can access parent’s public and protected members▫Assuming language has class visibility and protected

access modifier

•User clients can only access public members of another class

Page 20: Object Interconnections

Control of Access and Visibility•Smalltalk▫Instance variables are always private▫Methods are always public

• Java▫public and private refers to class, not instance of class

Sibling members of the same class permitted to access each other’s private data fields.

▫protected refers to package A protected feature accessible anywhere within package

▫final A final class can not be subclassed A final instance variable cannot be assigned to

Page 21: Object Interconnections

Control of Access and Visibility•C++▫Has public, private and protected▫Instance variables and methods are by default private▫Access modifiers define properties of class, not of

instances Sibling instances (other objects of same class) may access

each other’s member data Example: operator + for ComplexNumber

Weak form of Law of Demeter supported by protected Strong form of Law supported by private

Page 22: Object Interconnections

Control of Access and Visibility•C++▫public vs private class inheritance (default is public)

▫public class inheritance corresponds to inheritance for specialization (that is subclass is subtype) Supports principle of substitution Can use polymorphism

▫private class inheritance corresponds to inheritance for construction

Page 23: Object Interconnections

Friendship

•Another aspect of visibility in C++ is concept of a friend function.

•Friends of a class are not members of the class, yet can access the non-public members of the class

•A class can have two types of friends▫Friend functions▫Friend classes

Page 24: Object Interconnections

Friendship

• Friendship is granted, not taken-i.e. for class B to be a friend of class A, class A must explicitly declare that class B is its friend.• Friendship is not symmetric. For example, if class A is a

friend of class B, this does not necessarily mean that class B is also a friend of class A.• Friendship is not transitive. For example if class A is a

friend of class B and class B is a friend of class C, we cannot infer that class A is a friend of class C.

Page 25: Object Interconnections

Friend Functions

• To declare a function as friend of a class, precede the function prototype in the class definition with keyword friend.• Member access notions of private, public etc. are not

relevant to friend declaration, so friend declarations can be placed anywhere in a class definition.• As a good programming practice, place all friendship

declarations first inside the class definition’s body and do not precede them with any access specifier

Page 26: Object Interconnections

Friend Function Example

class Count{ friend void setX(Count & c, int val);

public:Count(): x(0) {}void print() const {cout<<x<<endl;}

private:int x;

};

Page 27: Object Interconnections

Friend Function Example

void setX(Count & c, int val){ c.x=val;}

void main(){Count counter;counter.print();setX(counter, 8);counter.print();

}

Page 28: Object Interconnections

Friend Class Example#include <iostream>using namespace std;

class A {friend class B;int x;

public: A(): x(0){} int get() const {return x; } void set(int y){x=y; }

};

Page 29: Object Interconnections

Friend Class Example

class B {int z;

public: void set(A & a) {a.x=20; } int get() const {return z; }

};

Page 30: Object Interconnections

Friend Class Example

void main(){A a1;B b1;b1.set(a1);cout<<a1.get()<<endl;

}

Page 31: Object Interconnections

Other friend examples

•Prototypes for overloaded << and >> friend functions can be declared inside of ComplexNumber class (but they are NOT methods)▫Can put the definition in the .cpp file, BUT do NOT

precede it with friend ComplexNumber::

• class Node can be a friend class of LinkedList ▫Can put it in Node.h and Node.cpp files now

Page 32: Object Interconnections

Concerns about friends

•Powerful tool•Easy to abuse▫Introduce data couplings

•Avoid them! Use them ONLY when no other tool will work.

Page 33: Object Interconnections

C++ Namespaces and Java Packages

•Reduce proliferation of global names•Static can limit scope of a name to a single file•Use Namespaces and Packaged when name is needed in

two or more files and avoiding global variables

Page 34: Object Interconnections

C++ Namespaces

namespace myLibrary { int x; class A { }; class B { };}

using namespace myLibrary; using myLibary::B;myLibrary::A anA;

Page 35: Object Interconnections

Java Packages

package myPackage; //first statement //in the file

import myPackage.*; import myPackage.B;myPackage.A anA = new myPackage.A();

Page 36: Object Interconnections

Intentional Dependency•Most programmers attempt to avoid dependency•Some situations, it is unavoidable

Example: ▫A viewer (such as a graphical display component)

associated with underlying data component (or model) Every time values change, the display needs to be updated

▫Can use a dependency manager as a go-between Model need only know about the dependency manager Viewers “register” with dependency manager When model changes, it sends a single message to

dependency manager…who subsequently notifies all dependents

▫COMMON DESIGN PATTERN Model-View-Controller

Page 37: Object Interconnections

Study

•pg. 461: 2, 9-14


Recommended