I don't remember exactly where the title text came from, but I remember seeing and hearing in C# that the implementation method should not be written in abstract classes as much as possible.
However, as mentioned above, I am not sure where the information was obtained, and I am worried about whether it is correct knowledge due to the possibility of misremembering it.
When I looked it up on the web, I found that abstract methods and implemented methods are mixed in the abstract class of the code I'm describing, and I'm not sure if the title is wrong.
For your information, I would like to briefly cite the content of the code I am currently facing.
[Reference]
実装The implemented method is called the implementation method
In particular, in this "Initialization, calculation, instance generation, etc. of variables common to all derived classes are performed in the HogeBase class," I thought, "It's just the basis, so shouldn't we initialize or calculate there?" and this leads to the title.
I'm sorry for the long sentence.
Thank you very much for your cooperation.
The type that does not have any implementation methods is interface in C#, which is different from the abstract class.So if "Is it better to have no implementation method in an abstract class as much as possible?" is true, it will no longer be an abstract class, so I don't think it's correct.
Also, for example, System.IO.Stream is not ISstream but is an abstract class and has a number of "implementation methods".Abstract classes should have a lot of implementation methods to follow this design.
These are only designs in the C# language, and things will be different in other languages.
In the first place, inheritance exists for the purpose of commonizing code in object orientation.
If you don't meet the purpose of code commonization, I don't think you can pay for the disadvantage of building an inheritance hierarchy.Abstract methods are able to bind signatures, which do not contribute to reducing the amount of code.Only implementation methods can provide code commonality.
As the questioner suggests, the inheritance hierarchy can be eliminated by keeping a reference to an instance of the class HogeDraw, which is a common part of the process, and using the difference part of the process as an implementation of interface IHogeCalc.(Design principle of attempting to replace in composition without so-called inheritance)
What matters here is the role sharing between HogeDraw and HogeCalc.If HogeDraw is able to share roles with Calc so that it remains unchanged regardless of class, you can eliminate the inheritance hierarchy above, but if not, it is probably better to use inheritance.
(I think modern object orientation is more likely to recommend interface-based mixin than abstract class inheritance because C# does not allow multiple inheritance of classes, so trying to rebuild classes from a certain perspective doesn't work.)
© 2024 OneMinuteCode. All rights reserved.