类别和物料放在一个表单管理，老狐狸懵圈了，猫猫说只需做到这一点

昨天高总问我，想把类别和物料清单放在一个表单中进行管理。

VFP里面左边维护类别，右边维护物料清单。问我怎么设计会更好。

我的回答是，不建议这样做。

左边树添加到一半，又要去操作右边。

左边树删除了，右边已选择的类别怎么处理。

表单关闭了，是提醒左边，还是右边？

这些相互的关系，都需要考虑清楚，复杂度指数上升。

我见过一个很失败的案例，一个LED控制软件，除开专业的参数配置，就编辑节目单，播放出来就做得异常复杂，我拿到软件，我第一眼是蒙逼的，啥也看不明白。

好的设计，第一眼就能看到重点，所以我们讲人性化设计就是这样的。

VFP是支持面向对象设计的，在面向对象设计里面，有一个叫单一职责的原则，用在表单维护里面也适用。

表单做为一个完整功能，一般也围绕一个主要功能做。

类别做一个表单

物料清单做一个表单

物料清单要增加类别可以调用类表单添加

这样各自的职责很清楚。

单一职责的定义

单一职责原则（SRP：Single responsibility principle）又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特·C·马丁（Robert C. Martin）于《敏捷软件开发：原则、模式与实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克（Tom DeMarco）和Meilir Page-Jones的著作中的内聚性原则发展出的。[1]

所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。

对类来说的，即一个类应该只负责一项职责(功能)。

　　违反单一职责原则的坏处：如类 A 负责两个不同职责:职责(功能) 1，职责(功能) 2。当职责(功能) 1 需求变更而改变类 A 时，可能造成职责(功能) 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2（即遵循单一职责原则）

　　该原则提出对象不应该承担太多职责(功能)，如果一个对象承担了太多的职责(功能)，至少存在以下两个缺点：

一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力

当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费

举例说明：大学学生工作管理程序

　　分析：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做法是生活辅导由辅导员负责，学业指导由学业导师负责，其类图如图 1 所示，也即不同的职责找不同的类，类的单一职责。

　注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

结论

单一职责听起来很简单，做起来却很难，因为我们总是自然而然地倾向与把职责结合在一起（习惯于面向过程的思维）。

猫猫觉得破除惯性思维(老思维)最重要，不要认为自己的是最适合的，一接到任务用老方法撸起代码来。这样永远没有进步。