5 ms·

It’s generally not what it claims. Single purpose is a good idea, but the rest… The idea that one class changing won’t change others is a pipe dream. Substitu

by hajile 3y ago

It’s generally not what it claims. Single purpose is a good idea, but the rest… The idea that one class changing won’t change others is a pipe dream. Substitution only matters if you’re using inheritance, but if you’re inheriting, you likely have bigger problems as few real world problems are naturally represented by inheritance. The interface rule is redundant with the single principle idea. Maybe it should have been SOLD instead. Dependency injection is a guideline at best. If you actually do what it says, you get enterprise fizzbuzz. It should only be used occasionally and sparingly at specific boundaries otherwise the cure becomes worse than the disease. More controversially, when you avoid inheritance in favor of composition in a language like Java, you lose polymorphism while keep a leaky abstraction and really bad encapsulation while the language still retains all the mental and syntactic complexity of the inheritance bits. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

mytailorisrich 3y ago
> The idea that one class changing won’t change others is a pipe dream Reality is never black and white but that's a good principle for good software design and worth at least aiming for. If anything that has been adopted and generalised in microservices, etc. because encapsulation, modularity, design by contract all hinge of this same idea, which is powerful and useful. That's why when discussing any "principles" the important is to get the core idea behind them instead of sticking to the letter and discarding them as useless.
- hajile 3y ago
  Encapsulation is extremely important and pairs with single responsibility, but that’s completely orthogonal to OOP. Once you are solidly in the composition camp, functions are immediately superior. They tend to be naturally single purpose and have mathematical rules that make them easy to compose. Most function-heavy languages also adopted modules which provide a better, less-leaky abstraction too and that’s without getting into all the other advantages in the type system or better syntactic ergonomics from dropping all the OOP baggage.
nyrikki 3y ago
Even in Uncle Bob's version of the single responsibility principle, 'one reason to change' is about people. He words it poorly, but it is more about not commingling DBA, UX, core domain logic in a module. People miss that and end up having low cohesion. While SRP and interfaces do have an intersection, they are not the same. Interfaces leaking implementation details is an example. Composition, dependency inversion, and dependency injection are all forms of L. Polymorphism is problematic in most cases but thinking it is the only way to accomplish that looser coupling goal is a misunderstanding of where we have grown with the concepts. I tend to prefer the ports and adapters pattern, which ensures client components that invoke an operation on a server component will meet the preconditions specified as required for that operation. That is equivalent to LSP or design by contract. SOLID is just a set of principles that are intended to make loose coupling and high cohesion the ideal default. This is in contrast to procedural code that we know makes unmaintainable systems. The problem with SOLID is the same as Agile, XP etc... People ignore the core ideas that are descriptive in nature and try to use them as oversimplified prescriptivist rules. To be fair Robert Martin wasn't great at selling this and that is why I tend to point people to authors like Martin Fowler who are more careful about sounding like a preacher handing out laws. But Robert Martin developed SOLID in the context of cohesion, and if you read it in that context it is valuable. He didn't invent the SOLID tool to remember the rules, but it seems that blog posts and Wikipedia pages are as far as people get before trying to implement it or dismiss it.
- Scubabear68 3y ago
  Take a look at Uncle Bob’s code some day. You will then realize that all of his writing was synthesized solely to make him consulting money. His actual code is rubbish. This has been true all the way back to the 90’s with his inane questions to the OOP Usenet groups.
  - nyrikki 3y ago
    I already stated he isn't like his books personally. But outside of Tu quoque fallacies, van you explain why this is a bad idea. "A module should be responsible to one, and only one, actor."
ahtihn 3y ago
> Substitution only matters if you’re using inheritance, but if you’re inheriting, you likely have bigger problems as few real world problems are naturally represented by inheritance. No, it matters when you implement interfaces (in the Java sense) too. Tons of real world problems are naturally solved by having multiple implementations of interfaces. Also, Dependency Inversion doesn't even make sense without it.

by hajile 3y ago

mytailorisrich 3y ago

> The idea that one class changing won’t change others is a pipe dream Reality is never black and white but that's a good principle for good software design and worth at least aiming for. If anything that has been adopted and generalised in microservices, etc. because encapsulation, modularity, design by contract all hinge of this same idea, which is powerful and useful. That's why when discussing any "principles" the important is to get the core idea behind them instead of sticking to the letter and discarding them as useless.

hajile 3y ago
Encapsulation is extremely important and pairs with single responsibility, but that’s completely orthogonal to OOP. Once you are solidly in the composition camp, functions are immediately superior. They tend to be naturally single purpose and have mathematical rules that make them easy to compose. Most function-heavy languages also adopted modules which provide a better, less-leaky abstraction too and that’s without getting into all the other advantages in the type system or better syntactic ergonomics from dropping all the OOP baggage.

nyrikki 3y ago

Even in Uncle Bob's version of the single responsibility principle, 'one reason to change' is about people. He words it poorly, but it is more about not commingling DBA, UX, core domain logic in a module. People miss that and end up having low cohesion. While SRP and interfaces do have an intersection, they are not the same. Interfaces leaking implementation details is an example. Composition, dependency inversion, and dependency injection are all forms of L. Polymorphism is problematic in most cases but thinking it is the only way to accomplish that looser coupling goal is a misunderstanding of where we have grown with the concepts. I tend to prefer the ports and adapters pattern, which ensures client components that invoke an operation on a server component will meet the preconditions specified as required for that operation. That is equivalent to LSP or design by contract. SOLID is just a set of principles that are intended to make loose coupling and high cohesion the ideal default. This is in contrast to procedural code that we know makes unmaintainable systems. The problem with SOLID is the same as Agile, XP etc... People ignore the core ideas that are descriptive in nature and try to use them as oversimplified prescriptivist rules. To be fair Robert Martin wasn't great at selling this and that is why I tend to point people to authors like Martin Fowler who are more careful about sounding like a preacher handing out laws. But Robert Martin developed SOLID in the context of cohesion, and if you read it in that context it is valuable. He didn't invent the SOLID tool to remember the rules, but it seems that blog posts and Wikipedia pages are as far as people get before trying to implement it or dismiss it.

Scubabear68 3y ago
Take a look at Uncle Bob’s code some day. You will then realize that all of his writing was synthesized solely to make him consulting money. His actual code is rubbish. This has been true all the way back to the 90’s with his inane questions to the OOP Usenet groups.
- nyrikki 3y ago
  I already stated he isn't like his books personally. But outside of Tu quoque fallacies, van you explain why this is a bad idea. "A module should be responsible to one, and only one, actor."

ahtihn 3y ago

> Substitution only matters if you’re using inheritance, but if you’re inheriting, you likely have bigger problems as few real world problems are naturally represented by inheritance. No, it matters when you implement interfaces (in the Java sense) too. Tons of real world problems are naturally solved by having multiple implementations of interfaces. Also, Dependency Inversion doesn't even make sense without it.