¿Es una buena práctica anular la funcionalidad heredada que no se usará?

Question

Me pregunto si debería cambiar la arquitectura del software de uno de mis proyectos.

Estoy desarrollando un software para un proyecto en el que dos lados (de hecho, un host y un dispositivo) usan código compartido. Eso ayuda porque los datos compartidos, p. las enumeraciones se pueden almacenar en un lugar central.

Estoy trabajando con lo que llamamos un "canal" para transferir datos entre el dispositivo y el host. Cada canal debe implementarse en el dispositivo y el lado del host. Tenemos diferentes tipos de canales, ordinarios y canales especiales que transfieren datos de medición.

Mi solución actual tiene el código compartido en una clase base abstracta. A partir de ahí, el código se divide entre los dos lados. Como ha resultado, hay algunos casos en los que habríamos compartido código pero no podemos compartirlo, tenemos que implementarlo en cada lado.

El principio de DRY (no te repitas) dice que no deberías tener código dos veces.

Mi idea era concatenar la funcionalidad de p. Ej. el canal de medición abstracto en el lado del dispositivo y el lado del host en una clase abstracta con código compartido. Sin embargo, eso significa que una vez que creamos una clase real para el dispositivo o el lado del host para ese canal, tenemos que ocultar la funcionalidad que utiliza el otro lado.

es esto una cosa aceptable para hacer:

public abstract class ChannelAbstract 
{ 
    protected void ChannelAbstractMethodUsedByDeviceSide() { } 
    protected void ChannelAbstractMethodUsedByHostSide()  { } 
} 

public abstract class MeasurementChannelAbstract : ChannelAbstract 
{ 
    protected void MeasurementChannelAbstractMethodUsedByDeviceSide() { } 
    protected void MeasurementChannelAbstractMethodUsedByHostSide()  { } 
} 

public class DeviceMeasurementChannel : MeasurementChannelAbstract 
{ 
    public new void MeasurementChannelAbstractMethodUsedByDeviceSide() 
    { 
     base.MeasurementChannelAbstractMethodUsedByDeviceSide(); 
    } 

    public new void ChannelAbstractMethodUsedByDeviceSide() 
    { 
     base.ChannelAbstractMethodUsedByDeviceSide(); 
    } 
} 

public class HostMeasurementChannel : MeasurementChannelAbstract 
{ 
    public new void MeasurementChannelAbstractMethodUsedByHostSide() 
    { 
     base.MeasurementChannelAbstractMethodUsedByHostSide(); 
    } 

    public new void ChannelAbstractMethodUsedByHostSide() 
    { 
     base.ChannelAbstractMethodUsedByHostSide(); 
    } 
} 

Ahora, DeviceMeasurementChannel está utilizando sólo la funcionalidad para el lado del dispositivo de MeasurementChannelAbstract. Al declarar todos los métodos/miembros de MeasurementChannelAbstract protected, debe usar la palabra clave new para permitir el acceso a esa funcionalidad desde el exterior.

¿Eso es aceptable o hay algún inconveniente, advertencia, etc. que pueda surgir más tarde al usar el código?

Answer 1

Para mí, parece un poco como si estuvieras confundiendo la herencia y la composición. Cuando tiene que "en blanco"/arrojar una excepción cuando la funcionalidad heredada no se solapa sanamente, su gráfico de herencia no tiene alguna clase intermedia. Y a menudo esto se debe a que algunas funciones solo deberían provenir de una instancia miembro de otra clase en lugar de heredarse.

Considere también la practicidad, el mapeo de todo en OOP perfecto no es el objetivo, el objetivo es un programa de trabajo que se puede mantener sin grandes dolores.

Answer 2

Me parece que no ha terminado de identificar qué bits de código se comparten. ¿No tendría más sentido mantener todo el material genérico/compartido en MeasurementChannelAbstract en lugar de tener diferentes métodos que las dos partes llaman? ¿Pensaría que deberían estar en clases heredadas?

Answer 3

Puede resolver el problema con la herencia, así:

public abstract class MeasurementChannelAbstract 
{ 
    protected abstract void Method(); 
} 

public class DeviceMeasurementChannel : MeasurementChannelAbstract 
{ 
    public void Method() 
    { 
     // Device side implementation here. 
    } 
} 

public class HostMeasurementChannel : MeasurementChannelAbstract 
{ 
    public void Method() 
    { 
     // Host side implementation here. 
    } 
} 

... o por la composición, utilizando el patrón de estrategia, así:

public class MeasurementChannel 
{ 
    private MeasurementStrategyAbstract m_strategy; 

    public MeasurementChannel(MeasurementStrategyAbstract strategy) 
    { 
     m_strategy = strategy; 
    } 

    protected void Method() 
    { 
     m_strategy.Measure(); 
    } 
} 

public abstract class MeasurementStrategyAbstract 
{ 
    protected abstract void Measure(); 
} 

public class DeviceMeasurementStrategy : MeasurementStrategyAbstract 
{ 
    public void Measure() 
    { 
     // Device side implementation here. 
    } 
} 

public class HostMeasurementStrategy : MeasurementStrategyAbstract 
{ 
    public void Measure() 
    { 
     // Host side implementation here. 
    } 
} 

Me parece que usted desea dividir su jerarquía de herencia entre ambos Canales estándar/de medida y Canales de dispositivo/host. Una forma de hacerlo es con la herencia múltiple, pero C# no admite la herencia múltiple (a excepción de las interfaces), y en la mayoría de los casos, un diseño basado en la composición será más simple.

Answer 4

Me gusta Rich implica: Necesitar solo UNO de los miembros declarados en MeasurementChannelAbstract en una de las implementaciones concretas es una indicación muy clara de que su interfaz está mal definida ya que tiene más de una responsabilidad. Esto significa que es difícil para los clientes de su código (y lectores) comprender las abstracciones y ver la diferencia entre las diversas implementaciones concretas.

Esto se llama "Single Responsibility Principle" y es muy importante para un buen diseño de OO.

(Para obtener más información sobre el buen diseño OO, recomiendo trabajar con todos los principios SÓLIDOS).

Answer 5

Por lo tanto me pregunto si está bien a tienen una única cadena de herencia (aceptando que algunas clases tendrán funcionalidad tanto para el host y el dispositivo lado) y hacer la separación en anfitrión de canal/dispositivo en la última etapa (blanking a cabo la funcionalidad de la que no es necesaria )

Creo que está bien. Pero puede borrar la funcionalidad que no es necesaria mediante el uso de diferentes interfaces para SimpleChannel y MeasurementChannel.