27
What is the meaning of the terms high/low coupling in object-oriented systems development or object-oriented programming (POO)?
27
What is the meaning of the terms high/low coupling in object-oriented systems development or object-oriented programming (POO)?
29
Concept
Good Practices (Design Principle)
*¹ But this is only about Good Practices (design principle), it does not mean that you can not use high degree coupling in your project, because it is inevitable in some cases. Care should only be taken to maintain your design with the least degree of coupling possible.
Examples
Considerations
Coupling is necessary, between different modules, what the standards preach is that it is as small as possible, always assessing whether it is necessary to create a certain dependency or whether it can be replaced by a smaller dependency.
Obs.: The concept of coupling is independent of programming language or technology used in your project. It is a matter of good practice.
16
Coupling is how much one class knows of another class.
The ideal is that there is low coupling between classes because classes should be specialists for the service they have been designated.
Low coupling is also desired because it is easier to identify problems related to class, which is one of the principles of the object orientation paradigm.
EDIT
"Knowing of another class" means that the class in question uses methods and/or attributes of some other class. This makes the class dependent on the other class, that is, the class behavior will be directly linked to the behavior of the other.
The high coupling between classes makes it difficult to maintain them, because imagine, every time you edit a class you will also be changing the behavior of the classes that are coupled with it, if you are not aware of the coupled classes you will be running a great risk of being entering bugs and unexpected behaviors to your program.
11
They talked so much about the definition, I’ll talk a little bit about Weak coupling:
Introducing
Weak coupling is one of the main requirements for building quality object-oriented (OO) software. The weak coupling measures how much a class depends on, or is related to, another class or subsystem. The ability of one class to inherit the behavior of another(s) is one of the main features of the OO paradigm. The main advantage is to be able to create new classes almost for free, taking advantage of the code of another. This article discusses these two concepts and shows why inheritance, in general, helps compromise weak coupling.
Weak coupling
A class with strong coupling relies heavily (usually without need) on others. This can lead to the following problems [Larman]:
classes that are difficult to take advantage of, since whenever this class is used all the others on which it depends must be present;
changes in related classes may force local changes and
are difficult to understand in isolation.
Common forms of coupling occur through: instance variables, local variables to methods or their arguments, called services in another class, one class derives directly or indirectly from another or one class implements a particular interface. In short, whenever a class references another type in any of the above circumstances coupling is occurring. Consider the code:
public class X
{
private ClasseConcretaY var1;
void M1(ClasseConcretaW var2 ) { … }
}
There are two main coupling points, in the instance variable var1, which is of the Classeconcretay type, and in the argument var2, which is of the Classeconcretaw type. In these two parts of the code the class X references two other concrete classes. This means that whenever this class is used, the other two must be available in the program namespace. In the case of Java, the(s) package(s) where they are located should(or) be in the classpath.
But, does referencing other classes always cause coupling problems? The answer is, it depends! Referencing stable and widespread classes is rarely a problem. For example, using the java.util package in a Java program will hardly cause future docking problems, since any Java runtime environment contains this library. The problem is in unstable classes, little known, ie in the classes that are created to meet the specific problems of projects.
How to decrease coupling?
A general rule of thumb for reducing coupling is "programming to an interface and not to an implementation" [Gamma]. In the above example this means replacing the statements of the concrete classes with statements of interfaces. Doing this decouples the code from a specific implementation, making it dependent only on an interface. This is not the definitive solution, a good project with good responsibilities is crucial, but it helps a lot. It is easier to understand alone a class that references only interfaces and more [Gamma]:
customers (class users) remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that customers expect, clients remain unaware of the classes that implement these objects; they only have knowledge of the abstract classes that define the interface.
Source: http://www.devmedia.com.br/acoplamento-fraco-x-heranca/3714
Browser other questions tagged oop software-architecture pattern-design modeling
You are not signed in. Login or sign up in order to post.
@Piovezan, your editing and description of it was so good that it should turn into comment to make it clear to everyone.
– Maniero
Yes @bigown! I also read the comment of the edition and saw that this error persisted in the answer for more than a year, nor had knowledge of this term "Design Principle", but it is correct that this cannot be a Design Pattern, because it is something more abstract that cannot be made as a cake. So I think the term "Design Principle" is much more appropriate. Thank you for the @Piovezan edition.
– Fernando Leal
Guys, thanks for the feedback. I do not know if in all editions compensates this level of detail, I put more because it is a potentially thorny subject (the definition of Pattern design) and which could result in discussions if it were not duly justified.
– Piovezan