4 ms·

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 commin

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."
  - Scubabear68 3y ago
    The problem is that Uncle Bob made up SOLID and other ideas more or less by cobbling random ideas from other people and selling them on the market as his own. As many others have mentioned here, pieces of SOLID kinda-sorta make sense, but it doesn't hang together cohesively because it was never created in a cohesive manner. ALWAYS look behind the curtain at what software consultants are selling to what they have actually built, and then you can ascertain if they are selling you hard won engineering knowledge or a bunch of marketing BS.
    - nyrikki 3y ago
      As I want to learn, outside of the problems with cargo culting, why having the SOLID principals as the default _ideal_ when programming cause problems. Sure he was pulling from Structural design ideas, which even Tom DeMarco, the author of the canonical book on SD, now says should have been iterative and Agile-like, but he was also pulling from papers like the following from 1972 about modularity. https://dl.acm.org/doi/10.1145/361598.361623 https://dl.acm.org/doi/10.1145/361598.361623 The SOLID principles are a specific application of computer science principles to OO. Separation of Concerns is a specific example of core CS principals that he pulled from but are from Dykstra. https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF So is your reason for discrediting him that he aspired to be a professional writer, or that he tried to collect concepts from the wider tent into a more domain specific presentation? Because structural design is an example where the founders realized that not paying attention to that first paper was problematic. "We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more sub- routines, and instead allow subroutines and programs to be assembled collections of code from various modules." How about addressing Robert Martin's position, instead of irrelevantly attacking random aspects of the person who is making the argument. A.K.A Ad Hominem fallacies. In the context of this thread, if a candidate could only express their objections to _ideals_ that are intended to be the defaults, and couldn't express their objections in a way that related to business and customer needs, I would be a hard no on the hiring position. It is OK to not agree with these ideals, but to only offer personal attacks to dismiss them, it indicates someone who will probably be a difficult team member and lack customer focus. Ad Hominem's never address the real concerns or needs of a project and are simply not constructive. We know that EA failed, we know SOA works better if imperfect, we know that aiming for loosely coupled and highly cohesive code results in systems that are easier to maintain and scale, and we know that with the rise of the cloud most needs will be distributed. All of those apply the same principles at a different scale or domain. Hand waving away those well known concepts because you have a distaste for an author won't change that. But if you share ideas that address the limits of those ideas perhaps it can help move us further.
- realusername 3y ago
  That's also my unpopular opinion about him, I thought I was alone. I watched some of his clean code videos in the past and thought his advice looked dated and very "enterprise" styled.
  - Scubabear68 3y ago
    Back in the 1800's and early 1900's medicine was a very new science (in a modern sense), and snake oil salesmen abounded. Laymen had very little information to discern legitimate medical advice from quacks hocking piss and ink as a cure all. We have the same problem now with software systems, although at the least we are advancing beyond the primitive stages and the charlatans are becoming more apparent.

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."
- Scubabear68 3y ago
  The problem is that Uncle Bob made up SOLID and other ideas more or less by cobbling random ideas from other people and selling them on the market as his own. As many others have mentioned here, pieces of SOLID kinda-sorta make sense, but it doesn't hang together cohesively because it was never created in a cohesive manner. ALWAYS look behind the curtain at what software consultants are selling to what they have actually built, and then you can ascertain if they are selling you hard won engineering knowledge or a bunch of marketing BS.
  - nyrikki 3y ago
    As I want to learn, outside of the problems with cargo culting, why having the SOLID principals as the default _ideal_ when programming cause problems. Sure he was pulling from Structural design ideas, which even Tom DeMarco, the author of the canonical book on SD, now says should have been iterative and Agile-like, but he was also pulling from papers like the following from 1972 about modularity. https://dl.acm.org/doi/10.1145/361598.361623 https://dl.acm.org/doi/10.1145/361598.361623 The SOLID principles are a specific application of computer science principles to OO. Separation of Concerns is a specific example of core CS principals that he pulled from but are from Dykstra. https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF So is your reason for discrediting him that he aspired to be a professional writer, or that he tried to collect concepts from the wider tent into a more domain specific presentation? Because structural design is an example where the founders realized that not paying attention to that first paper was problematic. "We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more sub- routines, and instead allow subroutines and programs to be assembled collections of code from various modules." How about addressing Robert Martin's position, instead of irrelevantly attacking random aspects of the person who is making the argument. A.K.A Ad Hominem fallacies. In the context of this thread, if a candidate could only express their objections to _ideals_ that are intended to be the defaults, and couldn't express their objections in a way that related to business and customer needs, I would be a hard no on the hiring position. It is OK to not agree with these ideals, but to only offer personal attacks to dismiss them, it indicates someone who will probably be a difficult team member and lack customer focus. Ad Hominem's never address the real concerns or needs of a project and are simply not constructive. We know that EA failed, we know SOA works better if imperfect, we know that aiming for loosely coupled and highly cohesive code results in systems that are easier to maintain and scale, and we know that with the rise of the cloud most needs will be distributed. All of those apply the same principles at a different scale or domain. Hand waving away those well known concepts because you have a distaste for an author won't change that. But if you share ideas that address the limits of those ideas perhaps it can help move us further.
realusername 3y ago
That's also my unpopular opinion about him, I thought I was alone. I watched some of his clean code videos in the past and thought his advice looked dated and very "enterprise" styled.
- Scubabear68 3y ago
  Back in the 1800's and early 1900's medicine was a very new science (in a modern sense), and snake oil salesmen abounded. Laymen had very little information to discern legitimate medical advice from quacks hocking piss and ink as a cure all. We have the same problem now with software systems, although at the least we are advancing beyond the primitive stages and the charlatans are becoming more apparent.