工程中的“面向对象”编程
在工程处理中，工程师很容易写出碎片的脚本代码，例如处理服务器上的脚本：
- 假设了一些存在的环境变量、目录结构、配置和数据
- 脚本基于这些假设开始做一堆中间处理，并最终得到一些输出数据。
即使有了docker，有了k8s，无论是在docker外，还是docker内，还是会有很多这样的工程处理脚本。
这些工程处理脚本非常容易碎片化，写这样的代码也很容易就没有模块化，缺乏明显的数据结构与算法的分离。
一种好的编程方式是，一旦开始写这样的脚本，从一开始就做“面向对象”抽象，例如
- 设计一个 Config 对象，处理好全局配置的处理，做好不同名称空间的配置的正交组织，做好从配置服务、本地配置、以及命令行配置的管理。
- 设计一个 Option 对象，处理好命令行参数和选项的管理。
- 设计一个 Machine 对象，这个对象封装了内部的各种处理细节，对外暴露出一个逻辑上机器的目录结构、配置和数据。
- 设计一个 Group 对象，处理好一组 Machine 的组织和管理。
- 设计一个 System 对象，这个对象组织好 Config, Option, 一个到多个 Group 的组织。
- 设计一系列的 Executor 对象，遵循单一职责原则，处理好每个明确定义职责的基于 Config, Option, Group 环境下的明确任务执行。
- 设计一系列的 Schduler 对象，负责调度应用层的任务到 Executor 执行。
这是一个基本的工程中的“面向对象”编程，无论在哪一个抽象层上，这些都免不了。
--end--
标签：脚本,配置,工程,处理,编程,面向对象,对象 From： https://www.cnblogs.com/math/p/oop-in-engine.html