在《面向对象软件构造》中提出：软件试题应当扩展开放，对修改关闭。简单的来说就是一个软件实体应该通过扩展来实现变化，而不是通过修改已有代码来实现。

软件实体介绍：

        1、项目中划分出的模块

        2、类与接口

        3、方法

    开闭原则视为软件实体的未来事件而制定的对现行设计进行约束的原则

例如：以图书销售为例：
public interface fBook{
	public String getName();
	public int getPrice();
	public String getAuthor();
}
public class Book implements fBook{
	private String name;
	private int price;
	private String author;
	public Book(String name.int price,String author){
	this.name = name;
	this.price = price;
	this.author = author;
	}
	public String getName(){
		return this.name;
	}
	public int getPrice(){
		return this.price;
	}
	public String getAuthor(){
		return this.author;
	}
}
public class BookStore{
	private final static ArrayList<fBook> bookList = new ArrayList();
	static{
		bookList.add(new Book("西游记",4900,"吴承恩"));
		bookList.add(new Book("三国演义",8300,"罗贯中"));
		bookList.add(new Book("红楼梦",4100,"曹雪芹"));
		bookList.add(new Book("水浒传",3600,"施耐庵"));
	}
	public static void main(String[] args){
		NumberFormat format = NumberFormat.getCurrencyInstance();
		format.setMaximumFractionDigits(2);
		System.out.println("-------------书店卖书记录如下----------------------"); for (IBook book : bookList) { System.out.println("书籍名称："+book.getName()+"\t\t作者："+book.getAuthor()+"\t\t价 格："+format.format(book.getPrice()/100.0)+"元");
	}
}

运行结果



假使项目有新的需求,40元以上的书籍9折销售

40元以下的书籍8折销售，对于该项目来说有3中解决方法：

(1)修改接口

        在fBook接口里新增getOffPrice方法，专门用于进行打折，所有的实现类度实现该方法，但这样修改的后果就是，实现类Book的要修改，书店类BookStore中的main方法也要修改，同时，fBook作为接口应该是稳定且可靠的，不应该进程发生变化，因此该方法否定

(2)修改实现类

        修改Book类中的方法，知己在getPrice()方法中实现打折处理，这个方法可以是可以，但如果采购书籍的人员要看价格怎么办，由于该方法以及进行打折处理，因此 采购人员看到的也是打折后的价格，会因信息不对称出现决策失误的情况，因此该方法不是最优方法

(3)通过扩展实现变化

        增加一个子类OffBook,覆盖getPrice方法，高层次的模块（也就是BookStroe中static静态块中）通过OffBook类产生新对象，完成需求变化对系统的最小开发，这样修改少，风险也小
public class OffBook extends Book{
	public OffBook(String name,int price,String author){
		super(name,price,author);
	}
	public int getPrice(){
		int selPrice = super.getPrice();
		int offPrice = 0;
		if(selPrice > 7000)
			offPrice = selPrice*90/100;
		else
			offPrice = selPrice*80/100;
		return offPrice; 
	}		
}
public class BookStore{
	private final static ArrayList<Book> booklist = new ArrayList();
	static {
		bookList.add(new OffBook("西游记",4900,"吴承恩"));
		bookList.add(new OffBook("三国演义",8300,"罗贯中"));
		bookList.add(new OffBook("红楼梦",4100,"曹雪芹"));
		bookList.add(new OffBook("水浒传",3600,"施耐庵"));
	}
	public static void main(String[] args) { NumberFormat format = NumberFormat.getCurrencyInstance(); format.setMaximumFractionDigits(2); System.out.println("-------------书店卖书记录如下----------------------"); for (IBook book : bookList) { System.out.println("书籍名称："+book.getName()+"\t\t作者："+book.getAuthor()+"\t\t价 格："+format.format(book.getPrice()/100.0)+"元"); } }
}




开闭原则作用

