In Java, what is the purpose of calling interface methods on objects from other classes?

Asked

Viewed 116 times

2

Follow the code I’m studying:

public interface Node {
    public abstract int eval ();
}

public abstract class Unary implements Node {
    private final Node child;

    public Unary(final Node child) {
        this.child = child;
    }

    public final int eval () {
        return compute(child.eval());
    }
    protected abstract int compute(int c);
}

public abstract class Binary implements Node {
    private final Node left;
    private final Node right;

    public Binary(final Node left, final Node right) {
        this.left = left;
        this.right = right;
    }

    public final int eval() {
        return compute(left.eval(), right.eval());  // minha dúvida aqui, porque left.eval() 
                                                    // ao invés de só left?
    }

    protected abstract int compute(int l, int r);
}

My question is, to the class Binary, in the method eval () when he returns compute(left.eval(), right.eval()), because the variables left and right are followed by the method eval() interface? whereas interface methods do nothing.

java pattern-design interface
  • 1

    They "do nothing" on the interface Node. But if you pass an object that implements the interface Node, and creates an implementation for the method eval, it will return (or must return) an integer.

  • Related: https://answall.com/q/2913/112052

2 answers

4


Design pattern

This looks like a design pattern, I don’t guarantee exactly which one because some are similar and aren’t always implemented right (it looks like a Strategy). Even though it is not any of the best known yet it is one that has a purpose. It seems to use more than one Pattern design.

This form of abstraction allows the flexibility to work with objects that are us without worrying about details of how the nodes will give you the information about them that an algorithm needs. The only thing you need to know about the knots is that it has a method eval() that gives you the necessary information.

The concrete implementations of Node will have a code on this eval() which says that information is relevant to identifying what it represents, but which specifically is just seeing each other’s code (we are seeing two quasi-implementations, at least the method is implemented, but as they are not concrete classes yet will not be in these classes that will actually be used).

When you call the method and each of the object fields is just taking this information. It is only known that it will return an integer value.

And we can observe that it will be used in a method that knows nothing about these nodes, it could receive anything, and that only in concrete classes will have exactly how to compute it.

Interface

The goal of the interface is precisely to give a contract, a form that an object will have if it decides to conform to it, then everyone who receives an object of this interface will be able to do that, and only that, that the interface said that it is capable.

Note that the fields child, left and right are of the interface type, can contain objects of any type that implements them, it does not care for the rest of what this object is or does, only for what the interface determined.

1

The method eval() (which means evaluate, i.e., evaluate) the interface Node really does nothing because it’s just a contract. It’s there to force whoever implements this interface to implement this method.

But the classes Unary and Binary that are implementing this interface are abstract (abstract). This means that they are not required to implement this method, and delegate this task to those who are subclass concrete (non-exotic) of these classes.

So if you have class Concreta extends Binary { ... }, for example, it will be required to implement eval().

Browser other questions tagged java pattern-design interface

You are not signed in. Login or sign up in order to post.