面向对象五大原则_基石_开闭原则

1988年，勃兰特·梅耶（Bertrand Meyer）在他的著作《面向对象软件构造（Object Oriented Software Construction）》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension,but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。这句话说得略微有点专业，我们把它讲得更通俗一点，也就是：软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。

----百度百科

为什么没有说是面向对象6大原则，为什么没有将开闭原则包括进去？  

开闭原则是最基础的一个原则，前面5个原则就是它的具体形态，开闭原则才是他们的接口。

IBook作为一个接口，里面有三个方法，而小说NovelBook是一个具体的实现类，是所有小说的总称，BookStore指的是书店。

public interface IBook { public String getName(); public int getPrice(); public String getAuthor();}

public class NovelBook implements IBook { private String name; private int price; private String autor;  public NovelBook(String name,int price,String autor){  this.name=name;  this.price=price;  this.autor=autor; }  public String getAuthor() {  return this.autor; } public String getName() {  return this.name; } public int getPrice() {  return this.price; }}

public class Store { private final static ArrayList<IBook> booklist = new ArrayList<IBook>(); static { // 静态模块加载数据，实际项目一般由持久层完成  booklist.add(new NovelBook("巴黎圣母院", 3200, "雨果"));  booklist.add(new NovelBook("悲惨世界", 5600, "雨果"));  booklist.add(new NovelBook("天龙八部", 4800, "金庸"));  booklist.add(new NovelBook("挪威的森林", 2200, "村上春树")); } 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书籍作者:"     + book.getAuthor() + "\t书籍价格:"     + format.format(book.getPrice() / 100.0) + "元");  } }}

让程序猿最害怕的需求变化来了: 因为俺们村最近炒股，都赔了，书卖不出去，需要打折来促销，40块以上的9折，以下的8折。

思考如何修改： 

    1.一了百了，修改接口，如果这个需求变化在设计的时候就想到了就好了。这样修改的话下面的NovelBook类要改，书店类也要改。接口对外是承诺，一旦确认不能修改。不能经常变化。否定！

    2.修改NovelBook中的getPrice方法，替换class文件，这个可行。但是还要结合实际情况。待定！ 

    3.扩展一个子类，重写getPrice方法。   可以！  

public class OffNovelBook extends NovelBook {  public OffNovelBook(String name, int price, String autor) {  super(name, price, autor); } @Override public int getPrice() {  int price=super.getPrice();  int oprice=0;  if(price>4000){   oprice= price*90/100;  }else{   oprice= price*80/100;  }  return oprice; }}

static { // 静态模块加载数据，实际项目一般由持久层完成  booklist.add(new NovelBook("巴黎圣母院", 3200, "雨果"));  booklist.add(new NovelBook("悲惨世界", 5600, "雨果"));  booklist.add(new NovelBook("天龙八部", 4800, "金庸"));  booklist.add(new NovelBook("挪威的森林", 2200, "村上春树"));  booklist.add(new OffNovelBook("唐诗三百首", 4500, "谁写的")); }

也许有人会认为高层业务代码已经修改了，但是这是不可避免的，有的时候甚至会连界面也会修改的。 变化也许是逻辑变化，也许是子模块变化，那么相应的对于其他模块必然会造成影响，视图变化也需要扩展。

再说了，如果你修改了以前写好的代码，要知道，在实际开发中，投入的代码都是经过测试MM的千锤百炼的，如果你这一改，测试MM的笑脸你是别想再看到了。不改的话我们还是好朋友。

开闭原则的好处:

    1.测试

    2.复用性

    3.可维护性

总之一句话，拥抱变化，拒绝修改，提倡扩展。系统的稳定性得到了保证。

让程序猿最害怕的需求又变化来了: 现在俺们村文化程度提高了，书店需要扩展，前几天张家的儿子和李家的女儿都考上了计算机专业，一个是大数据，一个是嵌入式，我们要加这俩个领域的书 。 

如何思考: 需要增加一个属性领域，还得在原来的基础上扩展，不能修改原有的抽象层，那么我再加一个不就行了吗？ 让IComputer接口继承IBook接口，然后再写具体类。通过构造传参。

public interface IComputerBook extends IBook { public String getScope();}

public class ComputerBook implements IComputerBook { private String name; private int price; private String autor; private String scope;  public ComputerBook(String name, int price, String autor, String scope) {  this.name = name;  this.price = price;  this.autor = autor;  this.scope = scope; } public String getScope() {  return this.scope; } public String getAuthor() {  return this.autor; } public String getName() {  return this.name; } public int getPrice() {  return this.price; }}

static { // 静态模块加载数据，实际项目一般由持久层完成  booklist.add(new NovelBook("巴黎圣母院", 3200, "雨果"));  booklist.add(new NovelBook("悲惨世界", 5600, "雨果"));  booklist.add(new NovelBook("天龙八部", 4800, "金庸"));  booklist.add(new NovelBook("挪威的森林", 2200, "村上春树"));  booklist.add(new OffNovelBook("下架的书", 4500, "谁写的"));  booklist.add(new ComputerBook("大数据入门", 8500, "李老师", "大数据"));  booklist.add(new ComputerBook("嵌入式精髓", 2600, "吴老师", "嵌入式")); }

这样的设计遵循抽象约束原则:   1.通过抽象层约束扩展，对扩展进行边界限定。

                                             2.参数类型，引用对象尽量使用接口或者抽象类。

                                             3.抽象层始终维持稳定，一旦确定不再修改。

1.抽象约束    

2.元数据控制模板

        元数据: 配置参数，变化的参数，例如登录时需要先检查IP地址，然后决定是否登录，SSH使用了拦截器，这在之前的博客有写过。控制反转，使用底层的反射来写的。

3.制定项目章程

       所有成员必须遵守的约定，整齐划一，提高开发效率，这个目前只能是模拟幻想而已。。。

4.封装变化

    (1).将相同的变化封装到一个接口或抽象类中。  (2).将不同的变化封装到不同的接口或者抽象类中。 

参考书籍《设计模式之禅》

我是菜鸟，我在路上。