Mana cara yang lebih baik untuk memanggil metode yang hanya tersedia untuk satu kelas yang mengimplementasikan antarmuka tetapi tidak yang lain?

Pada dasarnya saya perlu melakukan tindakan yang berbeda dengan syarat tertentu. Kode yang ada ditulis dengan cara ini

Antarmuka dasar

// DoSomething.java
interface DoSomething {

   void letDoIt(String info);
}

Implementasi kelas pekerja pertama

class DoItThisWay implements DoSomething {
  ...
}

Implementasi kelas pekerja kedua

class DoItThatWay implements DoSomething {
   ...
}

Kelas utama

   class Main {
     public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
          worker = new DoItThisWay();
        } else {
          worker = new DoItThatWay();
        }
        worker.letDoIt(info)
     }

Kode ini berfungsi dengan baik dan mudah dimengerti.

Sekarang, karena persyaratan baru, saya perlu memberikan informasi baru yang masuk akal DoItThisWay.

Pertanyaan saya adalah: apakah gaya pengkodean berikut baik untuk menangani persyaratan ini.

Gunakan variabel dan metode kelas baru

// Use new class variable and method

class DoItThisWay implements DoSomething {
  private int quality;
  DoSomething() {
    quality = 0;
  }

  public void setQuality(int quality) {
    this.quality = quality;
  };

 public void letDoIt(String info) {
   if (quality > 50) { // make use of the new information
     ...
   } else {
     ...
   }
 } ;

}

Jika saya melakukannya dengan cara ini, saya perlu membuat perubahan yang sesuai dengan penelepon:

   class Main {
     public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
          int quality = obtainQualityInfo();
          DoItThisWay tmp = new DoItThisWay();
          tmp.setQuality(quality)
          worker = tmp;

        } else {
          worker = new DoItThatWay();
        }
        worker.letDoIt(info)
     }

Apakah ini gaya pengkodean yang baik? Atau bisakah saya melemparkannya saja

   class Main {
     public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
          int quality = obtainQualityInfo();
          worker = new DoItThisWay();
          ((DoItThisWay) worker).setQuality(quality)
        } else {
          worker = new DoItThatWay();
        }
        worker.letDoIt(info)
     }

Saya berasumsi bahwa qualityperlu diatur di samping setiap letDoIt()panggilan pada a DoItThisWay().

Masalah yang saya lihat timbul di sini adalah ini: Anda memperkenalkan penggabungan sementara (yaitu apa yang terjadi jika Anda lupa menelepon setQuality()sebelum memanggil letDoIt()a DoItThisWay?). Dan implementasi untuk DoItThisWaydan DoItThatWayberbeda (yang satu perlu setQuality()menelepon, yang lain tidak).

Meskipun ini mungkin tidak menyebabkan masalah sekarang, itu mungkin kembali menghantui Anda pada akhirnya. Mungkin bermanfaat untuk melihat kembali letDoIt()dan mempertimbangkan apakah informasi berkualitas mungkin perlu menjadi bagian dari infoAnda melewatinya; tapi ini tergantung dari detailnya.

Apakah ini gaya pengkodean yang baik?

Dari sudut pandang saya tidak ada versi Anda. Pertama yang harus dihubungi setQualitysebelum letDoItdapat dipanggil adalah temporal coupling . Anda buntu melihat DoItThisWaysebagai turunan dari DoSomething, tetapi tidak (setidaknya tidak secara fungsional), itu agak seperti

interface DoSomethingWithQuality {
   void letDoIt(String info, int quality);
}

Ini akan membuat Mainsesuatu seperti

class Main {
    // omitting the creation
    private DoSomething doSomething;
    private DoSomethingWithQuality doSomethingWithQuality;

    public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
            int quality = obtainQualityInfo();
            doSomethingWithQuality.letDoIt(info, quality);
        } else {
            doSomething.letDoIt(info);
        }
    }
}

Di lain pihak, Anda dapat meneruskan parameter ke kelas secara langsung (dengan asumsi ini mungkin) dan mendelegasikan keputusan yang akan digunakan untuk pabrik (ini akan membuat instance dipertukarkan lagi dan keduanya dapat diturunkan dari DoSomething). Ini akan membuat Mainterlihat seperti ini

class Main {
    private DoSomethingFactory doSomethingFactory;

     public doingIt(String info) {
         int quality = obtainQualityInfo();
         DoSomething doSomethingWorker = doSomethingFactory.Create(info, quality);
         doSomethingWorker.letDoIt();
     }
}

Saya sadar Anda yang menulisnya

karena untuk alasan kinerja pembangunan DoItThisWay dan DoItThatWay dilakukan sekali dalam konstruktor Main

Tapi Anda bisa menyimpan bagian yang mahal untuk dibuat di pabrik dan mengirimkannya ke konstruktor juga.

Mari kita asumsikan qualitytidak dapat diteruskan ke konstruktor, dan panggilan ke setQualitydiperlukan.

Saat ini, potongan kode suka

    int quality = obtainQualityInfo();
    worker = new DoItThisWay();
    ((DoItThisWay) worker).setQuality(quality);

terlalu kecil untuk menanamkan terlalu banyak pikiran ke dalamnya. IMHO itu terlihat agak jelek, tetapi tidak terlalu sulit untuk dipahami.

Masalah muncul ketika potongan kode seperti itu tumbuh dan karena refactoring Anda berakhir dengan sesuatu seperti

    int quality = obtainQualityInfo();
    worker = CreateAWorkerForThisInfo();
    ((DoItThisWay) worker).setQuality(quality);

Sekarang, Anda tidak segera melihat apakah kode itu masih benar, dan kompiler tidak akan memberi tahu Anda. Jadi, memperkenalkan variabel sementara dari jenis yang benar, dan menghindari gips, sedikit lebih aman, tanpa upaya ekstra yang nyata.

Namun, saya sebenarnya akan memberikan tmpnama yang lebih baik:

      int quality = obtainQualityInfo();
      DoItThisWay workerThisWay = new DoItThisWay();
      workerThisWay.setQuality(quality)
      worker = workerThisWay;

Penamaan tersebut membantu membuat kode yang salah terlihat salah.

Antarmuka umum di mana inisialisasi bervariasi berdasarkan data runtime biasanya cocok dengan pola pabrik.

DoThingsFactory factory = new DoThingsFactory(thingThatProvidesQuality);
DoSomething doSomething = factory.getDoer(info);

doSomething.letDoIt();

Kemudian DoThingsFactory dapat khawatir tentang mendapatkan dan mengatur informasi kualitas di dalam getDoer(info)metode sebelum mengembalikan objek DoThingsWithQuality yang asli dilemparkan ke antarmuka DoSomething.