Una classe genitore non ha attributi o funzioni?

Le 3 classi condividono un'interfaccia? Cioè, forniscono un modo coerente per interrogarli? Non lavoro molto con i sensori, ma mi sembra strano che un sensore di livello dell'acqua e un sensore di porta abbiano molto in comune. Nel tuo diagramma sopra, hanno 3 diversi metodi che implementano ( MethodX() , MethodY() e MethodZ() ), ma nulla di ovvio in comune.

Se ognuno è in grado di emettere, ad esempio, un valore in virgola mobile che rappresenta la tensione proveniente dal sensore, allora potrebbe essere più sensato avere 3 diverse classi che contengono ciascuna un sensore, ma non ereditano da nessuna classe base. Questa è chiamata composizione oggetto piuttosto che eredità .

Per rispondere alla tua altra domanda - va bene avere una classe base che è "vuota" in quanto non ha variabili membro e tutti i suoi metodi sono astratti. Questa sarebbe essenzialmente un'interfaccia. A seconda della lingua che usi per implementarlo, puoi renderlo un'interfaccia (in qualcosa come Java o Objective-C) o una classe base astratta (in C ++).

Nella mia mente si tratta di questo: avrai mai bisogno di sostituirne uno con uno degli altri? Dato quello che fanno, non sembra probabile a meno che tu non sia il produttore dei sensori e scriva un'imbracatura di prova per testarli prima di spedirli ai clienti. In tal caso, potresti volere un metodo come getVoltage() su tutti loro. Ma per gli utenti finali di queste classi, probabilmente vorrai qualcosa di più specifico come getWaterLevel() , getDoorPosition() e getTemperature() . Internamente, potevano interrogare un oggetto Sensor per la sua tensione (o qualunque cosa fosse appropriata). Ma le interfacce probabilmente non avrebbero bisogno di essere molto simili dato che sarebbero state utilizzate in scenari così diversi.

Se veramente non condivide alcun comportamento, non dovrebbero condividere una classe base.

La vera domanda è, condividono il comportamento e penso che la risposta sia "sì" se la tua lingua supporta i modelli generici o di classe. Anche allora creerei un'interfaccia.

public interface ISensor<T>
{
    T Read();
}

public class WaterSensor : ISensor<float>
{
    public float Read() { ... }
}

Ogni sensore deve essere letto per essere utile. Oltre a questo non vedo alcuna ragione per cui queste classi dovrebbero essere correlate.

Vedo che potrebbe esserci un valore in un sensore di classe genitore perché presumo che ci sia o sarà una funzionalità comune. Ad esempio, ciascun sensore avrà una serie di attributi misurati e alcuni criteri che definiscono se il sensore è considerato scattato - o forse tre livelli normali, di allarme e critici. Quindi vedo una classe genitore con un'interfaccia in modo che i discendenti debbano implementare la funzionalità comune.

Il resto dell'applicazione gestisce gli oggetti generici "Sensore" e in realtà non conosce e non dovrebbe conoscere il funzionamento interno di ciascun sensore.