类是否应该为其依赖项定义吸气剂？

如何解决类是否应该为其依赖项定义吸气剂？

比方说我有一辆带电机的课车。

类电动机的定义如下：

class Motor {
    private String code;
    
    public String getCode() {
        return code;
    }
}

假设我们需要从有权访问汽车的人那里访问电动机的代码，应该如何定义汽车类别？

class Car {
    private Motor motor;

    public Motor getMotor() {
        return motor;
    }
}

允许这样做的地方：

Car car = ...
Motor motor = car.getMotor();
String code = motor.getCode();

或

class Car {
    private Motor motor;

    public String getMotorCode() {
        return motor.getCode();
    }
}

允许这样做的地方：

Car car = ...
String code = car.getMotorCode();

我认为第二个选项是最好的，因为它遵循了Demeter定律，第一个则没有。另一方面，外部类应该从内部类中定义每个单独的getter吗？电机是否应该暴露在getMotor()下？

解决方法

是的，因为Motor将由自己使用，但如果需要保证自己的类，则不会将其Car括起来。如果不是，则Car类可以将String motorCode本身存储。假设Car是一个没有明显逻辑的复合模型，就像在示例中一样。

该示例的厌食类设计使其不清楚，但是在实际应用中，Motor类具有数十个自己的字段和复合类。 Car类不能为所有它们提供方法。

然后，Car类可能具有聚合来自不同组合字段的数据的方法，或者使一些经常使用的数据在没有长car.getMotor().getSomething().getData()链的情况下更易于访问。

具有相同的车辆电动机等。我们产品中的层次结构（尽管更全面），我知道在现实世界中的应用程序Motor将被单独处理。以及诸如Transmission，Tyres之类的潜在内容。因此，最终结果是一种混合方法，您可以在其中访问内部复合元素，因为有时需要使用它。对象图太大，不够有趣，无法进行大量设计，因此必须在封装和开发速度之间进行权衡。

car.getMotor().getCode()获胜。

为什么？

代码更少；您不必实施getMotorCode()
getMotorCode()违反了得墨meter耳定律（Demeter's Law）–汽车会知道并与之耦合，而马达具有什么场域。如果有一天有一台没有密码的电机怎么办？
getMotorCode()是一种方便的方法，几乎没有增加任何价值
getMotorCode()并不是编码人员希望找到汽车电动机代码的地方，而car.getMotor().getCode()是
getMotorCode()不是行业标准-暂时，我不记得看到像getMotorCode()这样的方法（而且我已经看到了很多的代码）

关于违反得墨meter耳定律，引用Wikipedia：

对象a可以请求对象实例b的服务（调用方法），但是对象a不应“通过”对象b来访问另一个对象c来请求其服务。这样做意味着对象a隐式需要对对象b的内部结构有更多的了解。

这恰好描述了getMotorCode()的作用。

我认为这很简单：Motor是可变的还是Motor包含一些应隐藏的信息（即：不向客户/呼叫者公开）？如果答案是是-只需不直接公开Motor，而只能通过允许的信息公开。

否则您将冒险：

供呼叫者更改Motor的内部（您可能不需要）
曝光过多（也许VIN可能并不对所有人可见）

@ Bohemian♦正确。 Java中的Getter和Setter用于提供返回数据的标准方法。以这种方式实施Motor：

public String getCode() {
    return "Code: " + code;
}

您的Car类是否需要知道如何返回代码？否
假设您在getMotorCode()中实现了Car，是否将复制如何返回代码？否
您更改了返回诸如return "C: " + code;之类的代码的方式，是否会更改已实现的诸如getMotorCode()之类的每个方法？否

car.getMotor().getCode()是标准，因为每个部分都管理工作。

我认为到目前为止，大多数答案都没有提到最重要的方面：您的班级应该始终努力提供服务，而不是 objects 。

只要您有一个返回对象的吸气剂，就迈出打破“告诉，不要问”的第一步。

告诉您的客户端代码执行某些操作（通过调用其他对象的服务），而不是强制客户端检索其他对象，然后根据此类对象的状态做出决定！

类是否应该为其依赖项定义吸气剂？

如何解决类是否应该为其依赖项定义吸气剂？

解决方法

相关推荐