        开闭原则是面向对象设计的最终目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性

1、对软件测试的影响

        遵循开闭原则，软件测试只需要测试扩展的代码，无需测试原有代码，因为原来的代码能够正常运行

2、可以提高代码的复用性

        粒度越小，被复用的机会越大，根据原则和抽象编程可以提高代码的可复用性

3、可以提高软件的可维护性

        遵循开闭原则，其稳定性高、延续性抢，从而易于扩展和维护

代码有高低质量之分，而设计模式则是提高代码质量如提高其可维护性、扩展性、复用性等等，学习设计模式也可以提高个人对系统设计的理解等等，反正好处多多，正好最近也在学习，便记录一下。

要理解设计模式，我觉得除了要懂得这些设计模式的使用场景外，还要知道他们是围绕什么样的思想或者遵守什么样规则，那不得不提设计原则了。

1.开闭原则

对扩展开放，对修改关闭，即对于某个模块功能应该尽量使用继承或者接口来实现扩展，而不应该在原来代码上修改

就比如一个动物接口有play的方法，一个dog实现了play方法,如下面的代码

public class OpenAndClosePrinciple {

    public static void main(String[] args) {
        assert new Dog().play().equals("i am happy");
        System.out.println(new Dog().play());
        System.out.println(new ExtraDog().play());
    }
    
    interface Animal{
        public String play();
    }
   static class Dog implements Animal{

        @Override
        public String play() {
            return "i am happy";
        }
    }
    
    static class ExtraDog extends Dog{
        @Override
        public String play() {
            return super.play()+"too";
        }
    }
}

但是某一天这个dog需要在play的基础上加其他东西，此时如果把Dog的play方法返回的字符串加上"too"，则会导致主函数的业务逻辑不通过，即修改原有对象的方法会影响到引用该方法的业务逻辑，而修改Animal接口增加一个play2方法也不合适，这时候可以使用继承狗的方式去重写这个方法而不改写原来的代码，开闭原则要求尽可能通过扩展实现变化，尽量少的改变已有模块，尤其是一些比较底层，通用的代码

2.里氏替换原则

所有引用基类的地方必须能透明地使用其子类对象。比如一个可以接受Iterable参数的方法，他可以接受他全部的子类作为参数，但是一个接受ArrayList的方法不一定能接口同样实现了Iterable的接口的HashSet方法。

1.里氏替换原则是开闭原则的实现基础，设计程序时应尽可能基类进行对象的定义及引用，具体运行时再决定具体的子类类型。

2.提高复用性，子类继承父类时会继承其属性和方法，但同时也侵入子类代码，也增加了耦合度，父类变更要考虑对子类造成的影响

3.提高扩展性，可以通过重写父类方法进行功能扩展

依赖倒置原则：

程序依赖于抽象接口，不能依赖具体的实现，即对抽象、通用进行编程，尽量不要对实现进行编程

static class Person{
        public void feed(Dog dog){
            System.out.println("i feed a "+dog.getClass().getSimpleName());
        }
        public void feed(Cat cat){
            System.out.println("i feed a "+cat.getClass().getSimpleName());
        }
        public void feed(BaseAminal aminal){
            System.out.println("i feed a "+aminal.getClass().getSimpleName());
        }
    }

从代码可以看出，如果没有面向基类编程，则每天添加一个动物，就需要写一个feed方法，而第三个面向抽象对象的方法则不用写过多的方法，减少代码量，增强可读性

1)高层模块不应该依赖低层模块，应该依赖抽象（接口或者抽象类）

2)接口或抽象类不应该依赖于实现类，实现类应该依赖于接口或者抽象

3.接口隔离原则

客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。也就是说建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。

比如下面的代码，因为movable接口功能过多，导致main函数的输出不符合现实逻辑

