再会）
熟悉一个程序的设备后，我注意到它没有可以显示现实世界对象本质的类。
让我用一个例子来解释。假设我们有一台具有一组特定参数的机器。我们需要检查这些参数。该模型具有检查参数的方法，但没有具有一组参数的机器类。相反，我们从数据库中获取特定的 DataRow 并将其加载到参数验证方法中。
问题：这种方法的优点和缺点是什么？对我来说，这种方法很不寻常。我一直认为在程序中模型是首要的，数据库是信息的来源。毕竟，DataRow 对象本质上是相当抽象的。您需要知道行中列的名称。此外，在使用该程序时，我没有看到带有一组参数的特定 Car 类。总之，来自 DataRow 的数据会立即显示在屏幕上或转到方法中进行检查。
你所描述的恰恰相反
ООП。领域概念并没有明确地出现在代码中，只存在于作者的脑海中。优点是节省了创建和开发模型的时间，使您可以更快地编写原型。
这种方法的缺点在长距离和任何显着大小的代码库上都表现出来。基本上，这是在新程序员的头脑中创建基于代码的领域模型的困难，或者是将现有模型与代码进行比较的困难。这会导致代码退化、重复、意大利面条式代码，以及对什么和如何工作以及重构的副作用会传播多远缺乏信心。