Timeline for Why is Clean Code suggesting avoiding protected variables?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 17, 2019 at 12:41 | comment | added | guido | @Telastyn The inheriting approach is the base for accomplishing OCP, I'm interested in understanding how inheritance could break that principle. | |
| Dec 11, 2013 at 1:48 | comment | added | Bryan Glazer | YAGNI=You Aint Gonna Need it LSP=Liskov Substitution Principle OCP=Open/Close Principle SRP=Single Responsibility Principle | |
| S Oct 26, 2012 at 16:17 | history | suggested | samthebrand | CC BY-SA 3.0 | word choise |
| Oct 26, 2012 at 16:14 | review | Suggested edits | |||
| S Oct 26, 2012 at 16:17 | |||||
| Aug 29, 2012 at 15:05 | comment | added | abatishchev | @Telastyn: Can't disagree. But I can't say though that CoI is a principle unreservedly to lead. It's sort of strategy you may want to review against each particular scenario. Shortly, a "nice to know" thing a thing to keep in mind when designing classes. | |
| Aug 29, 2012 at 15:01 | comment | added | Telastyn | @abatishchev I am not inclined to. That article is a bit too strong towards composition IMO. Favoring composition isn't (imo) a principle to follow as strongly as the SOLID principles, since there are a number of scenarios where inheritence is clearly better. Those scenarios tend to be exceptional cases for SOLID. | |
| Aug 29, 2012 at 14:58 | vote | accept | Matsemann | ||
| Aug 29, 2012 at 14:50 | comment | added | abatishchev | You can rephrase point #4 as "They tend to violate Composition over inheritance Principle" | |
| Aug 29, 2012 at 13:50 | review | Suggested edits | |||
| Aug 29, 2012 at 14:08 | |||||
| Aug 29, 2012 at 6:44 | comment | added | user4051 | I agree with this and upvoted it. My corollary is that I start with an implementation and use the "push up" refactoring when I need it—so I only end up with protected variables in the case that the need can be demonstrated, not that I thought it'd be useful. | |
| Aug 28, 2012 at 22:43 | comment | added | user8709 | @Talastyn - of course the vertical distance thing could only be respected because C++ allows method definitions to be separated from their declarations, so the insert method for the branch and leaf classes can be kept together etc. And I'm not advocating protected data here, so the relevance is limited. | |
| Aug 28, 2012 at 22:41 | comment | added | user8709 | @Telastyn - one example I had was a multiway tree data structure. Nodes are either branch nodes or leaf nodes. Using late binding and recursion leads to neat implementations of the basic algorithms - no need for explicit is-this-a-leaf-node checks. It's not necessarily a great idea - in fact the multiway tree library I actually use is implemented quite differently - but it's within the realm of reasonable trade-offs. And of course a multiway tree data structure is highly unlikely to suddenly need a new node type next month. | |
| Aug 28, 2012 at 22:08 | comment | added | Telastyn | @steve314 I can't imagine a scenario where the base class and all of its inheritors will only ever live in one file. Without an example I am inclined to think it an abuse of inheritance or poor abstraction. | |
| Aug 28, 2012 at 21:46 | comment | added | user8709 | @Telastyn - not "necessarily". Sometimes, an inheritance hierarchy is defined all in one go and within a single file (where the language doesn't force different classes into different files, at least). This tends to be a design pattern thing rather than an extensibility thing - of course OOP design patterns are intended to be extensible, but they can also be used in cases where extensibility seems unlikely to be an issue, for familiarity or other reasons. Vertical distance is still an issue if the classes are complex, of course - and huge files are a problem too, at least to some people. | |
| Aug 28, 2012 at 16:32 | comment | added | Telastyn | @Matsemann - sure. If I remember the book accurately, that section focuses on the readability and discover-ability of code. If variables and functions work on a concept they should be close in code. Protected members will be used by derived types, which necessarily cannot be close to the protected member since they're in a completely different file. | |
| Aug 28, 2012 at 16:18 | comment | added | Robert Harvey | It seems that Uncle Bob is referring to vertical distance when someone is referring to a protected member between classes, and not in the same class. | |
| Aug 28, 2012 at 16:12 | comment | added | Matsemann | Thanks for many good reasons. However, the book mentions it specifically in a context of formatting and vertical distance, it's that part I'm wondering about. | |
| Aug 28, 2012 at 16:07 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 78 characters in body; added 68 characters in body; added 64 characters in body; added 72 characters in body; edited body |
| Aug 28, 2012 at 16:02 | history | answered | Telastyn | CC BY-SA 3.0 |