Coupling And Cohesion

Given two lines of code, A and B, they are coupled when B must change behavior only because A changed.
They are cohesive when a change to A allows B to change so that both add new value.The difference between CouplingAndCohesion is a distinction on a process of change, not a static analysis of code's quality. But there are plenty of indicators and BestPractices...These are some of the better-defined qualities that separate good software from bad software. Although they were formalized during the invention of StructuredProgramming, they apply exactly as well toObjectOrientedProgramming as to any other kind.Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.

• Someone had vague reference to decomposability here. Clarification?
• How about: 'Cohesion is inversely proportional to the number of responsibilities a module/component has.'

Coupling between modules/components is their degree of mutual interdependence; lower coupling is better.

• size: number of connections between routines
• intimacy: the directness of the connection between routines
• visibility: the prominence of the connection between routines
• flexibility: the ease of changing the connections between routines

A first-order principle of software architecture is to increase cohesion and reduce coupling.Cohesion (interdependency within module) strength/level names : (from worse to better, high cohesion is good)

• Coincidental Cohesion : (Worst) Module elements are unrelated
• Logical Cohesion : Elements perform similar activities as selected from outside module, i.e. by a flag that selects operation to perform (see also CommandObject).
  • i.e. body of function is one huge if-else/switch on operation flag
• Temporal Cohesion : operations related only by general time performed (i.e. initialization() or FatalErrorShutdown?())
• Procedural Cohesion : Elements involved in different but sequential activities, each on different data (usually could be trivially split into multiple modules along linear sequence boundaries)
• Communicational Cohesion : unrelated operations except need same data or input
• Sequential Cohesion : operations on same data in significant order; output from one function is input to next (pipeline)
• Informational Cohesion: a module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure. Essentially an implementation of an abstract data type.
  • i.e. define structure of sales_region_table and its operators: init_table(), update_table(), print_table()
• Functional Cohesion : all elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation
  • get_engine_temperature(), add_sales_tax()

Coupling (interdependence between modules) level names: (from worse to better, high coupling is bad)

• Content/Pathological Coupling : (worst) When a module uses/alters data in another
• Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag)
• Common/Global-data Coupling : 2 modules communicating via global data
• Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs.
• Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs.
• No data coupling : independent modules.

As usual with software source code metrics, these qualities are difficult (but not necessarily impossible) to reduce to quantitative data that can be meaningfully compared across different projects or organizations, despite their value as qualitative measures.These measures of quality arose in the context of structured procedural programming, but also apply to other paradigms, including OO; the best OO practices can be seen in these same principles. This should not be surprising; OO did not evolve in a vacuum.

What is cohesion and coupling in java?

A high cohesion and low coupling is always desired.
Cohesion is closely related the various functions of a class.
Coupling is how closely this class is integrated with implementations of other classes, that a change in any other class will result in change in this class.
Hence its always better to program to interface.

Cohesion means that the whole of a class sticks together (well, roughly). A class should be responsible for itself, should do one thing and as far as possible do everything for that one thing. For example: A Car class should remember its make, colour, speed. It is responsible for changing speed; the speedUp() and slowDown() methods should be in the Car class; no other class should make your Car go faster or slower.

Cohesion is (to quote sellers and Yeatman) A Good Thing.

Coupling means that one class gets at the implementation of another class.
For example:
Driver campbell = new Driver();
Car ford = new Car("Ford", "red");
. . .
public class Driver
{
Car myCar;
. . .
public void goFaster(int speed)
{
myCar.speed += speed;
}
. . .
}

The Car class has allowed access to its speed field and the Driver class changes its value directly. This means other classes gain access to the implementation of the Car class; any changes to that implementation will "break" the Driver class. This is "tight coupling" and tight coupling is A Bad Thing, because any changes to one class can mean that other classes would have to be altered too.
To avoid tight coupling

* All classes should have as small a public interface as possible.
* All non-constant fields should have private access.
* Any alterations to the values of fields should be via method calls.

Ant The Build Tool

A defined process is one of the most necessary but often least-used tools in software development. It is by nature an overhead task that accompanies a development effort. A defined build process ensures that the software in your development project is built in the exact same manner each time a build is executed. As the build process becomes more complex -- for example, with EJB builds or additional tasks -- it becomes more necessary to achieve such standardization. You should establish, document, and automate the exact series of steps as much as possible. Why do I need a defined build process? A defined build process is an essential part of any development cycle because it helps close the gap between the development, integration, test, and production environments. A build process alone will speed the migration of software from one environment to another. It also removes many issues related to compilation, classpath, or properties that cost many projects time and money If you are developing Java-based Web applications and you're still manually building and dragging and dropping files from one place to another, now is a good time to consider automating. Ant is an open source Java-based build tool that is available from the Apache Jakarta Project Web site. Ant differs from other build tools in several ways. Since Ant is not OS dependent, you can develop one standard build file for your projects and then re-use this code for any similar projects, regardless of the platform. Because the tool is not married to any one platform, you can capitalize on the "write once, run anywhere" philosophy. Ant is free and open source build tool, written in Java, helps in automating the entire build process of a Java development project. Ant uses XML build files. By default, Ant looks for a build file named build.xml. The build file contains information about how to build a particular project. Each project contains multiple targets like creating directory, compiling source codes. Target can depend on other targets. Targets contain tasks. Behind each task is a Java class that performs the described work.