public class InterfaceClosePrinciple {
    public static void main(String[] args) {
        System.out.println(new Dog().FlyOrRun()+"天空");
    }
}
interface movable{
    String FlyOrRun();
}
 abstract class BaseAminal implements  movable{
    public String move(){
       return this.FlyOrRun();
    }
}
class Dog extends BaseAminal {
    @Override
    public String FlyOrRun() {
       return "running to";
    }
}
    

但是把这两个功能拆分以后，得到的结果确实也符合逻辑

public class InterfaceClosePrinciple {
    public static void main(String[] args) {
        System.out.println(new Dog().fly()+"天空");
    }
}
 abstract class BaseAminal implements movable {
    
    public String moveWithFly(){
        return this.fly();
    }
    public String moveWithRun(){
        return this.run();
    }
}
interface movable {
    String fly();
    String run();
}
class Dog extends BaseAminal {
    

    @Override
    public String fly() {
        return "i cant't fly to";
    }

    @Override
    public String run() {
        return "running to";
    }
}


4.单一职责原则

单一职责可以降低类的复杂性，提高代码可读性、可维护性，并且使得修改引起的风险降低，保证设计类、接口、方法时做到功能单一，职责明确.

如果模块承担的职责过多，除了不易维护之外还会剥夺其他模块的能力,比如一个用户他的邮箱、性别等等信息都统一由一个updte语句修改，那么可能会造成某些不需要修改的字段在某次方法调用中被修改了，在造成数据错误的同时也增加了排查难度，应该每个方法都尽量实现的功能的尽量单一，但同时也要注意划分是否恰当，随着需求、系统变更，如果划分不当，会导致原来符合单一职责的模块代码的代码量增多，资源浪费，对于接口隔离模式也是——比如上面的接口多增加了Dog类做不了几个移动的方法，比如开车、坐飞机、坐火箭等等移动方式，这时候狗也要实现这些方法就冗余了，对于狗而言这是不用考虑的方法，所以在使用时也要注意划分问题

接口隔离原则虽然和单一原则一样有细化的思想，但是他们针对的不一样，接口隔离针对的是抽象（比如接口、抽闲类），而单一职责则是相对具体的（比如具体类、具体方法）

5.迪米特法则（最少知识原则）

一个软件实体应尽可能少的和其他实体发生相互作用，用于降低类和类的耦合度,他也叫只和朋友类交流，朋友类的定义：

出现在方法中的出参入参、成员变量等等,比如下面的driverByMySelf方法，他没有和直接的朋友进行交流，即自己操作其他无关的变量，增加了耦合度，而driver方法就和Car进行交互，省心省力，但在使用该原则时也要注意与其他实体发生交互时不需要操作其他实体过多的方法，只需要调用自己需要的即可

class Man {

    public void driver(Car car) {
        car.move();
    }
    public void driverByMySelf(Car car){
        new Engine().start();
        new Tire().start();
    }

}

class Car {
    private String engine;

    public void move() {
        new Engine().start();
        new Tire().start();

    }
}

class Engine {
    public void start() {
        System.out.println("发动机启动");
    }
}

class Tire {
    public void start() {
        System.out.println("轮胎转动");
    }
}

6.合成复用原则

合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

原则是优先使用组合／聚合的方式，而不是优先继承，但是组合和聚合也有不同点，组合则是面向整体的，各部分不能脱离而独立存在，比如身体-心脏就是组合的关系，属于强关联，而聚合就是弱关联，比如学生-教师的关系，学生脱离教师也没有影响，这个原则主要是建议利用好已有的对象达到功能复用。

 

总结：

1.里氏替换和依赖倒置原则：要求面向抽象、基类编程

2.接口隔离原则和单一职能原则：细化接口、职责

3.开闭原则：对修改关闭，对扩展开放

4.合成复用原则：注意复用

5.迪米特法则：通过直接对象做事，降低与其他无关类的耦合

什么是设计模式

软件工程中，设计模式（design pattern）是对软件设计中普遍存在的各种问题，所提出的解决方案。

 

设计模式的目的

1、代码重用性：相同的代码不需要多次编写。

2、可读性：即编程规范性，便于其他程序员的阅读和理解。

3、可扩展性：可以很方便的增加新的功能，也称为可维护性。

4、高内聚、低耦合

 

设计模式七大原则

设计模式原则是程序员编程时，应该遵守的原则，也是各种设计模式的基础（即设计模式为什么这样设计）。

单一职责原则（Single Responsibility Principle，SRP）

定义：应该有且仅有一个原因引起类的变更。简单来说，即一个类只负责一项职责，只有一个可以引起它的变化的原因。

我们知道，在 OOP (Object Oriented Programming) 里面，高内聚、低耦合是软件设计追求的目标，而单一职责原则可以看做是高内聚、低耦合的延伸，将职责定义为引起变化的原因，以提高内聚性，以此来减少引起变化的原因。职责过多，可能引起变化的原因就越多，这将会导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。

单一职责原则是七大原则中最容易理解的原则，但要真正实现它并不容易。通常情况下，我们应该遵守单一职责原则。只有在逻辑足够简单，才可以在代码级违反单一指责原则（使用 if - else）；只有类中方法数量足够少，才可以在方法级别保持单一指责原则。

设计模式六大原则（1）：单一职责原则

小话设计模式原则之：单一职责原则SRP

接口隔离原则（Interface Segregation Principle，ISP）

定义：1、客户端不应该依赖它不需要的接口；2、类间的依赖关系应该建立在最小的接口上。

其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个接口臃肿不堪。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加轻便灵活。或许看到接口隔离原则这样的定义很多人会觉得和单一职责原则很像，但是这两个原则还是有着很鲜明的区别。接口隔离原则和单一职责原则的审视角度是不同的，单一职责原则要求类和接口职责单一，注重的是职责，是业务逻辑上的划分，而接口隔离原则要求方法要尽可能的少，是在接口设计上的考虑。例如一个接口的职责包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，并规定了“不使用的方法不能访问”，这样的设计是不符合接口隔离原则的，接口隔离原则要求“尽量使用多个专门的接口”，这里专门的接口就是指提供给每个模块的都应该是单一接口(即每一个模块对应一个接口)，而不是建立一个庞大臃肿的接口来容纳所有的客户端访问。

面向对象六大原则——接口隔离原则

依赖倒置原则（Dependence Inversion Principle，DIP）

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。依赖倒置原则的核心思想是面向接口编程。

依赖关系传递常用的方式有三种：接口传递、构造方法传递、setter 方法传递。

注意事项：

底层模块尽量都要有抽象类或接口，增加程序稳定性。
	
变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间就存在一个缓冲层，利于程序的扩展。
	
继承时遵循里氏替换原则。
设计原则之依赖倒置和接口隔离

设计模式六大原则（3）：依赖倒置原则

里氏替换原则（Liskov Substitution Principle，LSP）

定义：1、如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。2、所有引用基类的地方必须能透明地使用其子类的对象。即子类可以扩展父类的功能，但不能改变父类原有的功能。

OO（Object-Oriented）中继承性的缺点：

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
	
继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所涉及到的子类的功能都可能产生故障。
通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

需要注意，不要将里氏替换原则理解成子类应该避免 override。里氏替换原则不是不能 override，而是要按照父类所期望的那样去 override。

里氏替换原则——面向对象设计原则

Java 中的多态是不是违背了里氏替换原则？

迪米特法则（Law Of Demeter，LOD）

定义：1、一个对象应该对其他对象保持最少了解；2、只与你的直接朋友交谈，不跟“陌生人”说话。

对第一点而言，迪米特法则也称之为最少知识原则，通俗的讲就是一个类对自己依赖的类知道的越少越好，对于被依赖的类，向外公开的方法应该尽可能的少。

而第二点的含义是，如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。这里的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

