Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would suggest two concepts, interfaces and dependency injection, as a way to decouple your classes. Interfaces give you a way to define a contract or set of expected behaviors that is independent of any implementation. When you have a class depend on an interface rather than on a class, you get the freedom to substitute other classes that implement the interface without having to rewrite the class that is depending on it.</p> <p>When you use interfaces with dependency injection, i.e., give the class the actual implementation that it is to work on rather than have it create a particular implementation on its own, you achieve even more decoupling in your application. Now the class only knows about the interface and doesn't even know how to create it, just use it. Dependency injection is often used with creational patterns such as Builder or Factory, where you localize the construction of objects in a single class so that only that class need change when you extend the application with additional classes.</p> <p>Also, remember that coupling (and its twin, cohesion) is a relative measure. You can't eliminate all coupling or your objects wouldn't be able to interact. Having some level of dependence is necessary. You need to balance it with ease of use and implementation as well.</p> <p>As for your particular example, it's hard to tell without actual code. I suspect that you are over-engineering the solution and violating the DRY principle (don't repeat yourself). You may need to look at ways to use interfaces and perhaps a lightweight wrapper to decouple your classes from the framework component rather than a complete reimplementation.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload