Question

我习惯于创建类，这些类倾向于传递对象以对它们执行操作，而不是将它们分配给成员变量并且操作引用成员变量。对我来说，感觉比OO更具程序性。

这是一种可怕的做法吗？如果是这样，有什么不利影响（性能，内存消耗，更容易出错）？它是否更简单，更贴近OO原则，如封装，以支持成员变量？

我的意思的一个人为举例如下。我倾向于做以下事情;

public class MyObj()
{

  public MyObj() {}

  public void DoVariousThings(OtherObj oo)
  {
    if (Validate(oo))
    {
       Save(oo);
    }
  }

  private bool Validate(OtherObj oo)
  {
    // Do stuff related to validation
  }

  private bool Save(OtherObj oo)
  {
     // Do stuff related to saving
  }

}

虽然我怀疑我应该做以下事情;

public class MyObj()
{

  private OtherObj _oo;

  public MyObj(OtherObj oo) 
  {
    _oo = oo;
  }

  public void DoVariousThings()
  {
    if (Validate())
    {
       Save();
    }
  }

  private bool Validate()
  {
    // Do stuff related to validation with _oo
  }

  private bool Save()
  {
     // Do stuff related to saving with _oo
  }
}

Answer 1

如果用面向对象的语言编写程序，人们会期望面向对象的代码。因此，在您的第一个示例中，他们可能期望使oo成为参数的原因是您将始终使用不同的对象。在你的第二个例子中，他们知道你总是使用相同的实例（在构造函数中初始化）。

现在，如果您始终使用相同的对象，但仍然像第一个示例中那样编写代码，那么您将彻底混淆它们。当界面设计得很好时，应该明白如何使用它。在你的第一个例子中并非如此。

Answer 2

我认为你已经自己回答了你的问题，你似乎意识到第二种方法一般更有利，应该使用（除非有第一种方法有严重的原因）。

我立即想到的优点：

为您和他人提供简化的可读性和可维护性
只有一个入口点，因此只需要检查！= null等。
如果您想要对该类进行测试，那就更容易了，即获得类似的东西（从OtherObj中提取接口IOtherObj并使用它）：
```
public MyObj (IOtherObj oo)  
{
    if (oo == null) throw...
    _oo = oo;
}
```

Answer 3

谈到你的方式的不利影响，没有，但只有你自己保留程序和代码，你做什么不是一个标准的事情，比如说，如果过了一段时间，你开始为了制作可能被其他人使用的库和代码，那么这是一个大问题。可能会传递任何foo对象并希望它能够正常工作。

你必须在传递对象之前对其进行验证，如果验证失败，则做相应的事情，但是如果你使用标准的OOP方式，则无需验证或处理不合适的类型对象通过的情况，< / p>

简而言之，你的方式不利于：代码可重用性 2.你必须处理更多例外。好吧，如果你要保持自己的事情，否则，这不是一个好的做法。

希望，它有点怀疑。

传递对象而不是将它们指定为类的成员是否会产生不利影响

3 个答案: