如何/仅使用表单和数据模块重构Delphi程序

Question

经过多年将Delphi程序编码为表单和数据模块中不可测试的代码(包括全局变量),唯一的类是表单本身,包含表单UI本身所需的所有代码.

我如何将代码转换为一组执行实际工作的类？我是否需要停止使用数据源/数据集并在类中执行所有操作？我需要ORM吗？

通常没有必要在表单中重用代码,所以将逻辑转换为类是否有意义？

Answer 1

如果我遇到一个责任太大的表格(或其他类),我通常会遵循以下模式:

1. 为逻辑定义一个新类.
2. 在表单中创建新类的成员变量.
3. 在onCreate中创建类,并在表单的onDestroy中释放它.
4. 将单个逻辑(例如变量)移动到新类.
5. 将所有方法移动或创建到新类.
6. 编译和测试.
7. 继续,直到所有逻辑都放入新类.
8. 尝试将逻辑类与表单类分离.(如果愿意,您甚至可以使用接口).

有些情况下单个类是不够的,因此创建更多类没有问题.这些类可以有其他类.

通过这些步骤,您可以解决大多数这些问题.

Answer 2

首先,我强烈建议您阅读Martin Fowler 所着的Refactoring一书.

这将使您真正了解如何以最佳方式明智地引入对现有(非OO)代码的更改以提高可维护性.

在您明确了解应用程序带来的好处(如果有的话)之前,我不会查看ORM.

Answer 3

我用一个应用程序来鼓励这样的问题,我开始做以下事情:

1. 为代码中的大多数通用逻辑定义主类.
2. 在每个表单中,将处理事件内业务逻辑的代码作为该表单中的函数/过程.
3. 然后将这些函数/过程作为静态方法移动到这些类.
4. 最后,只需要在验证UI等表单中调用所需的代码,并调用类.
5. 对于全局变量,尽量省略,并将值作为参数传递给方法.

我使用静态方法,因为它更容易从事件中删除代码,只需调用它们而不需要为每个操作创建/ Free对象.原始设计并非旨在将表单与业务逻辑代码分开.

最终的应用程序并不是完整的OO,但最不容易测试方法而不需要像以前那样与表单和事件进行交互.

有时您会觉得如果从头开始重新设计应用程序,那么进行更改以使其成为真正的OO设计会更容易.