Timeline for Managing and organizing the massively increased number of classes after switching to SOLID?
Current License: CC BY-SA 4.0
39 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 12, 2019 at 9:45 | comment | added | Ben | Remember that from the point of view of design, a function is an object, and a function signature is an interface. You don't need to implement a million classes each with one function in order to be doing SOLID. | |
| Jul 11, 2019 at 17:38 | comment | added | Filip Milovanović | @R.Schmitz: The O in SOLID is not necessarily about subclassing (in fact, it uses the term "software entities"). There's nuance to it; despite how it appears in its condensed statement, it doesn't say that it should be applied everywhere equally. And it's not anachronistic at all, we all rely on it every day. It can be applied at many levels: encapsulation, subclassing, interface implementation, dependency inversion, plugin architectures, protocols, APIs, etc. are all different expressions of OCP. Anything that relies on something else needs that something to be relatively unchanging (closed). | |
| Jul 11, 2019 at 15:55 | answer | added | Scott Hannen | timeline score: 2 | |
| Jul 11, 2019 at 12:18 | comment | added | Pierre Arlaud | Maybe this question I asked a while ago is also very relevant: softwareengineering.stackexchange.com/questions/220230/… | |
| Jul 11, 2019 at 2:03 | answer | added | maaartinus | timeline score: 2 | |
| Jul 10, 2019 at 15:07 | comment | added | R.. GitHub STOP HELPING ICE | Seriously, (assuming you're using proper version control), revert to the version before you started this mess, then burn a copy of the branch that went wrong to a CD (or maybe a blu-ray, since it sounds like it no longer fits on a CD or even a DVD) and find someone with the right spiritial empowerments to exorcise it in fire. | |
| Jul 10, 2019 at 12:49 | comment | added | hegel5000 | I wish it were idiomatic, in more languages, to put multiple small and related classes (as well as free functions/classes with a single static method and no state) into a single file, at ~50-200 lines per file. I've found that that style makes SOLID a good bit easier. | |
| Jul 10, 2019 at 11:57 | comment | added | Eric Duminil | It reminds me of github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition. | |
| Jul 10, 2019 at 10:24 | comment | added | R. Schmitz | @Graham "Part of me wonders if SOLID is overrated" even more, IMHO, the O is anachronistic. Most classes I write are supposed to do the one thing I think of, and not the infinite other things other people could think of when subclassing it. Most classes I write, I write with a "not open" mindset and they are better off as final/sealed. | |
| Jul 10, 2019 at 1:28 | comment | added | whatsisname | @JDDavis: knowing where to draw that line is part of the craft of software development. We can't do your job for you. If you nor your coworkers have the experience to have a 6th sense about it, you're just going to have to take your best shot and see how it goes youtube.com/watch?v=HBxcalnSzIk | |
| Jul 9, 2019 at 22:50 | comment | added | JD Davis | Again, I must ask where the line is drawn. Following SOLID, one of the most intuitive things for me personally is setting up DI so that pretty much none of my classes have dependencies on any other classes. I'm able to achieve 100% code coverage with arguably pretty decent tests in most cases. As you start to combine class responsibilities, the number of dependencies and resources those classes require also increases. How do you combat having to inject potentially 10-15 classes into the class when you have operations that are largely cross-cutting. | |
| Jul 9, 2019 at 22:05 | comment | added | BlueRaja - Danny Pflughoeft | HIGHLY related: softwareengineering.stackexchange.com/questions/14856/… | |
| Jul 9, 2019 at 21:49 | answer | added | candied_orange | timeline score: 14 | |
| Jul 9, 2019 at 19:52 | comment | added | GHP | @sbecker As for it being "proven to be very valuable" I'm sure it has on LOTS of projects (I've even written some!) but its not a silver bullet for ALL projects (as whatsisname indicates). Assuming that "SOLID = Better than not-SOLID" is the problem. Its just a technique (certainly a good one), but not a cure-all. | |
| Jul 9, 2019 at 19:50 | answer | added | Lao | timeline score: 5 | |
| Jul 9, 2019 at 18:35 | comment | added | Eric Lippert | There's a disorder of thought I call "object happiness disease", which is the belief that OO techniques are an end in themselves, rather than just one of many possible techniques to decrease the costs of working in a large codebase. You have a particularly advanced form, "SOLID happiness disease". SOLID isn't the goal. Lowering the cost of maintaining the codebase is the goal. Evaluate your proposals in that context, not in whether it is doctrinaire SOLID. (That your proposals are also probably not actually doctrinaire SOLID is also a good point to consider.) | |
| Jul 9, 2019 at 18:09 | history | edited | Robert Harvey | CC BY-SA 4.0 | deleted 5 characters in body |
| Jul 9, 2019 at 17:23 | comment | added | Filip Milovanović | Looks like your classes and other elements are too granular; you are being concerned with each individual operation, and you are not thinking about domain concepts and not modeling the domain. Your tests also seem to depend on the internals, but they should really be expressed in terms of higher level policies (so you can refactor without breaking half of the tests). It also looks like you are testing stuff that you really shouldn't: e.g., what does NewGuidProviderTests test for? If System.Guid.NewGuid() returns a GUID? | |
| Jul 9, 2019 at 17:06 | comment | added | Fabio says Reinstate Monica | Related: When using the Single Responsibility Principle, what constitutes a “responsibility?” | |
| Jul 9, 2019 at 16:18 | comment | added | JD Davis | @JohnBollinger in my case I wasn't necessarily having to modify many files to add functionality, but rather I was having to create many files as none of prerequisite functionality existed for what I was building. If we wanted to modify some portion of the implemented functionality, in theory each change should only require me to touch 1 or 2 files now. | |
| Jul 9, 2019 at 16:15 | comment | added | John Bollinger | @Graham, whereas applying SOLID principles may result in projects consisting of more files, when done correctly it does not make it hard to add features. On the contrary, it tends to facilitate adding features. The OP's issue of having to modify such large numbers of files to apply a change is thoroughly inconsistent with SOLID -- they seem to have misunderstood the relevant design principles. | |
| Jul 9, 2019 at 15:37 | comment | added | whatsisname | @Graham: the problem isn't that SOLID is over or underrated, it's that there are certain kinds of softwares where it makes sense and others it doesn't. SOLID is best used in beheometh consultingware-ERP type software deployments, the kinds of software the author of SOLID consults for. In software for a vending machine running on a microcontroller, not so much. The SOLID author and many users of it don't always recognize the distinctions. | |
| Jul 9, 2019 at 15:00 | history | tweeted | twitter.com/StackSoftEng/status/1148607769215459328 | ||
| Jul 9, 2019 at 14:30 | history | edited | JD Davis | CC BY-SA 4.0 | added 1929 characters in body |
| Jul 9, 2019 at 14:24 | comment | added | sbecker | @Graham SOLID isn't new. It's been around for decades and has been proven to be very valuable. Don't be encouraged by stories like this one. SOLID is complicated and difficult to apply. Jumping head first into it, screaming "best practice" isn't a good approach. | |
| Jul 9, 2019 at 14:00 | answer | added | John Bollinger | timeline score: 30 | |
| Jul 9, 2019 at 13:16 | comment | added | jpmc26 | @whatsisname I find that SOLID's formulation actually encourages that way of thinking. TDD advocacy often does, too. | |
| Jul 9, 2019 at 13:13 | comment | added | GHP | Part of me wonders if SOLID is overrated because when you can't easily add features (due to code complexity), then you're overall bug rate could very easy drop (due to fewer features being completed) which could be misinterpreted as "improvement". You'd have to compare pre and post-SOLID velocities to know for sure though. Also, some devs simply prefer procedural, copy-and-pasted codebases, while others prefer SOLID abstractions. Could be just a matter of style preference too. | |
| Jul 9, 2019 at 12:53 | comment | added | R. Schmitz | One thing that works really well for me regarding SRP is to not establish what responsibilities are up-front, but to let new "responsibilities" emerge naturally ("When reading the code in this class, I need to scroll up and down too much, but these 3 methods here are for the same thing that I can move to its own class.") | |
| Jul 9, 2019 at 11:48 | comment | added | Flater | @whatsisname: I fully agree with you but want to point out that your statement is liable to be misinterpreted. Very often I hear developers (used to bad practice) argue that SOLID takes more effort; simply because they are only observing the short term (a bit more scaffolding effort) and not the long term (severely reduced maintenance effort). Also, "more difficult" is very subjective, as I've worked with many developers who consider monolithic functions to be clearer as opposed to separate classes or design patterns. | |
| Jul 9, 2019 at 11:12 | history | became hot network question | |||
| Jul 9, 2019 at 8:38 | comment | added | Flater | @Euphoric: The issue can occur in both ways. I suspect you're responding to the possibility that 70-100 classes is overkill. But it's not impossible that this just happens to be a massive project which was crammed into 5-10 files (I've worked in 20KLOC files before...) and 70-100 is actually the right amount of files. | |
| Jul 9, 2019 at 7:09 | answer | added | David Arno | timeline score: 105 | |
| Jul 9, 2019 at 6:53 | answer | added | Telastyn | timeline score: 10 | |
| Jul 9, 2019 at 4:46 | comment | added | whatsisname | You've clearly adopted SOLID as a religion rather than a pragmatic tool to help get work done. If something in SOLID is making more work or making things more difficult, don't do it. | |
| Jul 9, 2019 at 4:11 | comment | added | Filip Milovanović | The fact that you have to change more files per task (significantly more!) means that you are doing SOLID wrong. The whole point is to organize your code (over time) in a way that reflects the observed change patterns, making the changes simpler. Every principle in SOLID comes with certain reasoning behind it (when and why it should be applied); it looks like you've gotten yourselves in this situation by applying these blindly. Same thing with unit testing (TDD); if you are doing it without having a good grasp on how to do design/architecture, you are going to dig yourself into a hole. | |
| Jul 9, 2019 at 3:55 | comment | added | JD Davis | Well if the SRP is to be followed, each class should have a single responsibility and a single reason to change. Following that, tons of actions that used to be grouped in massive Logic files are now broken up into small little units. As you break those parts into classes, interfaces, and write unit tests, you now get dozens of smaller, more targeted classes. Whereas before you had large, very general classes doing hundreds of things each. | |
| Jul 9, 2019 at 3:50 | comment | added | Euphoric | "Tasks that used to take 5-10 files can now take 70-100! " How in the hell? This is in no way normal. What kind of changes are you making that require changing that many files?? | |
| Jul 9, 2019 at 3:00 | history | asked | JD Davis | CC BY-SA 4.0 |