Which is the better way to call a method that is only available to one class that implements an interface but not the other one?

Question

Basically I need to execute different actions given a certain condition. The existing code is written this way

Base interface

// DoSomething.java
interface DoSomething {

   void letDoIt(String info);
}

Implementation of the first worker class

class DoItThisWay implements DoSomething {
  ...
}

Implementation of the second worker class

class DoItThatWay implements DoSomething {
   ...
}

The main class

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

This code works ok and is easy to understand.

Now, due to a new requirement, I need to pass a new piece of information that is only make sense to DoItThisWay.

My question is: does the following coding style good to handle this requirement.

Use new class variable and method

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

}

If I do it this way, I need to make the corresponding change to the caller:

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

Is it a good coding style? Or can I just cast it

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

Answer 1

I'm assuming that quality needs to be set alongside each letDoIt() call on a DoItThisWay().

The issue I see arising here is this: You are introducing temporal coupling (i.e. what happends if you forget to call setQuality() before calling letDoIt() on a DoItThisWay?). And the implementations for DoItThisWay and DoItThatWay are diverging (one needs to have setQuality() called, the other not).

While this might not cause issues right now, it may come back to haunt you eventually. It might be worthwhile to take another look at letDoIt() and consider if the quality information might need to be part of the info you pass through it; but this depends of the details.

Answer 2

Is it a good coding style?

From my point of view neither of your versions is. First having to call setQuality before letDoIt can be called is a temporal coupling. You're stuck viewing DoItThisWay as an derivative of DoSomething, but it isn't (at least not functionally), it's rather something like a

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

This would make Main rather something like

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

You could on the other hand pass the parameters to the classes directly (assuming this is possible) and delegate the decision which one to use to a factory (this would make the instances interchangeable again and both can be derived from DoSomething). This would make Main look like this

class Main {
    private DoSomethingFactory doSomethingFactory;

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

I am aware that you wrote that

because for performance reason the construction of DoItThisWay and DoItThatWay are done once in the constructor of Main

But you could cache the parts that are costly to create in the factory and pass them to the constructor, too.

Answer 3

Let's assume quality cannot be passed into the constructor, and the call to setQuality is required.

Currently, a code snippet like

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

is way too small to invest too much thoughts into it. IMHO it looks a little bit ugly, but not really hard to understand.

Problems arise when such a code snippet grows and due to refactoring you end up with something like

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

Now, you don't see immediately if that code is still correct, and the compiler won't tell you. So introducing a temporary variable of the correct type, and avoiding the cast, is a little bit more type-safe, without any real extra effort.

However, I would actually give tmp a better name:

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

Such naming helps to make wrong code look wrong.

Answer 4

A common interface where the initialization varies based on runtime data usually lends itself to the factory pattern.

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

doSomething.letDoIt();

Then DoThingsFactory can worry about getting and setting the quality information inside the getDoer(info) method prior to returning the concrete DoThingsWithQuality object cast to the DoSomething interface.