Timeline for Is Abstracting your code too much a bad use of SOLID Principles?
Current License: CC BY-SA 4.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 26, 2018 at 8:11 | comment | added | Ewan | @jaymee 100% agree YAGNI isnt about costs its about need. no one is suggesting you spend time building unrequested features. | |
| Jul 26, 2018 at 8:11 | comment | added | JᴀʏMᴇᴇ | Further still, you're not actively abstracting, or at least - you shouldn't be. From the start you should write 'stuff' that has one job. That's all. Surprised this topic has so much heat after years and years of OOP being tried and tested. | |
| Jul 26, 2018 at 8:07 | comment | added | JᴀʏMᴇᴇ | Can I also just ask this (again) - we're talking about 'costs' here, what costs?!?! What is the cost to a nice separation of concerns from the start?? The argument about whether this is 'worth it' or not is predicated on the assumption of a cost to ensuring SRP. There is no cost. It's maintainable, easier to write, most certainly easier to read, it's self-documenting, it's more testable. I'm totally lost as to why the approach suggested in this answer is even up for debate. It is a very short-sighted view that would suggest the time taken to abstract > time taken dealing with monoliths. | |
| Jul 26, 2018 at 6:40 | vote | accept | Brendon Grundlingh | ||
| Jul 26, 2018 at 6:16 | comment | added | Ewan | @whatsisname I do cover that in the answer. usually you only hear YAGNI after its already been coded. and in this case we are talking about maybe 5 more lines of code | |
| Jul 26, 2018 at 0:21 | comment | added | whatsisname | @Ewan: I know it's an analogy, but that super garage, you have to pay additional utilities, property tax, etc to maintain it. If you never put a helicopter in, it might not be worth to have paid for the upkeep. The same is true in software, but additional cost to write it and more cognitive difficulty. Rarely is anything totally free. | |
| Jul 25, 2018 at 12:23 | comment | added | JᴀʏMᴇᴇ | @jwenting - I think you need to relax a bit. How is it any more horribly performing? How is it unreadable? You know exactly what that method is going to do. | |
| Jul 25, 2018 at 11:22 | comment | added | JᴀʏMᴇᴇ | @Flater - it's not my assertion to back-up, it's a tried and tested principle. I have pointed the OP to a very very well-respected resource in which it discusses, in length, the benefits. | |
| Jul 25, 2018 at 11:22 | comment | added | Flater | @JᴀʏMᴇᴇ: You make spurious assertions, do not back them up, and either respond in non-sequiturs or dodge the topic whenever someone points out the flaw in your statement. This is pointless. | |
| Jul 25, 2018 at 11:17 | comment | added | JᴀʏMᴇᴇ | @Flater - I didn't, I haven't posted a single answer. This is precisely why it was a comment. | |
| Jul 25, 2018 at 11:17 | comment | added | Flater | @JᴀʏMᴇᴇ Can't believe I'm having to spell out the principles of OOP Then don't post answers in questions asking about the principles of OOP. | |
| Jul 25, 2018 at 11:15 | comment | added | JᴀʏMᴇᴇ | @jwenting - that sounds neat and tidy to me. I don't see the problem. It's testable, clear, almost self-documenting. What is the issue? | |
| Jul 25, 2018 at 11:15 | comment | added | jwenting | @JᴀʏMᴇᴇ I've seen way too many very bad examples of your logic taken to its logical end point. Which led to one program having a class to add 2 integers, with a method add(int), which was used in lue of doing like int i=a+b; THAT's the end result of your idea | |
| Jul 25, 2018 at 11:14 | comment | added | JᴀʏMᴇᴇ | @jwenting - it's written somewhere you need to abstract - yes, with good reason. And an in-depth explanation of those good reasons. Please read the book, or one of the many other hundreds of books discussing SRP. | |
| Jul 25, 2018 at 11:13 | comment | added | jwenting | @JᴀʏMᴇᴇ the only reason you've given is that you need to abstract because you need to abstract because it's written somewhere you need to abstract, and that you need to never stop abstracting. So abstraction becomes its own justification according to your logic. | |
| Jul 25, 2018 at 11:13 | comment | added | JᴀʏMᴇᴇ | keep abstracting code until you can't anymore - "can't" meaning it now does one single thing. Can't believe I'm having to spell out the principles of OOP. | |
| Jul 25, 2018 at 11:12 | comment | added | Flater | @JᴀʏMᴇᴇ: that directly contradicts the single responsibility principle. If you're presented with a unit that could be extracted The SRP is that justification to abstract that I'm taking about. You're still not getting that "always abstract" and "SRP is a valid reason to abstract" are two completely different things. You intended the latter, but you stated the former. | |
| Jul 25, 2018 at 11:12 | comment | added | JᴀʏMᴇᴇ | @jwenting - absolutely not. If there are reasons behind what I'm suggesting, reasons very very well established, how is that at all for the sake of it? | |
| Jul 25, 2018 at 11:11 | comment | added | jwenting | @JᴀʏMᴇᴇ if you don't draw a line at where to stop abstracting you are by definition abstracting for the sake of abstracting, as there's never going to be an end to it. | |
| Jul 25, 2018 at 11:11 | comment | added | Flater | @JᴀʏMᴇᴇ: Your response is a non-sequitur. At no point did I argue against SRP. I argued against the assertion that abstraction is always good regardless of context. And you're contradicting yourself: (A) I don't believe the line should be drawn. (B) There are valid reasons for abstraction to the Nth degree If (A) is correct, then (B) doesn't need "to the Nth degree" since there's allegedly no upper limit. | |
| Jul 25, 2018 at 11:11 | comment | added | JᴀʏMᴇᴇ | This is the issue: every next level of abstraction needs to justify its existence. It's not a default "yes". - that directly contradicts the single responsibility principle. If you're presented with a unit that could be extracted, given the fact a decision needs to be made, it's probably doing too much or, at least, is not doing one single thing. | |
| Jul 25, 2018 at 11:09 | comment | added | JᴀʏMᴇᴇ | @Flater - I think you've missed the point again. I don't believe the line should be drawn. But that doesn't mean I'm suggesting it for the sake of it. Again - these are OOP fundamentals, the concept of single responsibility is not new, nor is it up for debate usually. | |
| Jul 25, 2018 at 11:07 | comment | added | Flater | @JᴀʏMᴇᴇ: As per your own statement: I'd say, on the contrary, keep abstracting code until you can't anymore. So why are you drawing the line at N abstraction levels, and why not at N+1? Or N+2? ... This is the issue: every next level of abstraction needs to justify its existence. It's not a default "yes". | |
| Jul 25, 2018 at 11:06 | comment | added | JᴀʏMᴇᴇ | @Flater - this argument of 'for the sake of it' is facile. There are valid reasons for abstraction to the Nth degree. Why do you keep saying for the sake of it? | |
| Jul 25, 2018 at 11:05 | comment | added | Flater | @Ewan: Feedback to your answer should not be posted as a separate answer. Ant isn't answering OP's question, they're responding to your overgeneralized assertion that infinite abstraction for abstraction's sake is always the best solution. | |
| Jul 25, 2018 at 11:05 | comment | added | Ewan | @Flater "If it's correct and done or quick to do" If I had the super garage it would be worth more money, even if I don't have a helicopter | |
| Jul 25, 2018 at 11:05 | comment | added | JᴀʏMᴇᴇ | The notion of 'premature abstraction' directly implies that there is a cost to abstraction. It's an approach to design, with a cost I'm not aware of. What is the cost to complying with the idea of a separation of concerns? These are OOP fundamentals. This answer is absolutely correct, keep it nice and clear, nice and separate. | |
| Jul 25, 2018 at 11:03 | comment | added | Flater | In my view YAGNI is never a good argument. Does your house have a garage that is able to house a limo, or a helicopter, or both? Apparently, you can't argue that you're not going to need this, as per your own statement. This is clearly incorrect. YAGNI is always a relevant argument, the only debatable topic is where you draw the line of relevance. The odds of a change occurring need to outweigh the cost of implementing the abstraction that simplifies the change. | |
| Jul 25, 2018 at 11:01 | comment | added | Brendon Grundlingh | I agree with @Ewan, make it a question so we can vote. Very good points are made in this post | |
| Jul 25, 2018 at 10:54 | comment | added | Ewan | @AntP you should write an answer so we can see by the voting which view various peoples experience has lead them to agree with | |
| Jul 25, 2018 at 10:51 | comment | added | Ant P | Disagree with this answer. Abstracting prematurely leads to higher cognitive load in comprehending code and most often lead to abstractions that turn out to be unnecessary or - more importantly - wrong and difficult to reverse. I believe that abstracting hard dependencies at boundaries of systems is a sensible starting point and all other abstraction should be driven by need. Of course different people have a different idea of what "abstraction" actually means. | |
| Jul 25, 2018 at 10:49 | history | edited | Ewan | CC BY-SA 4.0 | added 341 characters in body |
| Jul 25, 2018 at 10:42 | history | answered | Ewan | CC BY-SA 4.0 |