If members of a class do not
depend on each other, the class is said to have no cohesion (no togetherness)
The goal is to design software
with low coupling (not none) and high cohesion.
The reason is that with low
coupling, changes and errors in one location will not propagate to the rest of
the code,
with high cohesion, code that
depends on each other is kept close to each other.
Mechanisms to promote low coupling:
• private fields – renaming a
field will not affect anything outside the class.
• non-public classes that can
only be seen inside a package.
• private methods that cannot be
called from outside the class.
Mechanisms that allow high cohesion
• all members are visible from inside
a class.
• default visibility is package
Coupling:
. . . the degree of
interdependence between modules
. . . a measure of the strength of interconnection
• The more the connections between one
module and the rest,
the harder to
understand that module,
so the harder to
re-use that module in another situation,
so the harder it is to
isolate failures caused by faults in the module
• The lower the coupling the “better”.
• Loose coupling is a design goal that seeks to reduce the inter-dependencies; between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component.
Loose coupling is a much more
generic concept intended to increase the flexibility of a system, make it more
maintainable, and makes the entire framework more "stable".
Tight-Coupling:-
1.
While creating complex
application in java, the logic of one class will call the logic of another
class to provide same service to the clients.
2.
If one class calling
another class logic then it is called collaboration.
3.
When one class is
collaborating with another class then there exists tight-coupling between the
two classes.
4.
If one class wants to
call the logic of a second class then they first class need an object of second
class it means the first class create an object of second class.
5.
For example, if we have
two classes called traveller and car, traveller class is calling logic of car
class; in this case traveller class creates an object of car class.
6.
In the above traveller
class and car classes, car class object of dependency for traveller object.
Example:-
Public class Traveller
{
Car c = new Car ();
Public void startJourney()
{
c.move();
}
}
Public class Car
{
Public void move()
{
}
}
·
In the above example
traveller object is tightly coupled with car object because in place car object
if you want to use bike object then, we need to make changes in Traveller class
Example :-
Public class Traveller
{
Bike b = new Bike ();
Public void startJourney()
{
b.move();
}
}
Public class Bike
{
Public void move()
{
}
}
Loose-Coupling:-
1.
In Loose-Coupling, when
one object is depending on another class object, some external entity will
provide that dependency object to the main object that external object we call
as a Container.
2.
In order to get
loose-coupling between objects the following two rules are required
3.
The classes should
follow POJI/POJO model.
4.
Apply dependency
injection mechanism.
For example:-
Vehicle(interface)-----------POJI
|
-------------------------
| |
Car(Class) Bike(Class)-------POJO
Public class Traveller
{
Vehicle v;
Public void setV(Vehicle v)
{
this.V=V;
}
Public void startJourney
{
V.move();
}
}
·
In the above traveler
class, an external entity injects either car (or) Bike object.
·
In traveler, these are
no changes required we are shifting the dependency from car to a Bike.
·
In the above traveler
class, we are token vehicle reference, so that an external object (Container)
can injects either car object (or) Bike object, depends on requirement if a
traveler.
·
In spring frame work,
spring container follows dependency injection mechanism and injects the
dependency objects required for a main object.
·
Spring frame work is
much success because of one of the main reason is it promotes Loose-Coupling
between the objects.
Cohesion:
. . . the extent to which its
individual components are needed to perform the same task
. . . how tightly bound or
related [a module’s] internal elements are to one another
• The less tightly bound the internal
elements,
the more disparate the parts
to the module, the harder it is to understand
• The higher the cohesion the “better”.
• High cohesion is when you have a class that does a well defined job. Low cohesion is when a class does a lot of jobs that don't have much in common.
Let's take this example:
You have a class that adds two
numbers, but the same class creates a window displaying the result. This is a
low cohesive class because the window and the adding operation don't have much
in common. The window is the visual part of the program and the adding function
is the logic behind it.
To create a high cohesive solution, you would have to create a
class Window and a class Sum. The window will call Sum's method to get the
result and display it. This way you will develop separately the logic and the
GUI of your application.
Coupling and related concepts
Encapsulation — putting in a container, packaging up, or
putting a
barrier around a group of
entities. “creating a module”. Often, the
programming language mechanism
that provides encapsulation also
provides a means to enforce
hiding.
• By itself, not directly related to
coupling (although is related to modules)
Information Hiding — implementation decisions, or
decisions that are
likely to change.
• If information hiding is enforced,
then certain kinds of relationships between modules are not possible, and so
limits the amount of coupling possible
Classic coupling measurement
• “physical” concept
• ordinal categories of relationship
between two modules
Content coupling modules can directly refer to the contents of
each other “bad”
Common coupling modules communicate via global data
Control coupling modules communicate by data that allows one
module to directly affect the behaviour of the other
Stamp coupling modules communicate by a
heterogeneous set of items,
not all of which are used
Data coupling modules communicate by parameters, where each
parameter is a single item or a
homogeneous set that incorporate no
control element “good”
No coupling there is no relationship
Cohesion and related concepts
Encapsulation — putting in a container, packaging up, or
putting a barrier around a group of entities. “creating a module”.
• By itself, not directly related to
cohesion (although is related to modules)
Abstraction — extracting the essential
details about a concept
• A good abstraction should have good
cohesion
Information Hiding — implementation decisions, or decisions that
are likely to change.
• Modules with good cohesion do not make
visible “non-essential” details
No comments:
Post a Comment