Có phải thực tế xấu khi tạo một lớp con trong tên chỉ để dễ đọc?

Tôi có ba cảm biến trong một gói duy nhất mà tất cả cần phải được hiệu chỉnh mà tôi sẽ gọi là Sens1, Sens2 và Sens3. Hiệu chuẩn cho Sens1 và Sens2 giống hệt nhau, nhưng hiệu chuẩn cho Sens3 yêu cầu thêm một tham số. Câu hỏi của tôi là "Cách tốt nhất để đối phó với ba đối tượng gần giống nhau trong khi vẫn duy trì khả năng đọc là gì?"

Tất nhiên, suy nghĩ đầu tiên của tôi là sử dụng đa hình. Tôi sẽ thiết lập một đối tượng Cảm biến chung bằng phương thức .calibrate (Tham số tham số) trong đó lớp Tham số cho phép tôi thay đổi số lượng tham số dựa trên hiệu chuẩn mà tôi đang thực hiện. Tuy nhiên, điều này dẫn đến những điều sau đây:

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

Vì vậy, những người trong tương lai sẽ cần phải biết rằng một cảm biến khác về cơ bản so với hai cảm biến kia, nhưng rất giống nhau, đối với tôi, điều tốt nhất để làm là chỉ phân loại tên Sens1 và Sens2. Nói cách khác, tạo hai lớp con không sửa đổi hoặc mở rộng bất kỳ hành vi nào để có tên lớp logic hơn. Hãy nhớ rằng, cả ba cảm biến này đều nằm trong cùng một gói, vì vậy dữ liệu này rất thường xuyên đi cùng nhau. Điều này thay đổi mã trên thành:

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

Ở đâu

Sensor1 extends Sensor {
}

Sensor2 extends Sensor {
}

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

Tôi có điên không khi nghĩ rằng đây là một ý tưởng tốt? Có một mô hình sạch hơn tôi hoàn toàn thiếu ở đây?

Khi được viết (có thể được đơn giản hóa), có vẻ như các Cảm biến đều giống nhau trong hành vi chung, nhưng các Thông số để hiệu chuẩn là khác nhau.

Nếu đây là sự khác biệt duy nhất và bạn đang sử dụng một ngôn ngữ có tính tổng quát, chẳng hạn như Java (được sử dụng bên dưới), bạn có thể tạo ra lớp theo các Tham số, đại loại như:

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

   abstract public void calibrated(CalibrationParameters parameters);
}

sau đó là một loạt

public class SensorN extends Sensor<CalibrationParametersForSensorN> {

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

}

Hãy cẩn thận: được gõ mà không có IDE nên có thể có lỗi chính tả hoặc lỗi ...

ps Đồng ý với Robert rằng những cái tên tốt hơn sẽ là, er, tốt hơn. Vì vậy, một triển khai cụ thể tốt hơn sẽ là:

public class Thermometer extends Sensor<ThermometerCalibration> {

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

}

Không phải nếu tên mô tả tốt nhất cho các cảm biến này là Sensor1, Sensor2và Sensor3. Các con số không chỉ ra bất kỳ đặc điểm phân biệt giữa các cảm biến.

Nếu các lớp khác nhau biểu thị các loại cảm biến khác nhau , thì các lớp khác nhau có thể được bảo hành. Đây là lý do tại sao đôi khi chúng ta gọi các lớp là các loại, mặc dù bản thân từ "loại" có nghĩa rộng hơn.

PressureSensor extends Sensor
TemperatureSensor extends Sensor

Tôi không chắc việc hiệu chuẩn có phải là trách nhiệm của cảm biến không ... Tôi sẽ xem xét việc tạo 2 lớp mới. Một cái gì đó như SensorCalibratorBase, SensorCalibratorAdavified. Sau đó, tôi sẽ tạo một phiên bản cụ thể của bộ hiệu chuẩn dựa trên trạng thái ứng dụng và đưa đối tượng cảm biến vào chức năng Hiệu chỉnh. Mỗi bộ hiệu chuẩn sẽ lấy các tham số cần thiết làm đối số của hàm tạo.