4

Today I was thinking about a nice way to write less code for a common functionality that is required for different objects.

Inheritance can do the job but then the classes won't be able to inherit from anyone else, so I chose Interfaces.

So I have my interface with the functionality I will need for some objects:

public interface Test {
    String message = "Hello from Interface!";

    default void printMessage() {
        System.out.println(message);
    }
}

And then I can use it in any object without having to override/write any code more than just simply calling the method when needed:

public class TestingTest implements Test {

    public String message = "Hello from Class!";

    public TestingTest() {
        printMessage();
    }

    public static void main(String[] args) {
        new TestingTest();
    }
}

It works like a charm! But... Then I thought, what if I want some of those objects to specify a different message without being required (optional), well first thing I thought was to shadow the interface variable, but it doesn't work, the default method keeps using the variable from the interface instead of the class variable (which shadowed it).

A solution of course would be to overload the printMessage method in the interface so it recieves the message as a parameter for when the user requires to specify the message, but is there any more elegant way? Something like simply just declaring a new message in the class?

Donald Duck
  • 8,409
  • 22
  • 75
  • 99
Rafael R. S. Robles
  • 847
  • 7
  • 20
  • You could go for [reflection](http://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection), but this choice would be even worse then trying to shadow the variable, since it can lead to nasty bugs. – SomeJavaGuy Nov 03 '15 at 14:48
  • I agree with you, reflection should be the last resort! – Rafael R. S. Robles Nov 03 '15 at 14:49
  • 3
    What about creating a default `getMessage()` and override that? – Tunaki Nov 03 '15 at 14:54
  • You can make it an abstract class instead of an interface? Then you have a protected field you can overwrite. – Diego Martinoia Nov 03 '15 at 14:54
  • 2
    Even if the interface field was an instance field, this wouldn't work. Fields are not polymorphic. – Sotirios Delimanolis Nov 03 '15 at 14:54
  • 3
    You are abusing interfaces as namespaces. There is no real inheritance relationship between your interface and the “implementing” class. But your example is too far away from real life tasks to propose an alternative. If the method contains something more useful, there is nothing wrong with overloading but as long as you don’t use polymorphic behavior, just make the methods `static` and use `import static` to invoke them without a prefix. – Holger Nov 03 '15 at 15:30

2 Answers2

3

The String message in the interface is static (AFAIK). So that scheme does not work.

You might do something (ugly) as:

default void printMessage(String... messages) {
    if (messages.length == 0) {
        messages = new String[] { "arrgg" };
    }
    System.out.println(messages[0]);
}

Fields have no inheritance, so the value can only stem from an overridable method like

public String message() { return "..."; }
Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
0

What you want is a functionality in n classes that should also be modifiable, if needed. To be honest, your example is a little bit abstract and thus my answer will be abstract, too.

public interface Test {
    void printMessage();

    default void printMessage(String message) {
        System.out.println(message);
    }
}

public class TestingTest {
    private final test;

    public TestingTest(Test test) {
        this.test = test;
    }

    public void someMethod() {
        test.printMessage("Hello from class");
    }
}

Additionally, you would have a class that implements the interface and offers the message. This way you could group your objects, change the message, make more complex logging and you would actually see the dependency from outside.

In my opinion, you are misusing the interface. An interface offers public methods to call it from outside, but you want to use them inside like they were private functionalities for the class. Just use objects instead.

Shryne
  • 121
  • 5