以-able結尾的接口中的方法命名約定

Question

所以說我有一個Opener類或接口（沒關系），它有一個方法public open(Openable<T> item) 。 Bag ， Window ， Door實現Openable接口，因為它們都可以打開。

問題：我應該如何在Openable界面中命名方法？ 如果我的名字是void open()那么這將意味着這是所有的對象Openable可以打開，這是不正確的，只有Opener可開Openable對象。

Answer 1

我將其命名為void openWithOpener() 。 這樣，您就不必綁定到一個Opener並且避免暗示Openable對象可以自行打開。

Answer 2

接口是合同。 如果一個類實現一個接口，則意味着該類完全支持該接口中聲明的所有操作。 （盡管並非總是如此）。 關於標題中的聲明：通常，所有名稱以“ -able”結尾的接口都將該類標記為能夠執行某些操作。 例如：Runnable- run() ，Executable- execute() ，Comparable- compareTo()等。

一種）

public interface Openable {
    void open();
}

上面的接口確實暗示着實現它的任何類都可以打開，而不管調用上下文如何。 它並不一定意味着該對象將打開，但這不是重點。

考慮@ sgj88_提出的以下內容：

B）

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

由於您聲明只有Opener可以打開Openable對象，因此從理論上講，這是一個更好的選擇。 （理想情況下，對象只應更改自己的內部結構，而不能更改其他對象）。 但是，實際上， Opener行為就像是改變行為的對象，類似於策略模式。

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

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

這樣做的原因是， Opener對Openable的內部Openable以更改其狀態，而顧名思義，它卻知道。 您將在Opener沒有open() ，因為這樣一來您就不需要Opener 。 因此，設計和實現的語義不匹配。

C）

由於只有Opener類型可以打開它們，因此可以假設有多種方法可以修改Openable的狀態，而不僅僅是對open()的單個調用。 然后， Openable需要更多的方法來修改其內部狀態，例如

setOpenRate(), setOpenFraction()等。

如果不是這種情況，並且問題涉及調用權限，即只有一個類Opener在其中使用open() ，則它不應該是接口。

考慮到在某種程度上設計接口的環境，可能有助於確定最佳選擇。