Let’s take an example and see how over-emphasizing de-coupling can lead to a poor design. Design is About Balancing Cohesion and Coupling (not blindly following principles) To “always decouple” is not going to find that balance. You can’t have it both ways-there is a balance to be struck, and advice In fact, coupling is almost always mentioned with cohesion, because there is a tension there. Tightly coupled bits of code that are cohesive can be much simpler to understand than de-coupled code. De-coupled systems can be hard to understand, even if their individual parts are simpler. These are all fair points, however there is a tradeoff with taking this to the extremes that the principle would A particular module might be harder to reuse and/or test because dependent modules must be included.Assembly of modules might require more effort and/or time due to the increased inter-module dependency.A change in one module usually forces a ripple effect of changes in other modules.Wikipedia outlines the disadvantages with tightly-coupled code: It’s usually accepted that tightly coupled code-code that has lots of interdependencies-is worse than looselyĬoupled code. …the degree of interdependence between software modules a measure of how closely connected two routines or modules are… Perhaps, perhaps, perhaps…it’s actually about coupling This gets at cohesion, which we talked about, but it also starts to That said, the Wikipedia details present a different problem and solution, namely that your classes should not So for people working in a dynamic language like JS or Ruby, this principle is wholly pointless as stated. You pass into a routine responds to the methods that routine calls, the code “works” 1. Ruby doesn’t define types and so as long as the object This seems quite reasonable, however the principle as stated says that “ no client should be forced to depend on methods it does not use” (emphasis mine).įirst, let’s just state that a dynamic language like Ruby automatically complies with this principle because theĭefinition of what a client depends on is what it uses. splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them…ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy. Very careful about over-optimizing for one or the other. Problem of coupling, and the reality is, we should just be talking directly about coupling and cohesion and be Now, I want to talk about the Interface Segregation Principle, which prescribes are very strange solution to the In the third post, I talk about how the Liskov Substitution Principle is too narrowly focused on the wrong problem, and doesn’t really give usable design guidance. Principle, and in the second, I recommended ignoring the Open/Closed Principle, since it isĬonfusing and most reasonable interpretations give bad advice. In that post, I outlined the problems I see with the Single Responsibility Interface Segregation Principle is Unhelpful but Inoffensive (SOLID is not solid)Īs mentioned in the original post, I’m realizing that the SOLID principles are not as…solidĪs it would seem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |