"Object-oriented programming has two main objectives: to build highly cohesive classes and to maintain loose coupling between those classes. High-cohesion means well-structured classes and loose coupling means more flexible, extensible software."
"Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. Though lack of cohesion may never have an impact on the overall functionality of a particular class or of the application itself the application software will eventually become unmanageable as more and more behaviours become scattered and end up in wrong places."
"Whenever one object interacts with another object, that is a coupling. In reality, what you need to try to minimise is coupling factors. Strong coupling means that one object is strongly coupled with the implementation details of another object. Strong coupling is discouraged because it results in less flexible, less scalable application software. However, coupling can be used so that it enables objects to talk to each other while also preserving the scalability and flexibility."
"In OO programming, coupling is unavoidable. Therefore, the goal is to reduce unnecessary dependencies and make necessary dependencies coherent."
Example :
Coupling is the unnecessary dependance of one component upon another
component's implementation. An example would be if you had a Dog class
that should be able to bark and jump. You could write it like this:
class Dog
{
void doAction(int number)
{
if(number==1)
//Jump code goes here
if(number==2)
//Bark code goes here
}
}
However, this way whoever used your class would have to follow your
convention that doAction(1) means jump and doAction(2) means bark. A
less-coupled way would be to write separate bark() and jump() methods.
Cohesion occurs when components are wired together in a smart, logical
way. If you have ever used a Controller class, that's a great example
of acheiving cohesion. Highly cohesive components interact with each
other semantically, in other words, they tell each other what they want
to do. In a bank example, an ATM object should be able to tell an
Account object to getBalance(), or withdrawFunds(), etc. These are
sensible ways for the ATM and Account to interact, not specific ways
that are only useful in one program.
So good OOD requires that components can interact powerfully, but
independently of eachother's implementation details. (Think of
System.out.println() - most people have no idea how that works, but
when you want to output some text, you can just use the method.)
Encapsulation is the use of hiding implementation details within your
code. Changing the above Dog code from doAction() to jump() and bark()
would be a step toward good encapsulation. This is getting
frighteningly nerdy, but I think you could say "A program with high
cohesion and low coupling exhibits good encapsulation". In other words,
encapsulation is the goal you're trying to reach when you reduce
coupling. A class with good encapsulation, in turn, lends it self to
being a cohesive part of a system.
Ref:
http://www.velocityreviews.com
No comments:
Post a Comment