Apakah praktik yang buruk untuk membuat subclass hanya untuk dibaca?

Saya memiliki tiga sensor dalam satu paket yang semuanya harus dikalibrasi yang akan saya sebut sens1, sens2, dan sens3. Kalibrasi untuk sens1 dan sens2 identik, tetapi kalibrasi untuk sens3 membutuhkan parameter tambahan. Pertanyaan saya adalah, "Apa cara terbaik untuk menangani tiga objek yang hampir identik dengan tetap mempertahankan keterbacaan?"

Pikiran pertama saya, tentu saja, adalah menggunakan polimorfisme. Saya akan mengatur objek Sensor generik dengan metode .calibrate (Parameter parameter) di mana kelas Parameter memungkinkan saya untuk memvariasikan jumlah parameter berdasarkan kalibrasi yang saya lakukan. Namun, ini mengarah pada hal berikut:

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

Sehingga orang-orang di masa depan perlu tahu bahwa satu sensor pada dasarnya berbeda dari dua lainnya, tetapi sangat sangat mirip, menurut saya hal terbaik yang harus dilakukan adalah dengan subkelas Sens1 dan Sens2 dalam nama saja. Dengan kata lain, buat dua subkelompok yang tidak mengubah atau memperluas perilaku apa pun untuk memiliki nama kelas yang lebih logis. Ingat, ketiga sensor ini berada dalam paket yang sama, sehingga data ini sangat sering disatukan. Ini mengubah kode di atas menjadi:

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

dimana

Sensor1 extends Sensor {
}

Sensor2 extends Sensor {
}

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

Apakah saya gila karena berpikir ini adalah ide yang bagus? Apakah ada pola pembersih yang benar-benar hilang di sini?

Seperti yang tertulis (yang mungkin terlalu disederhanakan) kedengarannya seperti Sensor semua sama dalam perilaku umum, tetapi Parameter untuk kalibrasi berbeda.

Jika ini adalah satu-satunya perbedaan, dan Anda menggunakan bahasa dengan generik, seperti Java (digunakan di bawah), Anda bisa membuat kelas dengan Parameter, seperti:

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

   abstract public void calibrated(CalibrationParameters parameters);
}

lalu sekelompok

public class SensorN extends Sensor<CalibrationParametersForSensorN> {

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

}

Peringatan: diketik tanpa IDE sehingga mungkin ada kesalahan ketik atau kesalahan ...

ps Setuju dengan Robert bahwa nama yang lebih baik adalah, er, lebih baik. Jadi implementasi konkret yang lebih baik adalah:

public class Thermometer extends Sensor<ThermometerCalibration> {

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

}

Tidak jika nama deskriptif terbaik untuk sensor ini adalah Sensor1, Sensor2dan Sensor3. Angka-angka tidak menunjukkan karakteristik pembeda antara sensor.

Jika kelas yang berbeda menunjukkan jenis sensor yang berbeda, maka kelas yang berbeda mungkin diperlukan. Inilah sebabnya kami terkadang menyebut kelas sebagai tipe, meskipun kata "tipe" itu sendiri memiliki arti yang lebih luas.

PressureSensor extends Sensor
TemperatureSensor extends Sensor

Saya tidak yakin apakah kalibrasi harus menjadi tanggung jawab sensor ... Saya akan mempertimbangkan membuat 2 kelas baru. Sesuatu seperti SensorCalibratorBase, SensorCalibratorAdavanced. Kemudian, saya akan membuat instance spesifik dari kalibrator berdasarkan status aplikasi dan memberi makan instance sensor untuk fungsi Calibrate-nya. Setiap kalibrator akan mendapatkan params yang dibutuhkan sebagai argumen konstruktor.