工程中的“面向对象”编程

工程中的“面向对象”编程

在工程处理中，工程师很容易写出碎片的脚本代码，例如处理服务器上的脚本：

1. 假设了一些存在的环境变量、目录结构、配置和数据
2. 脚本基于这些假设开始做一堆中间处理，并最终得到一些输出数据。

即使有了docker，有了k8s，无论是在docker外，还是docker内，还是会有很多这样的工程处理脚本。

这些工程处理脚本非常容易碎片化，写这样的代码也很容易就没有模块化，缺乏明显的数据结构与算法的分离。

一种好的编程方式是，一旦开始写这样的脚本，从一开始就做“面向对象”抽象，例如

1. 设计一个 Config 对象，处理好全局配置的处理，做好不同名称空间的配置的正交组织，做好从配置服务、本地配置、以及命令行配置的管理。
2. 设计一个 Option 对象，处理好命令行参数和选项的管理。
3. 设计一个 Machine 对象，这个对象封装了内部的各种处理细节，对外暴露出一个逻辑上机器的目录结构、配置和数据。
4. 设计一个 Group 对象，处理好一组 Machine 的组织和管理。
5. 设计一个 System 对象，这个对象组织好 Config, Option, 一个到多个 Group 的组织。
6. 设计一系列的 Executor 对象，遵循单一职责原则，处理好每个明确定义职责的基于 Config, Option, Group 环境下的明确任务执行。
7. 设计一系列的 Schduler 对象，负责调度应用层的任务到 Executor 执行。

这是一个基本的工程中的“面向对象”编程，无论在哪一个抽象层上，这些都免不了。

--end--