一、 "开放－封闭"原则(OCP)Open-Closed Principle原则讲的是：一个软件实体应当对扩展开放，对修改关闭。
优点：
通过扩展已有软件系统，可以提供新的行为。而对已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
举例：一国两制
为实现祖国统一，邓小平提出“一国两制”的构想，这是一个很好的“开闭原则”。“一国”是封闭，即坚持一个中国的前提，这一点不能变，用中央的话来说就是“在一个中国的前提下什么都可以谈”。而“两制”就是开放，你走你的资本主义道路，我走我的社会主义道路。
“一国两制”不允许更改现有一个中国的秩序，将资本主义制度纳入现有的政治制度中，从而扩展了这一秩序。用面向对象的语言来讲，不允许更改的是系统的抽象层，而允许更改的是系统的实现层。
二、里氏代换原则（LSP）
Liskov Substitution Principle（里氏代换原则）：子类型(subtype)必须能够替换它们的基类型。反过来的代换不成立
如果有一个“学生”的类，其中有两个派生类：“男生”和“女生”，在“男生”类中有一个“找朋友”的方法，其接收的参数是“学生”，那么我将一个“男生”实例传入方法“找朋友”的方法是完全可以的，这样实现子类形对基类型的替换。反过来，如果男生类中有另一个方法“找女朋友”的方法，那其中接收的参数只能是“女生”类型，那你传入一个“学生”类的对象就不对了吧。
三、依赖倒置原则(DIP)
依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。
抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。
使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。
比如：我有一个“员工”类，它里面有一个“工作考核”的方法返回考核的结果，你可以在这个方法里写自己的代码，实现对员工的考核（上级考核*70%+自我考核*10%+下级考核*20%）。但大家很容易就发现其中的问题，这种考核的代码只能考核中层领导，并不适合最高层领导和最低层员工的考核。这时大家会想到把员工分类，不同类型的员工建立不同的类（高层，中层，员工层），其中的“工作考核”方法的代码也不同。ＯＫ，恭喜你，你的思维又进了一步。但下面又一个问题摆在你面前，如果有一个“报表”类，其中有一个方法“打印”，该方法用来打印每一位员工的工作考核的结果，那么“打印”方法中的参数应当接收“员工”类，然后调用“员工”类的“工作考核”方法取出该员工的考核结果，并打印。
现在问题出来了：现在有好多个不同类型的员工类，究竟打印方法中该接收哪种类型的员工呢？可能有的朋友会想到，为不同类型的员工建立不同的“打印”方法，哈哈，这下你可就不太明智了，为什么呢？因为你的脑袋还束缚在面向细节的编程中，而没有把针对接口的编程深入到思想中。解决方法：做一个“员工”接口，其中一个抽象方法“工作考核”，在此接口上实现“高层”、“中层”和“员工”三个类，而在“报表”类的“打印”方法中的参数只需接收“员工”接口类型的参数不就一切搞定了吗？而且确保在接口不变的情况下，可以再加入新的派生类而不影响“报表”类的实现。
四、接口隔离原则（ISP）
接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
举例：香港回归十周马上就要到了，假设我们需要两辆游行的“花车”。如果请你做两辆“花车”起名叫做“辉煌十年”和“东方长歌”，你会如做呢？当然有人会想建一个“花车”接口，然后分别用“辉煌十年”和“东方长歌”的花车类实现、它派生它，然后实例化它。ＯＫ，先要恭喜你，因为你知道要针对接口进行编程。但是大家都知道花车不宜太相似，最好是标新立异，对吧？那我们再来看刚才设计的“花车”这个接口，是不是有点太“霸道”了？换句话说这个接口会导致两辆花车“如出一辙”，而体现不出各自特点。如何解决这个问题呢？答案是：接口拆散。建立三个接口：可移动、喜庆、新颖。而两辆花车的类分别都实现这三个接口。现在你就不用担心会出现两辆相似的花车了
