这是否违反得墨忒耳法则？与可读代码

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

对我来说，在管理器中实现了 3 个方法后会好很多。

您可以有 1 个数据管理器为两个服务器公开方法。

还有一条我喜欢的规则：不要问-告诉。

Answer 2

The code below brakes [sic] apparently the Law of Demeter, i.e. methods getServer().methodx(...). From other side it looks pretty compact = better readable?

我不明白你设计的重点。如果紧凑是您的目标，那么这不是更好吗？

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);
    }
}

除了更加简洁明了之外，恰好符合得墨忒耳法则。此外，它遵循优先组合而不是继承的原则，我认为您会看到得墨忒耳法则（但不是暗示）有利于这一点。

If the law is violated, them how to refactor this code?

我仍然喜欢上面介绍的内容。

Is the following solution acceptable (does it not look like a code duplication)?: [...]

如果您将其提交给我进行代码审查，我肯定会问您认为您从那里的继承中获得了什么。有人可能会争论您的代码是否在技术上是重复的，但它肯定比我提供的非继承版本更长、更复杂。并且非继承版本没有代码重复的问题。

这是否违反得墨忒耳法则？与可读代码

Is this a violation of the Law of Demeter? vs. readable code

java

law-of-demeter