Jaki jest lepszy sposób na wywołanie metody, która jest dostępna tylko dla jednej klasy, która implementuje interfejs, ale nie dla drugiej?

Zasadniczo muszę wykonywać różne działania, biorąc pod uwagę określony warunek. Istniejący kod jest zapisywany w ten sposób

Interfejs podstawowy

// DoSomething.java
interface DoSomething {

   void letDoIt(String info);
}

Wdrożenie pierwszej klasy robotniczej

class DoItThisWay implements DoSomething {
  ...
}

Wdrożenie drugiej klasy robotniczej

class DoItThatWay implements DoSomething {
   ...
}

Główna klasa

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

Ten kod działa dobrze i jest łatwy do zrozumienia.

Teraz, ze względu na nowy wymóg, muszę przekazać nową informację, która ma sens DoItThisWay.

Moje pytanie brzmi: czy następujący styl kodowania jest dobry, aby poradzić sobie z tym wymogiem.

Użyj nowej zmiennej klasy i metody

// 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 {
     ...
   }
 } ;

}

Jeśli zrobię to w ten sposób, muszę wprowadzić odpowiednią zmianę do osoby dzwoniącej:

   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)
     }

Czy to dobry styl kodowania? Czy mogę to po prostu rzucić

   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)
     }

Zakładam, że to qualitymusi być ustawione obok każdego letDoIt()połączenia na DoItThisWay().

Problem widzę wynikające tutaj jest taka: Ty wprowadzamy sprzęgło czasowej (czyli co happends jeśli zapomnisz zadzwonić setQuality()przed wywołaniem letDoIt()na zasadzie DoItThisWay?). A implementacje są rozbieżne DoItThisWayi DoItThatWayrozbieżne (jedno trzeba setQuality()zadzwonić, drugie nie).

Chociaż może to nie powodować problemów w tej chwili, może w końcu cię prześladować. Warto spojrzeć jeszcze raz letDoIt()i zastanowić się, czy informacje jakościowe mogą być częścią infoprzekazywanej przez ciebie informacji; ale to zależy od szczegółów.

Czy to dobry styl kodowania?

Z mojego punktu widzenia żadna z twoich wersji nie jest. Najpierw trzeba zadzwonić, setQualityzanim letDoItbędzie można go wywołać, to połączenie czasowe . Utkniesz oglądanie DoItThisWayjako pochodna DoSomething, ale to nie jest (przynajmniej nie funkcjonalnie), to raczej coś w rodzaju

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

To by było Mainraczej coś w rodzaju

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);
        }
    }
}

Z drugiej strony możesz przekazać parametry bezpośrednio do klas (zakładając, że jest to możliwe) i przekazać decyzję, której z nich użyć do fabryki (sprawiłoby to, że instancje byłyby wymienne i oba można wyprowadzić DoSomething). To by Mainwyglądało tak

class Main {
    private DoSomethingFactory doSomethingFactory;

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

Wiem, że to napisałeś

ponieważ ze względu na wydajność konstrukcja DoItThisWay i DoItThatWay odbywa się raz w konstruktorze Main

Ale możesz buforować części, które są kosztowne do wytworzenia w fabryce i przekazać je również konstruktorowi.

Załóżmy, że qualitynie można przekazać do konstruktora, a wywołanie setQualityjest wymagane.

Obecnie fragment kodu podobny do

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

jest o wiele za mały, aby zainwestować w niego zbyt wiele myśli. IMHO wygląda trochę brzydko, ale nie bardzo trudno zrozumieć.

Problemy pojawiają się, gdy taki fragment kodu rośnie, a po refaktoryzacji powstaje coś takiego

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

Teraz nie widzisz od razu, czy ten kod jest nadal poprawny, a kompilator ci nie powie. Tak więc wprowadzenie tymczasowej zmiennej właściwego typu i unikanie rzutowania jest nieco bardziej bezpieczne dla typu, bez żadnego dodatkowego wysiłku.

Jednak tak naprawdę dałbym tmplepszą nazwę:

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

Takie nazewnictwo pomaga sprawić, że zły kod wygląda źle.

Wspólny interfejs, w którym inicjalizacja różni się w zależności od danych wykonawczych, zwykle nadaje się do wzorca fabrycznego.

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

doSomething.letDoIt();

Następnie DoThingsFactory może martwić się uzyskaniem i ustawieniem informacji o jakości wewnątrz getDoer(info)metody przed zwróceniem konkretnego obiektu DoThingsWithQuality rzutowanego do interfejsu DoSomething.