Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-31T01:15:23Z

Smrober4: /* Single-choice */

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

== Meyer's Principles ==

=== Small Interfaces ===

Meyer’s principle of small [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces] states that if two [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer responsible for implementing the interface. By designing and implementing a small interface, the programmer also minimizes [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] between modules.

Below is an example of a small interface written in [http://java.sun.com/javase/6/docs/technotes/guides/language/index.html Java].

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduces coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing too much information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface, which in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the [http://docs.eiffel.com/eiffelstudio/docs_no_content.html Eiffel] language does not support nested classes.

All [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, programmers must choose to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another through their individual interaction with a common [http://en.wikipedia.org/wiki/Global_variable global variable]. This is an example of [http://www.site.uottawa.ca:4321/oose/commoncoupling.html common coupling] and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but programmers must be sure to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

[http://www.ruby-lang.org/en/ Ruby] supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

[http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx C#] is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, [http://en.wikipedia.org/wiki/C_(programming_language) C], and [http://en.wikipedia.org/wiki/C%2B%2B C++] are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the [http://www.microsoft.com/NET/ .NET] language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance. The single-choice principle has to do with separation of responsibility and encapsulation. Like the small interfaces and explicit interfaces principles, following the single-choice principle is a design decision made by the programmer. All object-oriented languages support the ability to abide by this principle, as long as the programmer follows good principles of object-oriented design.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

== References ==

# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 48]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 50]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 57]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 54]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 63]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-31T00:48:44Z

Smrober4: /* Explicit Interfaces */

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

== Meyer's Principles ==

=== Small Interfaces ===

Meyer’s principle of small [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces] states that if two [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer responsible for implementing the interface. By designing and implementing a small interface, the programmer also minimizes [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] between modules.

Below is an example of a small interface written in [http://java.sun.com/javase/6/docs/technotes/guides/language/index.html Java].

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduces coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing too much information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface, which in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the [http://docs.eiffel.com/eiffelstudio/docs_no_content.html Eiffel] language does not support nested classes.

All [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, programmers must choose to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another through their individual interaction with a common [http://en.wikipedia.org/wiki/Global_variable global variable]. This is an example of [http://www.site.uottawa.ca:4321/oose/commoncoupling.html common coupling] and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but programmers must be sure to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

[http://www.ruby-lang.org/en/ Ruby] supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

[http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx C#] is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, [http://en.wikipedia.org/wiki/C_(programming_language) C], and [http://en.wikipedia.org/wiki/C%2B%2B C++] are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the [http://www.microsoft.com/NET/ .NET] language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

== References ==

# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 48]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 50]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 57]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 54]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 63]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-31T00:41:27Z

Smrober4: /* Small Interfaces */

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

== Meyer's Principles ==

=== Small Interfaces ===

Meyer’s principle of small [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces] states that if two [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer responsible for implementing the interface. By designing and implementing a small interface, the programmer also minimizes [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] between modules.

Below is an example of a small interface written in [http://java.sun.com/javase/6/docs/technotes/guides/language/index.html Java].

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduces coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing too much information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface, which in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the [http://docs.eiffel.com/eiffelstudio/docs_no_content.html Eiffel] language does not support nested classes.

All [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, programmers must choose to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common [http://en.wikipedia.org/wiki/Global_variable global variable]. This is an example of [http://www.site.uottawa.ca:4321/oose/commoncoupling.html common coupling] and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

[http://www.ruby-lang.org/en/ Ruby] supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

[http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx C#] is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, [http://en.wikipedia.org/wiki/C_(programming_language) C], and [http://en.wikipedia.org/wiki/C%2B%2B C++] are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the [http://www.microsoft.com/NET/ .NET] language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

== References ==

# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 48]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 50]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 57]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 54]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 63]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-27T16:36:21Z

Smrober4: /* Small Interfaces */

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

== Meyer's Principles ==

=== Small Interfaces ===

Meyer’s principle of small [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces] states that if two [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer who is responsible for keeping their interfaces small, thereby decreasing [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] between modules.

Here is an example of a small interface in [http://java.sun.com/javase/6/docs/technotes/guides/language/index.html Java].

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing too much information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface that in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting its clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the [http://docs.eiffel.com/eiffelstudio/docs_no_content.html Eiffel] language does not support nested classes.

All [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, it is up to programmers to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common [http://en.wikipedia.org/wiki/Global_variable global variable]. This is an example of [http://www.site.uottawa.ca:4321/oose/commoncoupling.html common coupling] and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

[http://www.ruby-lang.org/en/ Ruby] supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

[http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx C#] is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, [http://en.wikipedia.org/wiki/C_(programming_language) C], and [http://en.wikipedia.org/wiki/C%2B%2B C++] are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the [http://www.microsoft.com/NET/ .NET] language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

== References ==

# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 48]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 50]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 57]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 54]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 63]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-27T03:23:50Z

Smrober4:

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

== Meyer's Principles ==

=== Small Interfaces ===

Meyer’s principle of small [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces] states that if two [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer who is responsible for keeping their interfaces small, thereby decreasing [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] between modules.

Here is an example of a small interface in [http://java.sun.com/javase/6/docs/technotes/guides/language/index.html Java].

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing more information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface that in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting its clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the [http://docs.eiffel.com/eiffelstudio/docs_no_content.html Eiffel] language does not support nested classes.

All [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, it is up to programmers to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common [http://en.wikipedia.org/wiki/Global_variable global variable]. This is an example of [http://www.site.uottawa.ca:4321/oose/commoncoupling.html common coupling] and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

[http://www.ruby-lang.org/en/ Ruby] supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

[http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx C#] is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, [http://en.wikipedia.org/wiki/C_(programming_language) C], and [http://en.wikipedia.org/wiki/C%2B%2B C++] are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the [http://www.microsoft.com/NET/ .NET] language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

== References ==

# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 48]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 50]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 57]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 54]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 63]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-27T03:22:59Z

Smrober4:

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

=== Small Interfaces ===

Meyer’s principle of small [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces] states that if two [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer who is responsible for keeping their interfaces small, thereby decreasing [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] between modules.

Here is an example of a small interface in [http://java.sun.com/javase/6/docs/technotes/guides/language/index.html Java].

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing more information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface that in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting its clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the [http://docs.eiffel.com/eiffelstudio/docs_no_content.html Eiffel] language does not support nested classes.

All [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented] languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, it is up to programmers to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common [http://en.wikipedia.org/wiki/Global_variable global variable]. This is an example of [http://www.site.uottawa.ca:4321/oose/commoncoupling.html common coupling] and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

[http://www.ruby-lang.org/en/ Ruby] supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

[http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx C#] is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, [http://en.wikipedia.org/wiki/C_(programming_language) C], and [http://en.wikipedia.org/wiki/C%2B%2B C++] are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the [http://www.microsoft.com/NET/ .NET] language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

== References ==

# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 48]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 50]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 57]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 54]
# [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1 Object Oriented Software Construction, 2nd edition, page 63]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-27T03:06:17Z

Smrober4: /* Single-choice */

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

=== Small Interfaces ===

Meyer’s principle of small interfaces states that if two modules must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer who is responsible for keeping their interfaces small, thereby decreasing coupling between modules. The principle of small interfaces can be somewhat subjective because there is not a widely accepted test to determine whether the principle has been violated.

Here is an example of a small interface in Java.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing more information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface that in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting its clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the Eiffel languages does not support nested classes.

All object-oriented languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, it is up to programmers to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [*]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common global variable. This is an example of common coupling and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://en.wikipedia.org/wiki/Uniform_access_principle]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

Ruby supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

C# is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, C, and C++ are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [*]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the .NET language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [*]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-27T01:47:25Z

Smrober4:

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

=== Small Interfaces ===

Meyer’s principle of small interfaces states that if two modules must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer who is responsible for keeping their interfaces small, thereby decreasing coupling between modules. The principle of small interfaces can be somewhat subjective because there is not a widely accepted test to determine whether the principle has been violated.

Here is an example of a small interface in Java.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing more information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface that in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting its clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the Eiffel languages does not support nested classes.

All object-oriented languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, it is up to programmers to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [*]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common global variable. This is an example of common coupling and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://en.wikipedia.org/wiki/Uniform_access_principle]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

Ruby supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

C# is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, C, and C++ are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [*]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the .NET language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [http://en.wikipedia.org/wiki/Single_choice_principle].

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-27T01:45:58Z

Smrober4: /* Self-documentation */

'''Meyer's principles.''' Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?
----

== Introduction ==

What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?

=== Small Interfaces ===

Meyer’s principle of small interfaces states that if two modules must interact, then the least amount of information should be shared between them [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-1]. The correct implementation of this principle often depends on the programmer who is responsible for keeping their interfaces small, thereby decreasing coupling between modules. The principle of small interfaces can be somewhat subjective because there is not a widely accepted test to determine whether the principle has been violated.

Here is an example of a small interface in Java.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
}

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing more information to clients.

public class EmployeeDb {
public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
public void setDb(DbConnection db) { // implementation… }
public DbConnection getDb() { // implementation… }
public void setTransaction(Transaction trx) { // implementation… }
public Transaction getTransaction() { // implementation… }
public Employee getEmployee(int employeeId) { // implementation… }
public void saveEmployee(Employee emp) { // implementation… }
public class FindCriteria {
public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
public getEmployeeId() { // implementation… }
public getName() { // implementation… }
public getBirthDate() { // implementation… }
public getPhone() { // implementation… }
}
}

The above example adds five additional operations to our interface that in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting its clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the Eiffel languages does not support nested classes.

All object-oriented languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, it is up to programmers to follow the principle of small interfaces, thereby reducing coupling within their applications.

=== Explicit Interfaces ===

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [*]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another via their individual interaction with a common global variable. This is an example of common coupling and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but it is up to the programmer to keep this principle in check.

=== Uniform-access ===

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [http://en.wikipedia.org/wiki/Uniform_access_principle]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

Ruby supports the uniform-access principle as illustrated by this example.

class Circle
# circumference and area are calculated and stored
attr_accessor :circumference, :area
PI = 3.142

def initialize(radius)
@circumference = PI*radius*2
@area = PI*radius*radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

In the above example, the <code>circumference</code> and <code>area</code> properties of <code>Circle</code> were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

class Circle
# circumference and area are calculated and stored
PI = 3.142

def circumference()
PI*@radius*2
end

def area()
PI*@radius*radius
end

def initialize(radius)
@radius = radius
end
end

# create a new circle
c = Circle.new(4)
# access properties of circle
puts c.circumference
puts c.circumference()
puts c.area
puts c.area ( )

C# is another language that supports the uniform-access through the use of its [http://en.wikipedia.org/wiki/Property_%28programming%29 properties] language feature. Java, C, and C++ are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

=== Self-documentation ===

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [*]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this [https://svn.origo.ethz.ch/eiffelstudio/branches/eth/origo_integration/Src/Eiffel/switch/communication/status/call_stack/eiffel_call_stack_classic.e example].

Java and many of the .NET language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special [http://en.wikipedia.org/wiki/Javadoc Javadoc] notation to describe classes and methods. Here is an example of that notation for describing a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Stack.html Stack].
/**
* The Stack class represents a last-in-first-out (LIFO) stack of objects.
*/
public class Stack {

/**
* Creates an empty Stack.
*/
public Stack() { // implementation... }

/**
* Tests if this stack is empty.
*/
public boolean empty() { // implementation... }

/**
* Looks at the object at the top of this stack without removing it from the stack.
*/
public Object peek() { // implementation... }

/**
* Removes the object at the top of this stack and returns that
* object as the value of this function.
*/
public Object pop() { // implementation... }

/**
* Pushes an item onto the top of this stack.
*/
public Object push(Object item) { // implementation... }
}

C# also has a special syntax for embedding [http://msdn.microsoft.com/en-us/library/b2s063f7(VS.80).aspx XML Documentation] within its modules, which is highlighted by the following example.

/// <summary>
/// The Stack class represents a last-in-first-out (LIFO) stack of objects.
/// </summary>
public class Stack {

/// <summary>
/// Creates an empty Stack.
/// </summary>
public Stack() { // implementation... }

/// <summary>
/// Tests if this stack is empty.
/// </summary>
public bool empty() { // implementation... }

/// <summary>
/// Looks at the object at the top of this stack without removing it from the stack.
/// </summary>
public object peek() { // implementation... }

/// <summary>
/// Removes the object at the top of this stack and returns
/// that object as the value of this function.
/// </summary>
public object pop() { // implementation... }

/// <summary>
/// Pushes an item onto the top of this stack.
/// </summary>
public object push(object item) { // implementation... }
}

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

=== Single-choice ===

What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?

[http://en.wikipedia.org/wiki/Single_choice_principle]

== Conclusion ==

== Also See ==

* [http://en.wikipedia.org/wiki/Bertrand_Meyer Wikipedia: Bertrand Meyer]
* [http://www.tucs.fi/summerschool2001/Meyer/meyer-architecture.pdf Slides: Principles of Object-Oriented Software Architecture]
* [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Wikipedia: Eiffel Programming Language]
* [http://c2.com/cgi/wiki?BertrandMeyerAndHisOpinions Bertrand Meyer And His Opinions]
* [http://www.geocities.com/tablizer/meyer1.htm Critique of Bertrand Meyer's Object Oriented Software Construction]
* [http://www.cetus-links.org/oo_eiffel.html Object Oriented Language: Eiffel]

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-26T23:14:30Z

Smrober4: /* Explicit Interfaces */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-26T23:13:12Z

Smrober4: /* Uniform-access */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-26T22:13:15Z

Smrober4: /* Small Interfaces */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-25T21:19:30Z

Smrober4: /* Self-documentation */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T03:28:27Z

Smrober4: /* Self-documentation */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:51:27Z

Smrober4: /* Explicit Interfaces */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:50:51Z

Smrober4: /* Small Interfaces */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:45:08Z

Smrober4: /* Also See */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:37:49Z

Smrober4: /* Also See */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:35:42Z

Smrober4: /* Uniform-access */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:35:10Z

Smrober4: /* Single-choice */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:34:15Z

Smrober4: /* Also See */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:29:04Z

Smrober4: /* Also See */

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-24T02:26:50Z

Smrober4:

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-23T03:29:51Z

Smrober4:

CSC/ECE 517 Summer 2008/wiki3 8 smr

2008-07-23T03:22:10Z

Smrober4:

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:25:09Z

Smrober4: /* Conclusion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below), the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of their software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying loose coupling will often promote high cohesion and creating highly cohesive modules will often result in loose coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:24:28Z

Smrober4: /* Conclusion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below), the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of their software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:19:16Z

Smrober4: /* Procedural Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below), the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:14:48Z

Smrober4: /* Common coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:14:03Z

Smrober4: /* Procedural Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:13:42Z

Smrober4: /* Logical Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by the fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:11:36Z

Smrober4: /* Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:11:23Z

Smrober4: /* Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 [3]]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:11:01Z

Smrober4: /* Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 3]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T03:10:39Z

Smrober4: /* References */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://javaboutique.internet.com/tutorials/coupcoh/
#http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.site.uottawa.ca:4321/oose/coupling.html
#http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
#http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:53:41Z

Smrober4: /* Conclusion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated each of these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. Experience tells us, however, that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals within object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:50:35Z

Smrober4: /* Measuring Coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes,
primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes,
or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. However, experience tells us that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals in object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:48:33Z

Smrober4: /* Conclusion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Within this article, we have discussed the basic premise of cohesion and provided examples that illustrate the varying degrees of cohesion. By creating modules that are highly cohesive, programmers can prevent costly maintenance, while increasing the readability, reliability, and reusability of their code. Often related to the concept of cohesion is coupling, which we also discussed. Coupling also has varying degrees and we illustrated these using several examples. By reducing coupling between modules, programmers can encourage code reuse as well as simplify maintenance and testing of the software. It is important to consider the relationship between these two similar concepts. As mentioned in the introduction, the goal of object-oriented programming is to have highly cohesive, loosely coupled classes. Applying the low coupling will often promote high cohesion and creating highly cohesive modules will often result in low coupling [http://en.wikipedia.org/wiki/Coupling_(computer_science)]. However, experience tells us that it is not always possible to achieve the highest degree of cohesion and the lowest degree of coupling. Consequently, good engineers should use metrics to measure the degree of cohesion and coupling in their programs and be familiar with the different types of cohesion and coupling so that they may be successful in achieving one of the primary goals in object-oriented programming.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:22:00Z

Smrober4: /* Stamp coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desired form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:21:36Z

Smrober4:

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desirable form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:20:57Z

Smrober4: /* Data coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desirable form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

In this example, <code>Client</code> and <code>CustomerInfo</code> interact using only primitive types of data. This is a desired form of coupling.

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:19:37Z

Smrober4: /* Stamp coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

In this example, the <code>Client</code> and <code>CustomerInfo</code> classes share the common <code>Customer</code> class. This is a desirable form of coupling.

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:17:02Z

Smrober4: /* Control coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example [http://it.toolbox.com/blogs/enterprise-solutions/design-principles-coupling-data-and-otherwise-16061] illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

In this example, the <code>Client</code> class controls the flow of execution within the <code>CustomerInfo</code> module. This form of coupling requires modules calling <code>CustomerInfo</code> to know about the flow of execution within its class.

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:12:58Z

Smrober4: /* Information cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:12:32Z

Smrober4: /* Sequential Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:07:03Z

Smrober4: /* Coupling */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Sequential Cohesion=====
Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

class Cube {
public ArrayList getInfo(){
ArrayList tempList = new ArrayList();
tempList.add(getArea());
tempList.add(getVolume());
return tempList;
}
public double getArea(){return 6*side*side;}
public double getVolume(){return side*side*side;}
}

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between them are said to be highly or tightly coupled. Alternatively, modules that have very little connection between them are said to be lowly or loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and comprehension of the relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T02:02:59Z

Smrober4: /* Functional Cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Sequential Cohesion=====
Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

class Cube {
public ArrayList getInfo(){
ArrayList tempList = new ArrayList();
tempList.add(getArea());
tempList.add(getVolume());
return tempList;
}
public double getArea(){return 6*side*side;}
public double getVolume(){return side*side*side;}
}

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

In this example, all of the operations in the <code>Stack</code> class facilitate the task of supporting a Stack data structure.

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between one another are said to be have high coupled or be tightly coupled. Alternatively, modules that have very little connection between one another are said to have low coupling or be loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and general understanding of relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T01:59:34Z

Smrober4: /* Information cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Sequential Cohesion=====
Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

class Cube {
public ArrayList getInfo(){
ArrayList tempList = new ArrayList();
tempList.add(getArea());
tempList.add(getVolume());
return tempList;
}
public double getArea(){return 6*side*side;}
public double getVolume(){return side*side*side;}
}

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between one another are said to be have high coupled or be tightly coupled. Alternatively, modules that have very little connection between one another are said to have low coupling or be loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and general understanding of relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T01:58:55Z

Smrober4: /* Information cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Communicational cohesion describes modules that perform several tasks against a shared data structure. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

In this example, all of the <code>RectangleTransformer</code> operations are performing actions against the shared <code>rectangle</code> member variable.

=====Sequential Cohesion=====
Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

class Cube {
public ArrayList getInfo(){
ArrayList tempList = new ArrayList();
tempList.add(getArea());
tempList.add(getVolume());
return tempList;
}
public double getArea(){return 6*side*side;}
public double getVolume(){return side*side*side;}
}

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between one another are said to be have high coupled or be tightly coupled. Alternatively, modules that have very little connection between one another are said to have low coupling or be loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and general understanding of relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion

CSC/ECE 517 Summer 2008/wiki2 6 cc

2008-07-08T01:57:43Z

Smrober4: /* Information cohesion */

''Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.''
----

==Introduction==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are concepts often discussed when referring to [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [http://javaboutique.internet.com/tutorials/coupcoh/]. This begs the question as to what is meant by cohesive classes and how do we know when classes are highly cohesive? Further, what does loose coupling mean and how do we know it has been maintained? This article combines information and examples gathered from the Web in an effort to shed some light on these very relevant questions.

In the first section of this article, we provide the basic definition of cohesion along with examples that describe the different types of cohesion. Next, we explain the concept of coupling and use more examples to illustrate the different types of coupling. In the third section of this article, we highlight some of the concepts related to cohesion and coupling, including ways to measure both and an illustration of [http://en.wikipedia.org/wiki/Law_of_Demeter Demeter’s Law]. Lastly, we provide a conclusion to the topics discussed herein.

== Cohesion ==

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] refers to the degree that a [http://en.wikipedia.org/wiki/Module_%28programming%29 module] performs one and only one function. In this context, a module refers to any logical collection of “program entities” [http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf]. This logical collection of program entities could be a [http://en.wikipedia.org/wiki/Function_%28computer_science%29 function], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class], or even a [http://en.wikipedia.org/wiki/Software_package_%28programming%29 package]. As stated earlier, the goal of object-oriented programming is to achieve highly cohesive classes. High cohesion is desired because it increases the likelihood that a module will be comprehendible, reliable, robust, and reusable [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. Alternatively, a module that exemplifies low cohesion is difficult to comprehend, costly to maintain, and less likely to be reused [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29]. The following examples illustrate the different types of cohesion and are arranged from lowest (least desirable) to highest (most desirable).

=====Coincidental Cohesion=====
Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

public static class BackendService {
public static float computeNetPay(int orderId) {
// implementation
}

public static float calculateInventoryReorderAmount(int inventoryId) {
// implementation
}

public static boolean generateInvoice(int invoiceId) {
// implementation
}

// ...
}

In this example, the <code>BackendService</code> provides a one stop shop for many different types of tasks. This type of cohesion is the least desirable and should be avoided.

=====Logical Cohesion=====
Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

public class DataStore {
public void SaveData(int destination, byte[] data) {
switch (destination) {
default:
case 0:
SaveToDb(data)
break;

case 1:
SaveToFile(data)
break;

case 2:
SaveToWebService(data)
break;
}
}

protected void SaveToDb(byte[] data) {
// implementation
}

protected void SaveToFile(byte[] data) {
// implementation
}

protected void SaveToWebService(byte[] data) {
// implementation
}
}

In this example, although all of the operations are logically related by teh fact that they all save data, the truth is they are in fact quite different. Saving to a database likely requires a completely different implementation than saving to a file or web service.

=====Temporal Cohesion=====
Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

public class Startup {
public void Initialize() {
InitializeLogging();

InitializeUI();

InitializeDb();
}

public void InitializeLogging() {
// implementation
}

public void InitializeUI() {
// implementation
}

public void InitializeDb() {
// implementation
}
}

This example highlights a common implementation pattern where tasks are grouped simply by the fact that they need to be executed at around the same time. Aside from needing to be executed at the same time, these operations implement tasks that are indeed quite different.

=====Procedural Cohesion=====
Procedural cohesion describes a module whose operations are typically grouped because they are executed within a sequence. Unlike sequential cohesion (discussed below) however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

public class GradeBookSystem {
public void Login(int teacherId) {
// implementation
}

public ArrayList GetStudents(int teacherId) {
// implementation
}

public void UpdateGrades(ArrayList grades) {
// implementation
}

public void UpdateAttendance(ArrayList dates) {
// implementation
}

public void Logout(int teacherId) {
// implementation
}
}

In this example, the <code>GradeBookSystem</code> exposes different tasks that allow the teacher to login, track student grades/attendance and logout. These operations are grouped in a procedurally cohesive manner to facilitate the higher level level task of upgrading the teacher's grade book.

=====Communicational Cohesion=====
Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

public class CustomerInformation {
public CustomerInformation(int accountNum) {
// implementation
}

public String getName() {
// implementation
}

public float getBalance() {
// implementation
}

// ...
}

In this example, the <code>getName</code> and <code>getBalance</code> operations facilitate tasks against the common input <code>accountNum</code>.

===== Information cohesion =====
Information cohesion can do several things with the same data - a class with various methods using same data. The following example illustrates information cohesion.

class RectangleTransformer {

Rectangle rectangle;

public RectangleTransformer(Rectangle rectangle) {
this.recentangle = rectangle;
}

public double getArea() {
// implementation
}

public double getPermiter() {
// implementation
}

public void flip() {
// implementation
}

public void stretch(double width, double height) {
// implementation
}
}

=====Sequential Cohesion=====
Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

class Cube {
public ArrayList getInfo(){
ArrayList tempList = new ArrayList();
tempList.add(getArea());
tempList.add(getVolume());
return tempList;
}
public double getArea(){return 6*side*side;}
public double getVolume(){return side*side*side;}
}

=====Functional Cohesion=====
Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

public class Stack {
public Stack() {
// implementation
}

public void push(Object obj) {
// implementation
}

public Object pop() {
// implementation
}

public Object peek() {
// implementation
}

public int isEmpty() {
// implementation
}
}

===Advantages and Disadvantages===
Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

==Coupling==
[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Coupling] refers to the degree of connectedness between two modules. Modules that have many connections between one another are said to be have high coupled or be tightly coupled. Alternatively, modules that have very little connection between one another are said to have low coupling or be loosely coupled. Introducing more coupling between modules, increases the interdependencies between modules. As a result, attempting to reuse one module requires the “import” of all of its associated or coupled modules [http://www.site.uottawa.ca:4321/oose/coupling.html]. In addition, high coupling may introduce issues with code reuse, maintenance, testing, and general understanding of relationships between modules [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29]. For these reasons, it is important to maintain loose coupling between classes. The following examples illustrate the different types of coupling and are arranged from tightest (least desirable) to loosest (most desirable).

=====Content coupling=====
Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

public class Rectangle {

public int Top = 0;
public int Left = 0;
public int Width = 0;
public int Height = 0;

public Rectangle(int top, int left, int width, int height) {
this.Top = top;
this.Left = left;
this.Width = width;
this.Height = Height;
}

public int getArea() {
return this.Width * this.Height;
}
}

public class FloorPlan {
Rectangle rectangle = null;

public FloorPlan(int width, int height) {
rectangle = new Rectangle(0, 0, 50, 100);
}

public void modifyDimensions(int width, int height) {
rectangle.Width = width;
rectangle.Height = height;
}

public int getArea() {
return rectangle.getArea();
}
}

In this example, <code>FloorPlan</code> is able to directly modify the <code>Width</code> and <code>Height</code> fields of the <code>Rectangle</code> object. This coupling creates a dependency from <code>FloorPlan</code> on the internals of the <code>Rectangle</code> object that inhibits maintenance of the <code>Rectangle</code> class. If someone wanted to go back and change the <code>Width</code> and <code>Height</code> fields of <code>Rectangle</code> class to use a different data type they would also have to update the <code>FloorPlan</code> class.

=====Common coupling=====
Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

#include <stdio.h>
#include <string.h>

#define NUM_FIELDS 3

class EmployeeRecordParser {
public:
EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {

m_aryFields = new char*[m_nCount];

char* strField = strtok(strRow, ",");

for (int ct = 0; ct < m_nCount && strField; ++ct) {

m_aryFields[ct] = new char[strlen(strField) + 1];

memcpy(m_aryFields[ct], strField, strlen(strField));

m_aryFields[ct][strlen(strField)] = 0;

strField = strtok(NULL, ",");
}
}

~EmployeeRecordParser() {
if (m_aryFields)
delete [] m_aryFields;
}

int GetCount() { return m_nCount; }
char* operator[](int nIndex) { return GetField(nIndex); }
char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }

private:
char** m_aryFields;
int m_nCount;
};

void ParseRecords(char* strFile) {
int nRecords = 0;
char* strRow = strtok(strFile, "\n");

while (strRow) {

EmployeeRecordParser record(strRow, NUM_FIELDS);

printf("\nEmployee Record %d\n------------------------\n", ++nRecords);

for (int i = 0; i < record.GetCount(); ++i) {
printf("Field %d: %s\n", i, record[i]);
}

strRow = strtok(NULL, "\n");
}
}

int main() {
char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";

ParseRecords(str);

return 0;
}

In the C++ example above, both the <code>ParseRecords</code> method and the <code>EmployeeRecordParser</code> class make use of the globally accessible [http://www.cplusplus.com/reference/clibrary/cstring/strtok.html strtok] function. Internally, <code>strtok</code> uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

=====Control coupling=====
Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

enum InfoType { id, name, balance }

public class CustomerInfo() {
public Object getCustomerInfo(InfoType type) {
Object returnVal = null;
switch (infoType) {
case InfoType.id:
returnVal = getCustomerId();
break;

case InfoType.name:
returnVal = getCustomerName();
break;

case InfoType.balance:
returnVal = getCustomerBalance();
break;
}

return returnVal;
}

// ...
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
int id = (int)customerInfo.getCustomerInfo(InfoType.id);
// ...
}
}

=====Stamp coupling=====
Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

public class Customer {
private int id = 0;
private String name = "";
private float balance = 0.0f;

public int getId() { return id; }

public void setId(int _id) { id = _id; }

public String getName() { return name; }

public void setName(String _name) { name = _name; }

public float getBalance() { return balance; }

public void setBalance(float _balance) { balance = _balance; }
}

public class CustomerInfo() {
public void save(Customer customer) {
int id = customer.getId();
String name = gustomer.getName();
// ...
}
}

public class Client {
private customerInfo = new CustomerInfo();

public void execute() {
Customer customer = new Customer();

customer.setId(5);
customer.setName("Example");
customer.setBalance(100f);

customerInfo.save(customer);
}
}

=====Data coupling=====
Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

public class CustomerInfo
{
public float getCustomerBalance(int customerId)
{
// implementation details
}
}

public class Client
{
private customerInfo = new CustomerInfo();

public void execute(int customerId)
{
float balance = customerInfo.getCustomerBalance(customerId);

// ...
}
}

=====Message coupling=====
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

class superclass {
public void processData(){ module1.processData(); }
}

public Module2 {
public void doSomething() { superclass.processData(); }
}

=====No coupling=====
Modules do not communicate at all with one another.

===Advantages and disadvantages===
Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

==Related Concepts==
When researching cohesion and coupling there are some related concepts that repeatedly appear. Below we discuss some related concepts to cohesion and coupling.

====Measuring Cohesion====
The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

'''Lack of Cohesion 1 (LCOM1)'''
LCOM1 = (P > Q) ? (P – Q) : 0

P = Total number of method pairs that do not use a common field of the class.
Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

'''Lack of Cohesion 2 (LCOM2)'''
LCOM2 = 1 – sum(mA)/(m*a)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

'''Lack of Cohesion 3 (LCOM3)'''

LCOM3 = (m – sum(mA)/a) / (m – 1)

m = Total number of methods in the class.
a = Total number of attributes in the class.
mA = Total number of methods that access attribute a.
sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

====Measuring Coupling====
While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

'''Coupling Between Objects (CBO)'''

CBO = sum(t)

t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

'''Data Abstraction Coupling (DAC)'''

DAC = sum(a)

a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

'''Method Invocation Coupling (MIC)'''

MIC = nMIC / (N – 1)

N = Total number of classes defined within the project.
nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

====Demeter's Law====
[http://en.wikipedia.org/wiki/Law_of_Demeter Demeter's Law] is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [http://javaboutique.internet.com/tutorials/coupcoh/index-2.html] illustrates how this could be done.

public float calculateTotal(Order order) {
return order.getProducts().getTotalCost();
}

In the example object the object which implements <code>calculateTotal()</code> is calling <code>getTotalCost</code> on a <code>Products</code> object which is exposed through <code>order</code>. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

public float calculateTotal(Order order) {
return order.getTotalCost()
}

public class Order {
// ...

public float getTotalCost() {
return products.getTotalCost();
}

// ...
}

==Conclusion==
Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself while on the other hand coupling is introduced by how dependent the module is on other modules. Good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the same time use as less data/objects from other modules as possible to have low coupling. Although low coupling is desirable, that doesn't mean high coupling doesn't have its uses. In some modules the programmer might want it to be tightly coupled for performance reasons - perhaps a series of modules dependent on each other to bring out the maximum output. A non-IT way of seeing this might be our human body - it is tightly coupled and parts/modules are all dependent on one and another - "removing or fixing" one will involve many other; Even though high coupling is bad but the human body functions much better tightly coupled than loosely coupled. So basically even though high cohesion and lose coupling is very desirable, the programmer has to view the design of the system to figure out what the best approach is.

== See also ==
*[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Wikipedia: Cohesion]
*[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Wikipedia: Coupling]
*[http://www.cs.kent.edu/~jmaletic/cs63901/downloads/CouplingCohesion.pdf Software Engineeriing Presentation: Coupling and Cohesion]
*[http://www.frontendart.com/monitor/help/node23.html More Cohesion Metrics]
*[http://www.frontendart.com/monitor/help/node22.html More Coupling Metrics]
*[http://javaboutique.internet.com/tutorials/coupcoh/index-2.html Example: Measuring Coupling and Cohesion]

== References ==
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
#http://www.waysys.com/ws_content_bl_pgssd_ch06.html
#http://www.site.uottawa.ca:4321/oose/index.html#cohesion
#http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
#http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
#http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
#http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
#http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
#http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
#http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
#http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion