これはDemeterの法則に違反していますか？対読可能なコード

Question

以下のコードは明らかにDemeterの法則、すなわちgetServer().methodx(...)の方法を制止しています。反対側から見ると、かなりコンパクトに見えますが、より読みやすくなりますか？

abstract class BaseManager { 
    ResultSet find(String searchText) { 
     return getServer().find(searchText); 
    } 

    ResultSet fetch(String fetchText) { 
     return getServer().fetch(fetchText); 
    } 

    void save(String saveText) { 
     getServer().save(saveText); 
    } 

    abstract BaseManager getServer(); 
} 

class Server1Manager extends BaseManager { 
    @Override 
    protected BaseManager getServer() { 
     return server1; 
    } 
} 

class Server2Manager extends BaseManager { 
    @Override 
    protected BaseManager getServer() { 
     return server2; 
    } 
} 

法律に違反すると、このコードをどのようにリファクタリングするのですか？ 事前に感謝します。

Answer 1

明らかに、デメテルの法則、つまり のメソッドgetServer（）。methodx（...）のコードは次のようになります。他の側からそれはかなり見える コンパクト=より読みやすい？

あなたのデザインのポイントは私には分かりません。コンパクトさがあなたの目標ならば、これはもっと良くないでしょうか？

class Manager { 
    private Server server; 

    public Manager(Server server) { 
     this.server = server; 
    } 

    ResultSet find(String searchText) { 
     server.find(searchText); 
    } 

    ResultSet fetch(String fetchText) { 
     server.fetch(fetchText); 
    } 

    void save(String saveText) { 
     server.save(saveText); 
    } 
} 

さらにコンパクトで明瞭であることに加えて、それはDemeterの法則に従うことになります。さらに、それは相続よりも組成を好むという原則に従う。これはデメテルの法則によって支持されると思われる（しかし暗示されない）。

法律に違反すると、このコードをどのようにリファクタリングするのですか？

私はまだ私が上に示したものが好きです。

（それがコード 重複ようには見えません）許容 次のソリューションです？：[...]

あなたがコードレビューのために私にそれを提示した場合、私は確かに尋ねますあなたがそこで継承されて得たと思うもの。あなたのコードが技術的に重複しているかどうかについて少し議論するかもしれませんが、私が提示した非継承バージョンよりもずっと長く複雑です。そして、継承されていないバージョンでは、コードの重複について疑問はありません。

Answer 2

私にとっては、マネージャーで3つのメソッドを実装した方がずっと良いです。

両方のサーバーのメソッドを公開する1つのデータマネージャーを持つことができます。

私が好きな別のルールがあります：質問しないでください -を教えてください。