Method naming conventions in interfaces ending with -able

Question

So let's say I have an Opener class or interface (doesn't matter), which has a method public open(Openable<T> item). A Bag, Window, Door implements Openable interface, because all of them can be opened.

Question: how should I name method in Openable interface? If I name it void open() then this will imply that all objects which are Openable can open, which is not true, only Opener can open Openable objects.

Answer 1

An interface is a contract. If a class implements an interface, this means that the class fully supports all operations stated in the interface. (Although this is not always the case). Regarding the statement in the title: generally all interfaces whose names end with "-able" mark the class as being able to do something. Examples: Runnable - run(), Executable - execute(), Comparable - compareTo(), etc.

A)

public interface Openable {
    void open();
}

The above interface does indeed imply that any class implementing it can be opened, irrespective of the call context. It does not necessarily mean that the object will open, but that is not the point.

Consider the following, as proposed by @sgj88_:

B)

public interface Openable {
    void open(Opener opener);
}

Since you state that only Opener can open Openable objects, theoretically this is a better option. (Ideally, objects should only change their own internals not other objects'). However, in practice Opener acts like a behaviour altering object, akin to the strategy pattern.

public interface Opener {
    // or something similar
    double fractionToOpen();

    Opener FULL_OPENER = () -> 1.0;
    Opener HALF_OPENER = () -> 0.5;
}

The reason for this is that Opener does not know anything about the internals of Openable in order to change its state, while the name suggests that it does. You wouldn't have open() in Opener because then you wouldn't need Opener in the first place. Hence the semantics of design and implementation do not match.

C)

Since only Opener type can open them then it can be assumed that there are more ways to modify the state of Openable than just a single call to open(). Then, Openable needs more methods for modifying its internal state,e.g.

setOpenRate(), setOpenFraction(), etc.

If this is not the case and the question refers to the call privileges, i.e. there is just a single class Opener in which open() can be used, then it shouldn't be an interface.

Perhaps given some context in which the interface is being designed would help to identify the best option.

Answer 2

I would name it void openWithOpener(). That way you're not tied to one Opener and you avoid implying that Openable objects can open themselves.