Question

我知道当你有一个只在一个地方使用的类对象时，编程和架构很糟糕。但是我也被警告要创建一个功能强大且可以做得太多的对象。那我该怎么做呢？这是我的意思的一个例子 - 请不要把这些事情视为文字，因为这只是一个例子。

无论如何，我有一个与我合作的对象，这个对象相当复杂。许多信息存储在此对象中，并且可以对数据执行大量操作。所以，让我们称这个对象为地球。

Public Class Planet
Private _population As UInteger = 0
Public ReadOnly Property Population() As UInteger
    Get
        Return _population
    End Get
End Property

Public Overridable Sub CreatePerson(Optional ByVal numberOfPeople As Integer = 1)
    _population += numberOfPeople
End Sub
End Class

到目前为止足够简单。但我可以继续讨论对象可能执行的许多事情。所以，为了防止事情变得太复杂，我打破了白天和夜间发生的“活动”，创造了另外两个对象：白天和黑夜（这两个没有显示）。所以现在我有一个更新的Planet类。

Public Class Planet

Private _population As UInteger = 0

Private _day As New Day
Private _night As New Night

Public ReadOnly Property Day() As Day
    Get
        Return _day
    End Get
End Property

Public ReadOnly Property Night() As Night
    Get
        Return _night
    End Get
End Property

Public ReadOnly Property Population() As UInteger
    Get
        Return _population
    End Get
End Property

Public Overridable Sub CreatePerson(Optional ByVal numberOfPeople As Integer = 1)
    _population += numberOfPeople
End Sub

End Class

现在，这两个类 - 白天和黑夜 - 将从不在Planet类之外使用。这是为这个“父级”星球组织我的方法和属性的好方法吗？我怎样整齐地组织类似的？

我读过关于重构的内容，但我认为这不会对我的情况有所帮助。我喜欢这样的想法，我可以调用这样的Planet对象：Earth.Night.BlowUpMoon。

Answer 1

考虑可发现性。如果其他人要使用你的物体，他们会知道他们必须在一天的特定时间炸毁月球，这与BirthdayCard.September25th.Send()相同吗？任何“别人”我也会在6个月内包括你。你是为了组织而组织还是以一种有意义的方式将类似的方法和属性放在一起？

Answer 2

尽管您的示例是人为设计的，但这种情况在域驱动设计中很常见。您的Planet类将是aggregate - 管理其内部实体的根对象。在聚合边界之外，所有交互都是通过根聚合对象。

Answer 3

重构你的类并将其拆分为几个较小的类，每个类都有一个single responsibility。它们每个只使用一次并不重要 - 代码仍然会更好，更容易理解，而且更容易测试。

如何防止上帝对象？

3 个答案: