设计模式/架构基本原则
整理来自来自《大话设计模式》
一、系统模块组件间目标：高内聚低耦合
高内聚低耦合也是软件设计的目标。
对内设计合理：数据和算法分离，逻辑和表现分离的MVC模式,对外:有统一简单的接口，也是软件工程里面的设计模块的目标。
二、接口和组合：依赖倒转原则，合成/聚合复用原则（一定面向接口,使用继承多态，组合优于继承）
1.面向接口编程，父类接口实现调用框架，子类实现细节，细节的实现依赖于父类的框架，client依赖于父类接口。
依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：
（1）抽象不应当依赖于细节；细节应当依赖于抽象；
（2）要针对接口编程，不针对实现编程。
里氏原则：是Barbara liskov女士在1988年发表的，核心思想是所有子类都可以替换父类，而使程序不改变，这是编程世界里的继承原则，只有符合编程世界里的继承，才能定义继承（区分于现实世界）。
依赖倒转原则是建立在里氏原则基础上的，是相对于面向过程编程来说的，面向过程是将实现细节封装为库，然后以后的高层模块就要依赖于底层的细节模块。
依赖倒转原则：高层模块(客户需求抽象)不依赖底层（子类）模块，高层模块和底层模块都应该依赖于抽象；抽象不应该依赖底层细节，细节应该依赖抽象。
总结：区分客户，抽象接口和子类，需要抽象出接口，面向接口编程。
2.合成/聚合复用原则（CARP）:要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的。
三、类的抽象和多态：开放关闭原则，里氏替换原则
用抽象继承多态(函数指针)对拓展开放，对修改关闭，需不断修正设计应对业务变化，同时知道拒绝使用抽象。
开放关闭原则是需要将揉成一团的代码用抽象，继承，虚函数多态分离为各个模块，从而对增加开放，对修改关闭。需要根据需求设计或者编写过程中对修改部分抽象出基类，声明共同的虚函数，对逻辑部分封装为子类，以后业务修改只需要增加逻辑子类即可；但不是什么都抽象应用关闭开发原则，拒绝抽象和使用抽象一样重要。
正确应用了抽象继承多态的设计方法，就可以获得面向对象所声称的UML协助设计，可维护，可复用，可拓展，灵活性好的巨大好处。
一国两制，公司考勤都用到了该思想的，对目标关闭不能修改，对硬制度开放弹性化。
在面向对象的抽象封装继承多态体系中，还有：
里氏代换原则:任何基类可以出现的地方,子类也可以出现。
子类能够必须能够替换基类能够从出现的地方。子类也能在基类 的基础上新增行为。这yi讲的是基类和子类的关系，只有这种关系存在时，里氏代换原则才存在。正方形是长方形是理解里氏代换原则的经典例子。四、类间通信：迪米特法则和接口隔离原则
类之间的通信，尽量通过抽象的第三者或者中介来通信，尽量将穿插结构改为星型结构，也就是mediater中介者模式。在类之间：如果两个类之间不必要直接通信，那么就不需要直接通信，而是通过抽象的第三者来通信。在类的结构设计上：每个类都应该尽量降低成员的访问权限，避免直接操作该类的数据成员，尽量降低类之间的耦合，使得修改其中一个类的话，不必直接修改牵连的很多类。
接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
迪米特法则是目的,而接口隔离法则是对迪米特法则的规范.
五、类和函数的划分：单一职责原则
一个类一个文件负责一个功能任务，一个函数一个小功能。
关键是划分类，类的划分，如果有多个动机来修改这个类，那么就要将该类划分，直到一个类负责一个功能模块和一个修改动机。
函数的划分也是同理的，如果是两个小功能那么将该函数划分为两个函数。
设计模式不单单是类的关联组合继承关系的模式，而是合理使用抽象、多态和封装的UML架构，使得业务需求改变更具修改拓展，重用灵活特性。