请参阅以下代码:
Public Class SystemCheck
public Overridable sub Check(ByVal RecordID As Integer, ByVal SystemID As Integer) As Boolean
'Generic code to check a system
And Sub
End Class
Public Cass MarketingSystemCheck
Inherits SystemCheck
public Overrides function Check(ByVal RecordID As Integer, ByVal SystemID As Integer) As Boolean
'Code to check Marketing system specifically
And function
End Class
Public Cass Sales SalesSystemCheck
Inherits SystemCheck
public Overrides function Check(ByVal RecordID As Integer, ByVal SystemID As Integer) As Boolean
'Code to check Marketing system specifically
And function
End Class
类检查记录是否可以删除。 SystemCheck.Check可用于检查来自许多系统的RecordID,例如生产,财务等。
我的问题是:拥有代表流程的类是不好的做法,例如SystemCheck而不是例如人。有人今天对我说,课程应该代表事物而不是过程,但我仍然不确定。
答案 0 :(得分:3)
过程就是事物,至少在概念上是这样。
没有规则说一个类必须只代表一个物理的三维现实世界的东西。类应该代表可能具有物理类似物或不具有物理类似物的个体“事物”,但更重要的是,类应代表关注点的概念分离。
如果“进程”可以使用自己的描述符,自己的功能以及自己更改的单一原因进行封装,那么我认为没有理由说它不应该是一个类。 (或许建议这个的人可以详细说明你的设计的替代品?)
比您的类更重要的是推动良好的面向对象设计的原则。一系列这样的原则是the S.O.L.I.D. principles。
如果“进程”与某个对象相关,而该对象代表“事物”,则可能该进程可以被重构为该“事物”的一部分“。但可能有非常令人信服的理由不应该这样做。如果“进程”和“事物”需要彼此独立地修改,那么合并它们会引入依赖性,这样当一个变化时需要重新测试。
有时将概念分离到自己的类中甚至可能与任何特定的面向对象原则无关,而只是重构可读性和可维护性的问题。我认为这是一个典型的例子Replace Method With Method Object重构模式。
不要害怕上课。它们非常有效地封装了逻辑和数据。 “太多的类”只有在业务概念变得非常紧张时才会成为一个问题,因为它们是在多个类中进行布局的。例如,如果在UI中向表单添加字段涉及在开发堆栈中一直修改大量类,那么可能有太多。 (或至少太多具有相同结构或大致相同的东西。)