Terryjourneys的博客

最近在重构XXXproject的显示子系统的驱动，由于原有的代码和架构经过常年累月的修改，已经面目全非。新接手后看了着实让人头痛，因此下决心重构。偶然间看到了这本大话设计模式，记得还是我读研期间一位同学推荐买的，之前虽然看过，但是理解并不是很深刻，趁此正好结合这个实例来好好揣摩一下。书中采用了C#语言列举了实例，这里我想用C语言来模拟这种实现这个显示子系统的驱动，想起来心中还有一点点的小兴

一、简单工厂模式二、策略模式

重要语录语录一：根据场景创建不同的算法实例交由用户，并未减轻用户的负担，仍然具有耦合性语法二：让用户知道的类越少越好，耦合性越低语录三：任何需求的变更都是需要成本的，改动越小越好一句话概括策略模式与工厂模式结合 将根据场景创建不同算法实例交由策略类，减少了算法实现与算法使用者的耦合性模式实践//TODO

重要语录语录一：代码需具备的品质：可维护（只改局部不动整体）可复用（环保可再利用）可扩展（方便添加新功能） 灵活性好（代码可多种方式组合）语录二：用尽可能的办法避免重复语录三：封装、继承、多态把程序的耦合度降低语录四：封装将业务逻辑与界面逻辑分离，分离开才能达到可维护 可扩展语录五：继承和多态实现可复用一句话概括简单工厂模式就是用一个工厂类来创建不同的对象，通过多态实现

重要语录语录一： 就一个类而言，应该仅有一个引起它变化的原因；语录二： 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会影响到其它职责语录三： 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离语录四： 如果能想到多于一个的动机会改变一个类，这个类就是多于一个的职责一句话概括一个类应该仅作一件事情，一个函数也应当只做一件事情，专一化模

重要语录语录一： 软件实体（类、模块、函数等等）对于扩展是开放的，对于修改是封闭的语录二： 因此要抽象最有可能发生变化的种类，来隔离这些变化，避免修改语录三： 变化一发生就要采取行动做进一步抽象，以避免更大的变化语录四： 对需求的变化时通过增加新代码进行的，而不是更改现有的代码语录五： 查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难语录六：拒绝不成熟的抽象和抽

重要语录语录一： 抽象不应依赖细节，细节应该依赖抽象语录二：  针对接口编程，不要对实现编程语录三： 高层模块和低层模块都应该依赖于抽象语录四： 程序中所有的依赖关系都是终止于抽象类或者接口，就是面向对象的设计，否则就是面向过程的设计一句话概括依赖关系终止于抽象类或接口，而子类继承自抽象类和接口，可以通过扩充子类功能来实现功能的扩展