I am supposed to write two versions of the same code. One with low coupling and high cohesion and another still with low coupling but this time with low cohesion. I don't really understand what the difference is? How can I have low coupling and low cohesion? They seem so related that this is impossible to do.
Can someone explain this? Perhaps with an example? Thanks!
In short:
Cohesion in software engineering, as in real life, is how much the elements consisting a whole(in our case let's say a class) can be said that they actually belong together. Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.
One way of looking at cohesion in terms of OO is if the methods in the class are using any of the private attributes.
Now the discussion is bigger than this but High Cohesion (or the cohesion's best type - the functional cohesion) is when parts of a module are grouped because they all contribute to a single well-defined task of the module.
Coupling in simple words, is how much one component (again, imagine a class, although not necessarily) knows about the inner workings or inner elements of another one, i.e. how much knowledge it has of the other component.
Loose coupling is a method of interconnecting the components in a system or network so that those components, depend on each other to the least extent practically possible…
In long:
I wrote a blog post about this. It discusses all this in much detail, with examples etc. It also explains the benefits of why you should follow these principles. I think it could help...
Coupling and cohesion are two different measures of software modules.
Coupling is a description of how two classes interact. If two classes are interdependent on each other, they exhibit tight coupling; if two classes can be used independently of one another, they exhibit loose coupling. Loose coupling is preferred, as it lends itself to reusable components and high maintainability.
Cohesion is a description of how the components of a single class belong together. A class containing methods that have nothing to do with each other exhibits low cohesion; a class containing methods that are logically similar exhibits high cohesion. High cohesion leads to focused classes that serve a well-defined purpose.
The relationship between coupling and cohesion is symbiotic. If two classes are tightly coupled, then there's a high probability that they don't have clear responsibilities and therefore will exhibit low cohesion. Conversely, if a class is highly cohesive, its purpose is well-defined and it is easier to use with other classes in a way that avoids coupling to them.
For your particular assignment, start by writing "good" code - low coupling and high cohesion. To morph that into something with low coupling and low cohesion, keep the classes independent of one another but shuffle the functionality around. Create a Utility class with a whole bunch of unrelated methods. Put all of the methods that start with a vowel into another class. Do something that prevents any class from having a well-defined purpose.
As long as you keep the classes from depending on each other, you're creating code that exhibits low coupling but also has low cohesion.
Cohesion and coupling are properties of how you organize your items.
Let's take a physical example. Now suppose you had a baseball, tennis ball, cricket ball, croquet ball, lacrosse ball, and a billiard ball. Suppose you also had a baseball bat, tennis racquet, cricket bat, croquet mallet, lacrosse stick, and a pool cue. If you were to randomly sort these twelve objects into six bagged pairs of objects, you would probably have an organization with low coupling and low cohesion. To be concrete, let's say the six bags contained:
This organization has low cohesion because the objects in each bag are unrelated. This organization has moderate coupling because the density of relationships between the content of different bags is medium (but spaghetti-like) -- six links (one for each sport ball-bat pair) of a possible 21. If you wanted an example of even lower coupling you could start with a higher number of pairs of sports objects
The obvious organization of the objects into bags of
has even lower coupling (zero coupling) because none of the bag contents are related to the content of other bags. It has high cohesion because the contents within a bag are related to each other.
Coupling and Cohesion are somehow two close concepts but are not the same. Your design should have:
Low Coupling: It means your classes should not be dependent on other classes (esp. concrete classes) too much. You must decouple them as much as possible. Decoupling helps reusability ( the goal of OO software engineering). Because when you reuse such classes, you don't need to bring any other class with your class to make it work. Many design patterns such as Facade fulfill this goal.
High Cohesion: It means your class should not include many unrelated tasks. When you increase cohesion, code comprehension becomes easier since the class is doing some coherent tasks. This also increases reusability. Some design patterns such as Visitor have this goal.
In continue, I give 3 class example that may make more sense :
#include <Document>
#include <Printer>
#include <SpellCheker>
class HighCoupling{
// This class need other class to be usable
Document *doc;
Printer *activePrinter;
CretaeDocument() { /*...*/ }
SaveDocument() { /*...*/ }
PrintDocument() { /*...*/ }
CheckSpell() { /*...*/ }
};
#include <Document>
class LowCouplingHighCohesion {
// This class don't need other classes
// This class is a specialist on some task
CretaeDocument() { /*...*/ }
SaveDocument(Format *) { /*...*/ }
LoadDocument() { /*...*/ }
};
#include <Document>
class LowCouplingLowCohesion {
// This class don't need other classes
// This class do many unrelated things
CretaeDocument() { /*...*/ }
SaveDocument() { /*...*/ }
OpenDocument() { /*...*/ }
Undo() { /*...*/ }
ChangeDocumentBackground() { /*...*/ }
SearchInDocument() { /*...*/ }
};
Say for example that you have two classes which will only work if both classes are there. The similarity of functionality within a class is called cohesion, how things belong together, but how they interact is called coupling.
So if you write a program that has low coupling and high cohesion it means that the classes of the program are easy to use and reuse and that the internals of the class belong together. So the classes are filled with methods that show similarity.
In this manner it is rather easy to change a part of a program without having to change your entire code on multiple places. So coupling in general is the term that describes how easy or hard it is to implement and cohesion is used to measure the similarity between methods in a class. So if you want to build something with low coupling and low cohesion, you would have to build something that is easy to implement into a program, but messes up the encapsulation.
The difference is in the meaning.
Coupling is referred to something that has a negative meaning. So, according to SOLID rules you have to try to build your application in such way, that it is Loosely Coupled. For example, Gof patterns (e.g., Abstract Factory) and DI containers (such as MS Unity or NInject in .NET world) can help you to achieve this. Loosely Coupled code means that if you need to insert new class into your application (or, let's say in this way - if you need to change one class to another), then you can do it easily without big efforts.
Cohesion is referred to something that has a positive meaning. So, as you probably guessed, you have to try to build your application in such way, that it will implement High Cohesion. What does it mean? It is referred to interaction between different modules of your application. For example, let's assume that your app has two modules:
If the Import module can successfully import almost everything that is exported by the Export module, then it means that you set up a good interaction between them and a cohesion between them is high.
