A class should have only one reason to
change.
This
principle states that if we have 2 reasons to change for a class, we have to
split the functionality in two classes. Each class will handle only one
responsibility and if in the future we need to make one change we are going to
make it in the class which handles it.
If
there are two different reasons to change, it is
conceivable that two different teams may work on the same code for two
different reasons. Each will have to deploy its solution, which in the
case of a compiled language (like C++, C# or Java), may lead to incompatible
modules with other teams or other parts of the application.
This
principle is closely related to the concepts of coupling and cohesion. Coupling
refers to how inextricably linked different aspects of an application are,
while cohesion refers to how closely related the contents of a particular class
or package may be. All of the contents
of a single class are tightly coupled together, since the class itself is a
single unit that must either be entirely used or not at all.
No comments:
Post a Comment