Timeline for How do the SOLID principles apply in the context of Lambdas and Streams?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2020 at 14:49 | comment | added | Robert Bräutigam | @BenCottrell Also, I honestly don't know what the "correct" interpretation of SRP is. I've read the book(s), I know and thought about the last 5 tries of Uncle Bob to define it. The last one, that it is "about people" is just nonsensical to me. So I just take what most people understand under SRP and talk about that. If you say that's not what it means, I'm curious what you mean. | |
| Jun 17, 2020 at 14:42 | comment | added | Robert Bräutigam | @BenCottrell Ok, the code you split up may actually have no connection to the other code you had in the class. So that would not increase coupling, you're right. However that's the most you can say. It will never decrease coupling. | |
| Jun 17, 2020 at 14:30 | comment | added | Ben Cottrell | I also disagree with the premise that splitting up objects results in increased coupling. There is no reason for objects to have any dependency on each other at all. Any object can do its job or jobs without being dependent upon other objects provided it has enough information. The task of orchestrating objects and facilitating communication between objects does not require those objects to communicate with each other nor have any dependency on each other -- it doesn't even require them to share any interfaces. Orchestration is often separate. | |
| Jun 17, 2020 at 14:21 | comment | added | Ben Cottrell | What you're describing there is a result of failure to follow SRP and OCP. It's not entirely uncommon for people to misunderstand or misinterpret - again, that could be down to people viewing them as general purpose guidelines such as assuming it means "an object should only do one thing", or just not really understanding the requirements of a project. Tightly-coupled classes and code which requires a lot more mocking and set-up in unit tests are a very definite violations of SRP. | |
| Jun 17, 2020 at 9:10 | comment | added | Robert Bräutigam | @BenCottrell That's the sales pitch. It's highly debatable whether any of that is true. "Avoids tight coupling" sounds especially untrue, given that SRP primes developers to split stuff. Splitting up objects never results in less coupling, since coupling is a thing between objects. The most you can argue, is that it may result in increased cohesion, but that happens at the expense of coupling. | |
| Jun 16, 2020 at 22:07 | comment | added | Ben Cottrell | SRP and OCP are often mistaken as general guidelines, but really are context-dependent. One of their main design advantages however lies in writing code which is easily unit-testable, avoids tight coupling between classes, avoids/minimises injected dependencies, minimises/avoids the need for mocking and extensive setup in unit tests, minimises the number of different test cases needed for sufficient unit test coverage. | |
| Jun 16, 2020 at 19:19 | history | answered | Robert Bräutigam | CC BY-SA 4.0 |