对象图或单个属性作为方法参数？答案

【问题标题】：Object graph or individual properties as method parameters?对象图或单个属性作为方法参数？
【发布时间】：2014-06-30 16:20:57
【问题描述】：

假设我有一个非常深的对象图，作为一个简化的例子，像这样

class Car {
    Engine Engine { get; set; }
    Dashboard Dashboard { get; set; }
    IEnumerable<Wheel> Wheels { get; set; }
}

class Engine {
    Pump FuelPump { get; set; }
    Motor StarterMotor { get; set; }
}

为了这个例子，我想要一个负责执行此操作的 CarStarter，而不是 Car 具有 Start() 方法。想象一下 Car 可以是一个大的、深度嵌套的对象图，而 CarStarter 只需要访问几个属性，其中一些属性有几个层次。我应该将 Car 对象传递给 CarStarter，还是只传递重要的属性？那么在我的简化示例中有哪些重载？

class CarStarter {
    void Start(Car car) {
        car.Dashboard.Lights.SwitchOn();
        car.Engine.FuelPump.Run();
        car.Engine.StarterMotor.Start();
    }

    void Start(Dashboard dashboard, Pump fuelPump, Motor starterMotor) {
        dashboard.Lights.SwitchOn();
        fuelPump.Run();
        starterMotor.Start();
    }
}

前者感觉不对，因为它要求 CarStarter 深入了解 Car 类的整个嵌套结构的结构及其属性。在单元测试中传递给 CarStarter 时，需要填充 Car 对象的哪些属性也有点不透明。

对我来说，后者似乎是更好的选择，但有可能导致参数过多。

【问题讨论】：

标签： design-patterns

【解决方案1】：

我们可以在这里创建一个参数对象：http://sourcemaking.com/refactoring/introduce-parameter-object

【讨论】：

感谢您的建议。这是一种有趣的看待它的方式。我几乎是从相反的方向来的——在这种情况下，参数列表不会太长；太短了。我们正在传递一个已经可以访问其他所有内容的对象，但这依赖于使用这种方法的每个方法都对这个“参数对象”的结构有深入的了解。

【解决方案2】：

我缺少的关键短语是Law of Demeter。我很确定这个问题属于Inappropriate Intimacy 代码异味的普遍支持，但被违反的确切“规则”似乎是得墨忒耳定律或最少知识原则。

【讨论】：