Question

我一直在探索向以前由“经理”或“控制器”处理的对象添加功能的便利性。我只是担心是否有任何问题以这种方式工作。我可以看到的主要问题是耦合。

作为一个例子，让我们用一个公司解雇一个雇员。

以前，我会这样工作：

class Employee
{
    // Does employee stuff
}

class Business
{
    public List<Employee> employees
}

class BusinessManagement
{
    Business buisness
    public void FireEmployee(Employee employee)
    {
        business.employees.Remove(employee);
    }
}

现在我一直在尝试：

class Employee
{
    Business business
    Fire()
    {
        business.employees.Remove(this);
    }
}

class Business
{
    public List<Employee> employees
}

后一种方法既方便又方便，因为您只需要引用该雇员，就可以在任何需要的地方解雇该雇员。您也不需要管理类。

Answer 1

我认为您担心在这里避免耦合是正确的–我认为您的示例是不好的做法。但是，让我们解压缩，并展示一种方法，使我们可以通过更易于理解，可预测和可维护的类之间的契约来实现相同的行为。

一家企业有很多员工，它知道自己雇用的人-因此拥有对Employee对象的引用集合是有意义的。员工（为简单起见）为一家公司工作，因此Employee包含对Business对象的引用是有意义的。这些引用不一定会否定地将这些类耦合在一起，只要它们之间的契约在每个对象的调用均受该类控制且其业务逻辑是该类所关注的每个对象上明确地处于公共方法中即可。

企业解雇了一名雇员，而雇员还需要知道他们被解雇了。如果要执行此操作，请将Fire(Employee e)方法放在Business类上-在此方法内，我很可能想调用e.GetFired()然后从集合中删除该员工员工。然后，Employee.GetFired()会将Employee自己的Business属性设置为null。

这可以双向工作，同时保持这些类之间的分隔。员工大概可以辞职-因此，Employee.Quit()可以打电话给Business.EmployeeHasQuit(Employee e)，将自己作为参考传递给他人-允许Business实例自行承担删除{{1 }}集合中的实例。

您的示例是耦合的示例，因为Employee类的Employee方法使用它对Business对象的引用来访问公共集合并删除自身。如果GetFired()方法设置为Business.Fire(Employee e)，它也将是耦合的。一个合理的经验法则是，类不应直接修改其他类的成员。通过让每个类管理自己的状态，您可以实现行为以确保事物始终处于有效状态，并触发其他必要的行为（例如，我们要确保当Employee辞职时，其安全通行证被撤销，并且这可能会在e.Business = null内部发生–如果员工只是将自己从“企业”集合中删除，情况并非如此，企业可能还希望有机会将已辞职或被解雇的员工纳入“前雇员”集合中，以便以后跟踪它们。

希望这是一个易于理解的示例，说明了对象之间相互通信的方式，同时又对自己的状态和行为承担全部责任！

让“经理”对一个对象做某事或让对象自己做某事的利弊是什么？

1 个答案: