Is it good practise to blank out inherited functionality that will not be used?
- by Timo Kosig
I'm wondering if I should change the software architecture of one of my projects.
I'm developing software for a project where two sides (in fact a host and a device) use shared code. That helps because shared data, e.g. enums can be stored in one central place.
I'm working with what we call a "channel" to transfer data between device and host. Each channel has to be implemented on device and host side. We have different kinds of channels, ordinary ones and special channels which transfer measurement data.
My current solution has the shared code in an abstract base class. From there on code is split between the two sides. As it has turned out there are a few cases when we would have shared code but we can't share it, we have to implement it on each side.
The principle of DRY (don't repeat yourself) says that you shouldn't have code twice.
My thought was now to concatenate the functionality of e.g. the abstract measurement channel on the device side and the host side in an abstract class with shared code. That means though that once we create an actual class for either the device or the host side for that channel we have to hide the functionality that is used by the other side.
Is this an acceptable thing to do:
public abstract class MeasurementChannelAbstract
{
protected void MethodUsedByDeviceSide()
{
}
protected void MethodUsedByHostSide()
{
}
}
public class DeviceMeasurementChannel : MeasurementChannelAbstract
{
public new void MethodUsedByDeviceSide()
{
base.MethodUsedByDeviceSide();
}
}
Now, DeviceMeasurementChannel is only using the functionality for the device side from MeasurementChannelAbstract. By declaring all methods/members of MeasurementChannelAbstract protected you have to use the new keyword to enable that functionality to be accessed from the outside.
Is that acceptable or are there any pitfalls, caveats, etc. that could arise later when using the code?
