我的设计模式之旅(1)——学习的原则和一些笔记

首先，这是我自己的旅程，学了1年多的C#，好多问题还是无从下手，希望跟随着李建忠老师引导，和一些书籍的阅读学习，能使自己对软件设计和程序设计有所提高。我自己学习的目的也许和我上一句说的有冲突，但是感觉李建忠老师说的很对，我学习设计模式不是为了用他去编成去设计，而是在重构中让设计和编码更具合理性，软件的需求变化确实很剧烈，尤其对于一些流程性的工作平台来说，一旦流程更改，如果设计不是很合理的话将造成灾难性的问题。闲话少说，先将李建忠老师课程中的一些原则，我觉得自己应该记住的摘录在下面：

面向对象设计模式解决的是“类与相互通信的对象之间的组织关系，包括他们的角色、职责、写作方式几个方面。”

所谓“好的面向对象设计”是那些可以满足“应对变化，提高复用”的设计。

模式是通过不断的重构得来的。觉得这句很重要，模式是当多次重复劳动后，返回来评估观察的时候（重构），才会慢慢发现的。以前自己很不重视重构的问题，甚至没有思考过，现在发现重构是能提高质量的一个重要方法。

设计模式不是用来写代码例子的，而是用来设计软件的。个人理解其实设计也不是一上来就用模式来设计，因为软件的应用情况千差万别，一些“特色”需求也比较多，所以像编码实现一样，对于设计也进行阶段评审和测试，重新考虑软件的设计才会发现其中的一些模式。

 

从编程语言直观了解面向对象

对面向对象三大机制的支持，即：“封装、继承、多态”

1．封装，隐藏内部实现

2．继承，复用现有代码

3．多态，改写对象行为

 

设计原则：

这里以我原来的一个项目为例

1．针对接口编程，而不是针对实现编程

项目中是这样的，原来属于同一类的物品，例如药品，在开始录入系统全部都是药品，但是经过一段时期后，经过一些处理流程，其中一些药品被分成了几类，进入不同的处理流程。当时的处理就是在同一张表里作类别字段，然后用SQL语句筛选，而且药品读出后再按类别字段在程序里坐判断，像李建忠老师书说的一样，以后如果类别增加是需要修改而不是增加一个新的类。在作单个药品的处理时，感觉其实可以根据读出的类型实例化成不同类别的药品对象，然后将这个对象返回给调用程序。这样更符合面向对象的设计原则。

还有一点就是权限的设计，规定了3级角色，结果就写死了关系，以后如果结构变化需要调整权限这是一个不可维护的模块。现在想来，其实返回3种类型的对象，然后定义好3种对象能干什么就OK了，这是我理想的设计。但是有一点比较讨厌的是，用户还要根据每个人设置不同的权限，这一点就不太好办了，总不能有多少个人就实例化多少种对象返回吧，虽然是一个比较好的结构，以后也是可以维护的，但是感觉不是很好的方案，现在也没有想到比较好的解决方案。经过一段时间CRM3.0的研究，发现微软CRM3.0的权限设计比较不错，是一个四维的设置，可以实现权限控制到记录级别，首先第1维是不同的模块的设置，分为销售、营销和服务等几大模块，然后再每个模块中先建立一个2维的概念，纵坐标是不同的角色，横坐标是在该模块中不同的操作，这里已经有了3维的设置，第4维就是提供了一个权限的级别，例如：企业级、部门级、个人等，在前面的那个3维表里进行设置，意思就是如果设置企业级，允许这个角色在这一模块下的这个操作可以操作企业中的所有记录，例如读取，他就可以看到企业级别下的所有记录。

2．优先使用对象组合，而不是类继承

为了实现低耦合。只有很强的is a的关系才用类继承。

3．封装变化点

 

单一职责原则（SRP）：

– 一个类应该仅有一个引起它变化的原因。

开放封闭原则（OCP）：

– 类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

Liskov 替换原则（LSP）:

– 子类必须能够替换它们的基类

依赖倒置原则（DIP）：

– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

接口隔离原则（ISP）：

– 不应该强迫客户程序依赖于它们不用的方法。

 

三大基本面向对象设计原则

– 针对接口编程，而不是针对实现编程

– 优先使用对象组合，而不是类继承

– 封装变化点

 

以上是观看李建忠老师课程的一些笔记和随想。