Low coupling, high cohesion, that’s what we all aim for right (or have been instructed to aim for by Software engineering books and instructors).
For argument’s sake, my definition of coupling is one component’s dependency on how another component is implemented. As a developer, low coupling is desired because without the dependency on another component you can reuse your code more easily. As a person who has to go in and debug or update an application it is easier to focus on one component’s behavior. When you view the design of your application in terms of objects acting upon one another hopefully the ability to decouple components becomes easier. Take for example if you created a game with a character whose movements were controlled by the user. If the code to move the character looked something like:
moveCharacter(int movementNumber)
{
if (movementNumber == 1)
{
// move left
}
else if(movementNumber == 2)
{
// move right
}
…
}
Then any other component in this game is forced to know the different numbers which move this character. A better implementation would be to make a moveRight() and moveLeft() methods.
Cohesion is when components interact in a way that is logical and easy to determine the flow of data. Again if you think of your application in terms of objects operating on one another, and name the methods in a way that is easy to understand then designing an application becomes that much easier. For example if you had a Bank Account object you could expect it to have methods such as getBalance(), deposit(double x), withdrawl(double x), etc.
OOD represents a more modular way to design an application.
Coder
Print This
