OOP/OOD 耦合问题答案

【问题标题】：OOP/OOD Coupling questionOOP/OOD 耦合问题
【发布时间】：2010-10-21 19:45:25
【问题描述】：

我有一个函数可以返回给定期间的订单。我创建了一个 Period 对象，它确保在指定日期范围时，开始日期

我的问题是这样的：

我认为在面向对象设计原则中，耦合是不好的。我是否通过让 Order 类在其方法之一中使用 Period 类作为参数来引入 Order 和 Period 类之间的耦合？

我的猜测是肯定的，但是这样做有好处，即，一旦定义了对象，就不必在每次将句点作为参数传递给不同的方法时执行相同的参数验证检查。 Orders 类。

此外，Microsoft 不是经常将一种类型的非内在对象传递给其他对象吗？
对我来说，避免耦合听起来像是避免重用，而 OOP 应该促进这一点。这听起来像是相互竞争的目标。

谁能澄清一下。

Public Class Order

   Public Shared Function GetOrders(ByVal customerId As Integer,
                                    ByVal forPeriod As Period) As Orders

       **'Should the param object MonthPeriod be replaced with 2 date params?
       'Would I be "reducing coupling" by doing so, a good thing.**

   End Function

End Class

Public Class Period

    Property FromDate As Date
    Property ToDate As Date

    Public Sub New(ByVal fromDate As Date, ByVal toDate As Date)

        If fromDate > ToDate Then
            Throw New ArgumentException("fromDate must be less than Or equal toDate")
        End If

        _FromDate = fromDate
        _ToDate = toDate

    End Sub

End Class

Public Class MonthPeriod : Inherits Period


    Public Sub New(ByVal fromDate As Date, ByVal toDate As Date)

        MyBase.New(fromdate, toDate)

        If fromDate.Date <> New Date(fromDate.Year, fromDate.Month, 1) Then
            Throw New ArgumentException("fromDate must be the first day of the month")
        End If

        If toDate.Date <> New Date(toDate.Year, toDate.Month, Date.DaysInMonth(toDate.Year, toDate.Month)) Then
            Throw New ArgumentException("fromDate must be the last day of the month")
        End If

    End Sub

End Class

【问题讨论】：

标签： .net vb.net oop

【解决方案1】：

.Net 中的一切都是对象，但对象很少单独存在，因此类之间会有一定程度的耦合是的。您需要问的问题是类是紧耦合、有些耦合还是松耦合。紧密耦合的类构成了一个脆弱的体系结构，因为变化可能会对整个模型或系统产生连锁反应。随着时间的推移，课程的维护会变得越来越困难。使您的类更松散耦合往往会缓解其中一些问题。关于某事物是否松耦合（来自here）：

耦合是指的程度一类具有的直接知识其他。这并不意味着解释为封装 vs. 非封装。它不是一个参考某一类的知识另一个类的属性或实施，而是知识那个其他类本身。强的当依赖类发生耦合时包含一个直接指向 a 的指针具体类提供要求的行为。依赖关系不能被替代，或者它的 “签名”已更改，无需对依赖类的更改。松动的当依赖时发生耦合类只包含一个指向接口，然后可以由一个或多个具体实施类。

在您的示例中，您介绍了 Order 类和 Period 类之间的一些耦合。您可能需要将两个相关日期传递给 Order 方法，并且您选择创建一个 Period 类来执行此操作。为什么？因为你有两次约会；一个开始日期和一个截止日期；并且您想验证截止日期是否晚于起始日期您的代码中只有一个位置。这是DRY principle的一个应用程序；这是一件好事。 DRY 原则的应用虽然相关，但与代码重用不同（来自here）：

一些特点更容易重用的软件是模块化、松耦合、高凝聚力、信息隐藏和关注点分离。

松散耦合只是实现代码重用的几个特征之一。代码重用在某种程度上是您在代码的其他地方使用 Period 类的能力，而不仅仅是 Order 类。如果您要添加一个接口来抽象出您对 Period 类的使用，这将使您的 Order 类和 Period 类更加松散耦合，但这不会剥夺您的代码重用能力（您在其他地方使用 Period 类的能力在您的代码中）。

【讨论】：

完全同意...很好的答案。谢谢（我读了很多次，但是，当你看到一个如此详尽的评论（为什么/何时/细节）时，在你的代码中走哪条路是有道理的。谢谢史蒂夫。

【解决方案2】：

松散耦合和重用确实是相互竞争的概念。在设计软件时，您必须不断平衡两者的使用。

【讨论】：

好的，根据你的回答，我想我理解了这些概念。

【解决方案3】：

系统中的服务（如 GetOrders）可以依赖于易于创建的小型值对象（如 Period）。这使您的服务对象可以根据您正在工作的领域而不是始终以基本类型进行交流。

因此，在这种情况下，我会说将 Period 传递给 GetOrders 是正确的。它提高了抽象级别。 GetOrders 对所有 Period 类都感兴趣，因此您不会不必要地扩大 GetOrders 了解的概念范围（只是形式不同）。如果 Period 是一个包含一堆其他东西的更大的类，那么耦合将是一个更大的问题。

使这一切正常的第二个因素是创建 Period 对象很容易。如果它要求您创建一系列其他对象，那么耦合将是一个问题。这就是为什么您没有让您的值对象发送电子邮件并将自己保存到数据库等的原因。

【讨论】：

【解决方案4】：

应避免不必要的耦合，但在您的场景中，Period 仅用于定义一个值类型，该值类型聚合了有关您的域的一些概念，因此它一点也不差。如果超出了值类型的使用范围，您将需要使用依赖注入 (DI) 和控制反转 (IoC) 等技术将它们解耦。

就您衡量设计而言，当涉及到依赖关系时，您将不得不超越类级别，而更多地关注命名空间或程序集级别。在您的情况下，如果 Period 存在于同一个命名空间或程序集中，那么您在包中的类型之间仍然具有非常好的关系凝聚力。在上述场景中，您的命名空间的传出和传入耦合仍将保持不变/较低。

【讨论】：