.Net 设计的优点/缺点：相互引用的对象与。事件？答案

【问题标题】：.Net Design Pros/Cons: Objects Referencing Each Other Vs. Events?.Net 设计的优点/缺点：相互引用的对象与。事件？
【发布时间】：2012-12-24 02:51:48
【问题描述】：

TruckStop 有一个 List(of TruckClass) 和一个名为 Weigh() 的方法。 TruckClass 需要调用 Weigh()。以下两种设计的优缺点是什么？ TruckClass 具有对 TruckStopClass 的引用并调用 MyTruckStopClassReference.Weigh() 与。 TruckClass 引发由 TruckStopClass 处理的 TruckClass.Weigh 事件。

我已经读过，相互引用的对象不会影响 GC，但它需要每个 TruckClass 中的额外引用。在硬币的另一面，我读到事件处理程序也是引用，如果你不解开它们可能会导致问题。对此事的利弊/最佳实践/意见进行一点澄清或评论将不胜感激。

【问题讨论】：

我假设您只有一个带有一台或多台秤和许多卡车的卡车停靠站。尽可能坚持现实 - 卡车停靠站管理秤，因此您的 TruckStop 类必须在卡车上调用 GetWeigh()。你不能反过来，因为卡车不知道是否有可用的秤，或者知道是否不是他们的工作
Truck/TruckStop 是一个虚构的例子。更不用说卡车司机可以在决定称重之前先获得燃料。在“子类”必须触发“父类”的某些方法调用的情况下，我更关心对象相互引用与对象引发事件的优缺点。
一个缺点是孩子在不需要的时候与父母耦合。他们有单独的责任，应该这样对待。在这一点上讨论垃圾收集器是多余的......
先生。 Whitehead，您是说 Truck 对象中的 TruckStop 引用是由于耦合或两种情况导致的 Con？
与问题无关。我曾经有过这种情况。添加它们时，每个对象都会引用列表。尝试将同一个对象放入两个不同的列表时遇到了奇怪的问题。

标签： .net vb.net oop

【解决方案1】：

就这两种方法而言，我更倾向于倾向于这两个类是独立的，而不是被事件/处理程序捆绑在一起。在这个理论案例中，我会将称重函数放在模块内或卡车停靠站类的共享函数中，并将卡车作为参数。

如果您打算走事件路线，那么让一个班级处理在单独班级中引发的事件并不是一种非常可取的做事方式。在我个人看来，如果我这样做了，我会觉得很肮脏，因为这会导致两个类紧密耦合，至少会让人觉得你在扼杀 OOP 设计。

过去我在处理可以从多个位置调用相同表单的程序时合并表单初始化所做的事情是让所有可以启动表单的可能位置将事件引发到一个公共容器，无论它是基本表单或容器类或类似的东西，然后在该父表单/类/容器上，我处理来自所有子级的每个事件。这样做的好处是您可以让一个调用表单初始化程序的子过程（或函数，但是您想定义它）处理所有事件，并且如果您需要更改表单的创建方式并将其全部显示在一处。

此示例与您的示例并不严格相关，但如果您稍微更改示例并说两个类都可以导致某些车辆被称重，那么将接入点集中到卡车停靠站的称重功能将使项目管理变得简单容易多了。

【讨论】：

感谢您的回答。作为后续，这是否意味着 Form/Button 关系也是 OOP 设计的屠宰？ Button 是 Form 的 Controls 属性的一部分，会引发 Click 等事件，但它是一个单独的类。
@NoAlias：我一直认为任何控件和父表单都是一种特殊情况，但是当您退后一步将它们视为独立类时，它确实符合模式。我会说当引发事件的类依赖取决于处理事件的类时，这条线就画好了。因此，对于按钮和表单，它们将通过 OOP 测试，因为按钮不关心是否有任何东西在监听单击，无论何时单击它都会触发它。因此，如果它不依赖于监听它的东西，那么在“卡车”中引发事件不会是坏事。

【解决方案2】：

我的解决方案是在 TruckStop 类中同时包含 TruckClass 和 Weigh() 方法。比如：

Class TruckStop
    Class Truck
        (private attributes)
        (public properties)
    End Class

    Public Shared Function Weigh(truck) as Weight
        (code)
    End Function
End Class

并像这样引用：

weight = thisTruckStop.weigh(thisTruckStop.Truck(truckNum))

【讨论】：