迪米特法则想要表达的是降低类之间的耦合度，提高模块的相对独立性。其实现方式主要有通过以下两个方面：

从被依赖者的角度来说，只暴露应该暴露的方法或者属性，即在编写相关的类的时候确定方法/属性的权限；
	
从依赖者的角度来说，只依赖应该依赖的对象。
迪米特法则——面向对象设计原则

白话设计——浅谈迪米特法则

合成复用原则（Composite/Aggregate Reuse Principle，CARP）

定义：要尽量使用合成和聚合，尽量不要使用继承。

为什么尽量不要使用继承？

继承复用破坏包装，它把父类的实现细节直接暴露给了子类，这违背了信息隐藏的原则；
	
如果父类发生了改变，那么子类也要发生相应的改变，这就直接导致了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。而用合成和聚合的时候新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新的类专注于实现自己的任务，符合单一职责原则。
那么我们时候才能使用继承复用呢？判断标准是里氏替换原则，里氏代换原则是继承复用的基础。合成复用原则同里氏替换原则相辅相成的。

设计模式六大原则——合成/聚合复用原则(CARP)

面向对象的7种设计原则(4)-合成/聚合复用原则

开闭原则（Open Closed Principle，OCP）

定义：软件实体应当对扩展开放，对修改关闭。首先这里的软件实体，包含以下几个部分：项目中划分出的模块、类与接口、方法；其次，对扩展开放是对提供方而言，而对修改关闭是对使用方而言。

开闭原则是编程中最重要的原则，其他原则都是为了实现开闭原则。

其实开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

这 7 种设计原则是软件设计模式必须尽量遵循的原则，各种原则要求的侧重点不同。其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；单一职责原则告诉我们实现类要职责单一；接口隔离原则告诉我们在设计接口的时候要精简单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；迪米特法则告诉我们要降低耦合度；合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

设计模式六大原则（6）：开闭原则

开闭原则——面向对象设计原则

设计原则
设计原则

一.概述

1.定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
2.含义：一个软件应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化的。
3.应对场景：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会在修改旧代码时引入新的错误，从而使我们不得不对整个功能进行重构，并且需要所有代码经过重新测试。

二.为什么遵守及使用？


1）开闭原则非常有名，只要是面向对象编程，在开发时都会强调开闭原则


2）开闭原则是最基础的设计原则，其它的五个设计原则都是开闭原则的具体形态，也就是说其它的五个设计原则是指导设计的工具和方法，而开闭原则才是其精神领袖。依照Java语言的称谓，开闭原则是抽象类，而其它的五个原则是具体的实现类。


3）开闭原则可以提高复用性： 复用可以减少代码的重复，避免相同的逻辑分散在多个角落，减少维护人员的工作量以及系统变化时产生bug的机会。怎么才能提高复用率呢？设计者需要缩小逻辑粒度，直到一个逻辑不可以分为止。


4）开闭原则可以提高维护性 ：一款软件量产后，维护人员的工作不仅仅对数据进行维护，还可能要对程序进行扩展，维护人员可做的是扩展一个类，而不是修改一个类。


三.如何使用开闭原则


1）抽象约束
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：

通过接口或抽象类约束扩散，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法。
参数类型，引用对象尽量使用接口或抽象类，而不是实现类，这主要是实现里氏替换原则的一个要求
抽象层尽量保持稳定，一旦确定就不要修改



2）元数据(metadata)控件模块行为
编程是一个很苦很累的活，那怎么才能减轻压力呢？答案是尽量使用元数据来控制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗的说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。


3）制定项目章程
在一个团队中，建立项目章程是非常重要的，因为章程是所有开发人员都必须遵守的约定，对项目来说，约定优于配置。这比通过接口或抽象类进行约束效率更高，而扩展性一点也没有减少。


4）封装变化
对变化封装包含两层含义：

(1)将相同的变化封装到一个接口或抽象类中 ；

(2)将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

封装变化，也就是受保护的变化，找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口。