系统软件的常见问题
1:僵化：牵一发而动全身，系统不可修改或扩展。
2:复杂或重复。过分复杂，难于理解。
3：不可复用，过于僵化而不可服用，不能剥离出独立的服用组件。
4:不够稳定。常常出错而又无法解决问题，系统运行不够可靠。
设计的原则：
降低耦合，来实现软件的复用和扩展，这正是设计原则的最终奥义。
随着面向对象的发展，形成了以封装，继承，多态为主的完整体系。继承了以抽象来封装变化，降低耦合实现复用的精髓。
而设计模式是对经验的总结与提炼，是对重复发生问题进行的总结和最佳解决策略的探索。
经典的5个设计原则：
1：单一职责原则
一个类，应该仅有一个引起它变化的原因。不要将变化原因不同的职责封装在一起，而应该分离。
2:开放封闭原则
软件实体，应该对外修改关闭，对外扩展开放。
3:依赖倒置原则
依赖于抽象，而不要依赖于具体，因为抽象相对稳定。
4:Liskov替换原则
子类必须能够替换其基类
5:合成/聚合复用原则
在新对象中聚合已有对象，使之成为新对象的成员，从而通过操作这些对象达到复用的目的，合成方式较继承方式耦合更松散。所以应该少继承，多聚合。
6:迪米特法则
又叫最少知识原则，指软件实体应该尽可能少的和其他软件实体发生作用。
单一职责原则的核心思想：
一个类最好只做一件事，只有一个引起它变化的原因。
单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，引起他变化的原因就越多，这将导致职责依赖，相互之间产生影响。从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
因此，SRP原则的核心就是要求对类的改变只能是一个，对于违反这一原则的类应该进行重构。
在以上设计中，DBManager类将对数据库的操作和用户权限的判别封装在一个类中实现，已添加记录为例。
public class DBManager { public void Add() { if (GetPermission(id) == "CanAdd") { Console.WriteLine("管理员可以增加数据。"); } } }
这显然是一个充满僵化味道的实现，如果权限设置的规则发生改变，那么必须修改所有的数据库操作逻辑。
重新设计的思路:
以Proxy模式调整之后，有效实现了职责的分离，DBManager类只关注数据操作和逻辑，而不用关系权限判断逻辑。
public class DBManager:IDBAction { public void Add() { } }
而将权限的判断交给DBManagerProxy代理类来完成。
public class DBManagerProxy : IDBAction { private IDBACtion dbManager; public DBManagerProxy(IDBAction dbAction) { dbManager = dbAction; } //处理权限判断的逻辑 public string GetPermission(string id) { //处理权限判断 } public void Add() { if (GetPermission(id) == "CanAdd") { dbManager.Add(); } } }
通过代理，将数据操作和权限判断两个职责分离，而实际的数据操作由DBManager来执行，此时客户端的调用就变得非常简单。
public class DBClient { public static void Main() { IDBAction DBManager = new DBManagerProxy(new DBManager("CanAdd")); DBManager.Add(); } }
开放封闭原则：
开放封闭原则(OCP）是面向对象原则的核心，软件设计本身的目标就是封装变化，降低耦合。
核心思想:
软件实体应该是可拓展，而不可修改的。也就是说，对拓展是开放的，而对修改是封闭的。
因此开放封闭原则主要体现在2个方面：
对外拓展开放，意味着有新的需求或变化时，可以对现有代码进行拓展，以适应新的情况。
对修改封闭，意味着一旦设计完成，就可以完成独立完成其工作，而不要对类进行任何修改。
需求总是变化。对软件设计者来说，必须在不需要原有系统进行修改的情况下，实现灵活的系统拓展，只有依赖于抽象。实现开放封闭的原则就是对抽象编程，而不是对具体编程，因为抽象相对稳定，而通过面向对象的继承和多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的拓展方法，所以对拓展就是开放的，这是实施开放封闭原则的基本思路。
应用反思：
思路：银行处理员
class BusyBankStaff { private BankProcess bankProc = new BankProcess(); //定义银行业务员工的业务操作 public void HandleProcess(Client client) { switch (client.ClientType) { case "存款用户": bankProce.Deposit(); break; case "转款用户": bankProce.Transfer(); break; case "取款用户": bankProce.DrawMoney(); break; } }
将业务功能抽象为接口，当业务员依赖于固定的抽象时，对于修改就是封闭的，而通过继承和多态机制，从抽象体派生出新的拓展思路，就是对拓展的思路。
按照上述设计实现，用细节体现为:
interface IBankProcess { void Process(); } //按银行按业务进行分类 class DespositProcess : IBankProcess { public void Process() { //办理存款业务 } } class TransferProcess : IBankProcess { public void Process() { //办理转账业务 } } class DrawMoneyProcess : IBankProcess { public void Process() { //办理取款业务 } }
思路的转变，会让复杂的问题变得简单，使系统各负其责，人人实惠。有了上述的重构，银行工作人员变成一个彻底的EasyBankStaff.
class EasyBankStaff { private IBankProcess bankProc = null; public void HandleProcesss(ClientCertificateOption client) { //业务处理 bankProc = client.CreateProcess(); bankProc.Process(); } }
银行业务可以像这样就自动的实现了。
class BankProcess { public static void Main() { EasyBankStaff bankStaff = new EasyBankStaff(); bankStaff.HandleProcesss(new Client("转账用户")); } }
当有新的业务增加时，银行经理不必为重新组织业务流程而担心，只需为新增的业务实现IBankProcess接口，系统的其他部分丝毫不受影响。
对应的实现为：
class FundProcess : IBankProcess { public void Process() { //办理基金业务 } }
依赖倒置原则：
依赖倒置原则核心思想：
依赖于抽象。
具体而言：
高层模块不应该依赖于底层模块，两者都应该依赖于抽象。抽象不应该依赖于具体，具体应该依赖于抽象。
依赖，一定会存在于类与类、模块与模块之间。面向对象设计在某种层次上，就是一个关于关系处理的哲学，而依赖倒置正是这种哲学思想在具体应用中的体现。当两个模块之间存在紧耦合关系时，最好的方法就是分离接口和实现，使得高层调用接口的方法，底层模块实现接口的定义。
同时，业务员EasyBankStaff、业务IBankProcess和客户Client之间，明显违背了依赖倒置原则，业务员和业务类依赖于具体的客户，而非抽象。
CreateProcess在创建业务类别时，是必须依托于ClientType为判断条件的，从而也决定了HandleProcess的执行也受制于ClientType的条件时，我们必须从HandleProcess的处理过程了解这一点。
public class Program { public static void Main(string[] args) { EasyBankStaff bankStaff = new EasyBankStaff(); bankStaff.HandleProcess(new Client("转账用户")); } }
bankStaff处理HandleProcess的过程依赖于具体的Client客户，而当有新的业务类别增加时，系统中必须增加对客户类别的依赖，对于完美的设计来说，这种机制是僵化的，应该实现更好的解决方案。
需要找到潜在的对象，使EasyBankStaff依赖于抽象，而抽象的办法就是为EasyBankStaff和Client之间增加一个抽象接口。
具体的实现为：
interface IClient { IBankProcess CreateProcess(); } class DepositClient : IClient { IBankProcess IClient.CreateProcess() { return new DepositProcess(); } } class TransferClient : IClient { IBankProcess IClinet.CreateProcess() { return new TransferProcess(); } } class DrawMoneyClient : IClient { IBankProcess IClinet.CreateProcess() { return new DrawMoneyProcess(); } }
在客户端调用，不需要进行任何类别的判断，可以实现用户自动找到窗口的需求。
public class BankProcess { public static void Main() { EasyBankStaff bankStaff = new EasyBankStaff(); bankStaff.HandleProcess(new Client("转账用户")); } }
HandleProcess自行受理其业务，通过依赖于抽象，实现了Client对象的依赖倒置，Client不被依赖，可以实现更多的灵活性。当有新的业务类别增加，只需要实现Client接口。
class FundClient : IClinet { IBankProcess IClient.CreateProcess() { return new FundProcesss(); } }
抽象的稳定性决定了系统的稳定性，因为抽象是保持不变的，依赖于抽象是面向对象设计的精髓，也是依赖倒置原则的核心思想。
依赖于抽象是一个通用的规则，而某些时候依赖于细节则是在所难免的，必须权衡在抽象和具体之间的取舍，方法不是一成不变的。
依赖于抽象，就是要对接口编程，不要对实现编程。
接口隔离原则：
核心思想：
使用多个小的专门的接口，而不要使用一个大的总接口。
具体实现：
接口应该是内聚的，应该避免出现"胖"接口。
一个类对另一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的接口，这是一种接口的污染。
接口有效地将细节和抽象隔离，体现了对抽象编程的一切好处，接口隔离原则强调接口的单一性。而胖接口存在明显的弊端，会导致实现的类型必须完全实现接口所有的方法、属性等。在设计上，这是一种浪费，而且在实施上会带来潜在的问题，对胖接口的修改将导致一连串的客户端程序需要修改，这是一种灾难。
将胖接口分解为多个特定的定制化方法，使得客户端仅仅依赖于他们实际调用的方法，从而解除了客户端不会依赖于他们不用的方法。因此，按照客户需求将客户分组，并依赖这种分组来实现接口，是接口隔离的重要方法。分离的主要手段有两种：
委托分离，通过增加一个新的类型来委托客户的请求，隔离客户和接口的直接依赖，但是会增加系统开销。
多重继承分离，通过接口多继承来实现客户需求，值得推荐。
应用反思：
IComputerUser是一个典型的"胖"接口，对于Aduit来说，他既需要工作，又需要娱乐，对于学生，只需要学习就行了，工作对他来说是浪费。
重新设计:
interface IComputerLearn { void ToLearn(); } interface IComputerWork { void ToWork(); } interface IComputerBeFun { void ToBeFun(); } class Aduit { private IComputerWork myWork(); private IComputerBeFun myFun; public void UseComputer { //主要是工作 myWork.ToWork(); //还可以娱乐 myFun.ToBeFun(); } } class Child { private IComputerLearn myLearn; public void UseComputer() { myLearn.ToLearn(); } }
建议：
将功能接近的接口合并，可能造成接口污染，实现内聚的接口才是接口设计的基本原则。
接口隔离原则，能够保证系统拓展和修改的影响不会拓展到系统的其他部分，
Liskov替换原则：
Liskov替换原则是关于继承机制的应用原则，是实现开放封闭原则的具体应用规范。
只有子类能够替换其基类时，才能保证系统在运行时期内识别子类，这是保证继承复用的基础。