隐式转换对象

下面的代码演示了我有时会看到的模式，其中一个对象在作为参数传递给多个方法调用时被隐式转换。隐式转换对象

var o = new MyReferenceType(); 
DoSomeWorkAndPossiblyModifyO(o); 
DoYetMoreWorkAndPossiblyFurtherModifyO(o); 

//now use o...

这对我来说是错误的（它几乎感觉不到面向对象）。可以接受吗？

来源

2010-02-02 Ben

你能澄清可以接受吗？你的意思是从语言角度还是从开发/设计角度？ – macabail 2010-02-02 22:49:15

我的意思是从开发/设计的角度来看。我想多年的面向对象设计让我更习惯于控制自己转换的对象。 – Ben 2010-02-02 23:20:45

这是可以接受但通常不好的风格。通常的“好”的做法是：

DoSomeWorkAndModify(&o); // explicit reference means we will be accepting changes 

o = DoSomeWorkAndReturnModified(o); // much more elastic because you often want to keep original.

您介绍的方法是有道理的，当o是巨大的，使得它的一个副本在内存中是毫无疑问的，或者如果它是一个函数，你（和其他人=私人）使用非常频繁，不想打扰&语法。否则，懒惰会导致一些真正难以检测到的错误。

来源

2010-02-03 09:20:12

谢谢 - 这很好地表达了我原来的想法。 – Ben 2010-02-03 10:27:34

它完全取决于方法实际上做了什么，除了修改该对象。例如，主要与在内存中保存某个状态有关的对象可能没有任何与在任何地方保持该状态相关的任何内容。

这些方法可以用于加载数据库中的数据，并用该信息更新对象。

但是！因为我编程主要是在C＃，因此.NET，这是一个完全面向对象的语言，我真的写你这样的代码：

var o = new MyReferenceType(); 
SomeOtherClass.DoSomeWorkAndPossiblyModifyO(o); 
SomeOtherClass.DoYetMoreWorkAndPossiblyFurtherModifyO(o); 

//now use o...

在这种情况下，其他类的实际名称（或与其他类如果有2个参与者）会给我一个关于实际发生的事情和/或上下文的大线索。

例子：

Person p = new Person(); 
DatabaseContext.FetchAllLazilyLoadedProperties(p); 
DatabaseContext.Save(p); // updates primary key property with new ID

来源

2010-02-02 22:51:49

根据您的方法名，我认为没有什么转型隐。这种模式是可以接受的。另一方面，如果您的方法的名称为printO(o)或compareTo(o)，但实际上修改了对象o，则设计会很糟糕。

来源

2010-02-02 23:01:48 akf

隐式转换对象

回答

相关问题