3 ms·

I agree; it seems that SOLID does a good job of marshalling the complexity out of individual elements into the system as a whole. This can be a good thing, if t

I agree; it seems that SOLID does a good job of marshalling the complexity out of individual elements into the system as a whole. This can be a good thing, if the system design itself was created with SOLID in mind, and is well implemented. However if the system design didn't account for this complexity shift, it will likely cause a lot of mayhem.

gdy 7y ago
"if the system design itself was created with SOLID in mind" Could you possibly elaborate what you mean by that?
- craftinator 7y ago
  Yes! In part I kept that ambiguous, because I've observed many edge cases and was trying to capture the overarching theme. The core idea is that often a project is designed without respect to the "design guidelines" that developers are asked to adhere to during implementation. I see SOLID as a set of design AND implementation guidelines; it contains rules for both the global and local systems. I've observed that often, the design of a system framework ignores the design portion, but requires the implementation portion (I've done it myself, and wondered why my project turned into a hot mess even though I followed all the rules!). With SOLID, complexity is pushed out of individual components and into the global scope. Instead of having a component manage multiple responsibilities, it must have only a single responsibility; now you have multiple components each managing single responsibilities. Some problems that can arise from this are multiple classes that have shared or overlapping responsibilities, classes that only handle edge cases, data innaccesibility, data and code duplication... This is different than (but related to) abstraction, in that you aren't hiding implementation, instead you are dividing it. With that division comes some non-trivial overhead, which the global design of the system needs to have planned for. This is not necessarily a bad thing; it reduces the burden of designing each individual component, while increasing the burden of designing the global system to manage how the components must interact. If, in designing a system using the SOLID principles, you do not plan for how much of the complexity is being pushed towards the global scope, you can have a huge codebase that isn't cohesive enough to function as a whole. That might've been too much elaboration, but it is kind of difficult to explain a portion without being thorough.
  - mannykannot 7y ago
    I don't know that it so much that the essential complexity is being pushed into the global state - a global constraint, for example, is global regardless of how you implement the system - but factoring into tiny modules puts more layers below that level. That is not the wrong way to do things, but it has not gotten rid of the complexity. And using only small classes and methods does not guarantee the elimination of accidental complexity either; I have seen enough cases where the code has become a sort of shell game, were you go from class to class looking for where something actually gets done. As a rule of thumb, code with classes having 'helper' in their names probably has this problem, though it would usually be easy enough to rename them to conform to the single-responsibility principle.

gdy 7y ago

"if the system design itself was created with SOLID in mind" Could you possibly elaborate what you mean by that?

craftinator 7y ago
Yes! In part I kept that ambiguous, because I've observed many edge cases and was trying to capture the overarching theme. The core idea is that often a project is designed without respect to the "design guidelines" that developers are asked to adhere to during implementation. I see SOLID as a set of design AND implementation guidelines; it contains rules for both the global and local systems. I've observed that often, the design of a system framework ignores the design portion, but requires the implementation portion (I've done it myself, and wondered why my project turned into a hot mess even though I followed all the rules!). With SOLID, complexity is pushed out of individual components and into the global scope. Instead of having a component manage multiple responsibilities, it must have only a single responsibility; now you have multiple components each managing single responsibilities. Some problems that can arise from this are multiple classes that have shared or overlapping responsibilities, classes that only handle edge cases, data innaccesibility, data and code duplication... This is different than (but related to) abstraction, in that you aren't hiding implementation, instead you are dividing it. With that division comes some non-trivial overhead, which the global design of the system needs to have planned for. This is not necessarily a bad thing; it reduces the burden of designing each individual component, while increasing the burden of designing the global system to manage how the components must interact. If, in designing a system using the SOLID principles, you do not plan for how much of the complexity is being pushed towards the global scope, you can have a huge codebase that isn't cohesive enough to function as a whole. That might've been too much elaboration, but it is kind of difficult to explain a portion without being thorough.
- mannykannot 7y ago
  I don't know that it so much that the essential complexity is being pushed into the global state - a global constraint, for example, is global regardless of how you implement the system - but factoring into tiny modules puts more layers below that level. That is not the wrong way to do things, but it has not gotten rid of the complexity. And using only small classes and methods does not guarantee the elimination of accidental complexity either; I have seen enough cases where the code has become a sort of shell game, were you go from class to class looking for where something actually gets done. As a rule of thumb, code with classes having 'helper' in their names probably has this problem, though it would usually be easy enough to rename them to conform to the single-responsibility principle.