-
Notifications
You must be signed in to change notification settings - Fork 5.5k
C.120 Understanding "Do not use inheritance when simply having a data member will do." #1963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It's not superfluous if it avoids unwanted coupling and other unwanted effects like derived-to-base conversions, ADL, slicing etc. |
Thank you, Jonathan, for confirming that wrapping is a reasonable approach. At the same time, I propose, that some might choose to ignore this guideline in some cases. and wait until the language has support for automatically exposing functions of object data members at the containing object interface (for example |
The guidelines cannot cover all situations. If waiting indefinitely for a hypothetical language extension that isn't on the agenda is the right call for your project, that's your call. The guideline seems correct as written for today's C++ language. |
This also relates to whether wrapper functions to expose data object members would ever be needed because if the data member is the correct decision based on overall application design, then exposing the functions might not make sense. In that case, my syntax suggestion would also not be applicable because the usefulness of wrappers would not apply. I think that the key with C.120 is not whether "a data member will do" 🙂. As we know, inheritance is (very 🙂) useful but not essential, so one could always design around inheritance and use data members - or vice-verse one can force inheritance by deciding to make constructor or other functions protected etc. The real decision is whether inheritance efficiently and intelligently serves the goals of the application. This relates more to the type as a concept, and the concept itself, again, relates to the goals of the application. |
@CompCodeNet When reading C.120 I read it more as if you're using a pure data object then don't use inheritance. C.120 could probably be enhanced with a good example of that portion of the guideline; |
@BenjamenMeyer Thank you, an example is helpful. However, I also think that the starting point should be to explain the purpose of inheritance as a language capability. As discussed in previous post, the purpose of inheritance is to abstract or extend types that fulfill a conceptual role. So, one would only want to inherit (including multiple) if the resulting (derived) exposed interface fits the concept of the type. I.e. What you are inheriting is in line with the type's concept. From this understanding, one can then distinguish between internal members that support the implementation of the class's concept vs. exposed functions that manifest the class's concept. |
@jwakely I can see that inline wrappers for contained objects would essentially be "comments" since the compiler would turn them into NOPs except the actual _containedObject.SomeFunction( ) call. I can also see that it's a decent approach to keeping code clean and simple. The only other point that I was making is that it's good if the language can accommodate these things in syntax and thus reduce the verbosity. |
Editors call: @jwakely answered this well. Thanks! |
The text was updated successfully, but these errors were encountered: