È una cattiva pratica creare una sottoclasse nel nome solo per la leggibilità?

8

Ho tre sensori in un unico pacchetto che devono essere tutti calibrati, che chiamerò sens1, sens2 e sens3. La calibrazione per sens1 e sens2 sono identici, ma la calibrazione per sens3 richiede un parametro aggiuntivo. La mia domanda è: "Qual è il modo migliore per gestire tre oggetti quasi identici pur mantenendo la leggibilità?"

Il mio primo pensiero, ovviamente, era usare il polimorfismo. Vorrei impostare un oggetto Sensor generico con un metodo .calibrate (Parameters params) in cui la classe Parameters mi consente di variare il numero di parametri in base alla calibrazione che sto facendo. Tuttavia, questo porta a quanto segue:

Sensor sens1 = new Sensor();
Sensor sens2 = new Sensor();
Sensor3 sens3 = new Sensor3();

Quindi le persone future dovranno sapere che un sensore è fondamentalmente diverso dagli altri due, ma molto molto simile, mi sembra che la cosa migliore da fare sia sottoclasse Sens1 e Sens2 solo nel nome. In altre parole, crea due sottoclassi che non modificano o estendono alcun comportamento per avere più nomi di classi logiche. Ricorda, tutti e tre questi sensori sono nello stesso pacchetto, quindi questi dati vanno molto spesso insieme. Questo cambia il codice precedente in:

Sensor1 sens1 = new Sensor1();
Sensor2 sens2 = new Sensor2();
Sensor3 sens3 = new Sensor3();

dove

Sensor1 extends Sensor {
}

Sensor2 extends Sensor {
}

Sensor3 extends Sensor {
    @Override
    calibrated(Parameters params) {
        \ Code
    }
}

Sono pazzo di pensare che sia una buona idea? C'è un modello più pulito che mi manca completamente qui?

    
posta tomsrobots 16.05.2015 - 01:18
fonte

3 risposte

5

Come scritto (che può essere semplificato eccessivamente) sembra che i Sensori siano tutti uguali nel comportamento generale, ma i Parametri per la calibrazione sono diversi.

Se questa fosse l'unica differenza, e stai usando un linguaggio con generici, come Java (usato sotto), potresti generare la classe con i Parametri, qualcosa del tipo:

abstract class Sensor<CalibrationParameters> {
   // constructor, getters, setters, etc...

   abstract public void calibrated(CalibrationParameters parameters);
}

quindi un gruppo di

public class SensorN extends Sensor<CalibrationParametersForSensorN> {

   public void calibrated(CalibrationParametersForSensorN parameters) {
      ...
   }

}

Avvertenza: digitata senza IDE, quindi potrebbero esserci errori di battitura o errori ...

P.S. D'accordo con Robert che i nomi migliori sarebbero, ehm, meglio. Quindi una migliore implementazione concreta sarebbe:

public class Thermometer extends Sensor<ThermometerCalibration> {

    public void calibrated(ThermometerCalibration parameters) {
       ...
    }

}
    
risposta data 16.05.2015 - 01:28
fonte
9

Non se i migliori nomi descrittivi per questi sensori sono Sensor1 , Sensor2 e Sensor3 . I numeri non indicano alcuna caratteristica distintiva tra i sensori.

Se le diverse classi denotano differenti tipi di sensori, allora potrebbero essere garantite classi diverse. Questo è il motivo per cui a volte ci riferiamo alle classi come tipi, sebbene la parola "tipo" abbia un significato più ampio.

PressureSensor extends Sensor
TemperatureSensor extends Sensor
    
risposta data 16.05.2015 - 01:27
fonte
0

Non sono sicuro che la calibrazione dovrebbe essere responsabilità del sensore ... Vorrei prendere in considerazione la creazione di 2 nuove classi. Qualcosa come SensorCalibratorBase, SensorCalibratorAdavanced. Quindi, vorrei creare un'istanza specifica del calibratore in base allo stato dell'app e inserire l'istanza del sensore nella sua funzione Calibra. Ogni calibratore otterrebbe i parametri necessari come argomenti del costruttore.

    
risposta data 16.05.2015 - 17:23
fonte

Leggi altre domande sui tag