Masterpiece

    在理解MRP的时候关键是一些业务概念以及计算逻辑，这里引用了运作管理教程里的一个百叶窗的例子来说明计算过程以及所需要的数据。
    主生产计划：
   
    BOM：
   
    库存信息以及提前期：
   
    物料的需求计划：
   

    在物料需求计划制定出来之后就会参考能力需求计划来决定是否可行，如果可行那么就生成真正的执行物料计划，如果不可行那就要重新制定。
    能力需求计划主要搜集的数据包括：工作中心的数据（用于计算工作能力），工艺线路数据（工作中心加工什么物料），工厂的生产日历（工作中心工作时间）。
   
    从中可以计算出负荷如下，其中符合为负值则说明出现问题，计划需要改进：
   
    上面就是MRP的基本计算逻辑，清楚了吧！

    接口和抽象超类以前都有用过，当时就有点疑惑，明明接口的这个功能有超类来替代就是可以的，何必还要有接口这个东西呢，今天看了《JAVA 与模式》中的阐述才算明白。 

    之所以要用接口来实现软件的可插入性，是因为如果我们选择基于类的继承来保证可插入性，应该说在最简单的情况下可以实现，但是如果当一个类要同时实现两种接口的时候，用类的继承实现方式就出现了问题，因为在C#中还是JAVA中，一个类只能继承自一个超类，而可以实现多个接口。所以要用类的继承实现方式保证可插入性就必须出现一个超超类，这样就违反了Open Close Principle。所以说这也就是什么时候采用接口继承、什么时候采用类继承的主要参考原则。
    而且，在下列情况用接口来保证可插入性显得更灵活，（关联可插入性）如一个对象要完成一个任务要知道另外一个对象并调用其方法，这个对象对其他对象的知识叫关联，而这个关联可以移到与接口，即是关心的不是具体类，而是具体类有没有实现该接口。（调用可插入性）由调用具体类变成了通过接口调用具体类，这样在调用的时候就不必关心具体类，而是动态决定，只要实现该接口的类都可以被调用。 

    前段时间公司培训，有一位讲师在讲述面向对象的过程中讲到，曾经有人建议过让他们编码的时候尽量的花点时间把接口抽象出来，然后再去实现它，后来遭到他们的反对，所以也就没有执行。而现在系统做的越来越大了，由具体类之间的依赖所引发的问题也应该就越来越多了，处理起来也越来越棘手了，所以可以说软件越复杂，规模越大，客制化越多，接口的重要性就越大。
     以前学J2EE的时候觉得J2EE里面无论是EJB， 还是Servelet、Jsp,JMS怎么就那么多接口呢，看来是自己愚昧了

    接触面向对象也有两三年了，但是对于面向对象的一些原则却还没有掌握，最近复习了一下设计模式和面向对象的原则，所以写下一些笔记以及自己对这些原则的看法。 

    1.Open Close Principle （对可变性的封装）

    设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
    其实这里所说的不被修改是指的重要的抽象层的模块不会被修改，这也就是使变化中的软件系统有一定的稳定性。当系统要扩展或者添加新的行为的时候只需要添加另外实现的模块即可。由于新添加的模块继承于抽象层，所以实现了其不变性。
    比如在策略模式中，OCP就得到了很好的体现，算法的不同实现其实就是对扩展的支持，而算法抽象类是对系统的不变性的支持，环境类包装了对于环境变化的控制与所采用算法的选择，当采用其他算法的时候只需要扩展算法类即可。 
    也就是说关键在于抽象，抽象出来的东西是不变的，具体的实现继承于抽象，所以保证了对修改的Close，而抽象的实现方式有多种，可以随需添加，当然这也就是对扩展的Open。 另外要求的是技术包括：多态 Polymorphism,接口 Interface，继承 Inheritance.

    另外在对可变性进行封装的时候也应该注意以下几点：
    1.识别系统有可能变化的地方。
    2.不要将一种可变形散布在多处代码，而应该封装起来。
    3.不要将一种可变性与另外一种可变性混在一起。

    几乎所有的模式都是对不同可变形的封装，使其符合OCP。

    2.Liskov Substitution Principle 

    一个软件实体如果使用基类的话，那么一定适用于其子类，而且他根本不能察觉出基类对象和子类对象的区别^[1]。   其实力求符合这一设计原则是为了让我们理解继承，不要滥用继承。客户程序依赖的行为是基类，也就是我们抽象出来的类，所以继承该类的类就必须保证能够满足客户程序的要求，即能够代替基类。  
    如在策略模式中所有的算法都可以互换，只要子算法遵循超类中定义的接口，所以说符合LSP。  
    另外在我们的编码中也可以看出来，如果我们有一个超类SuperClass以及一个具体的子类SubClass，在超类中有一个public method这时如果你想在子类重写该方法并且把方法的访问级别调低，这编译都不会通过，因为违反了LSP原则。因为在这里如果客户程序用了引用了超类，很明显，用这个SubClass是无法替换SuperClass的。在这个例子中编译器做了检查，但是实际编码中有很多是编译器检查不出来的，如经典的正方形长方形问题。

    3.Dependence Inversion Principle 

    DIP的原则是要依赖于抽象而不是依赖于具体，高层模块不应该依赖与低层模块，两者都应该依赖于抽象，这样不至于使得以来关系的影响扩大，对依赖对象的修改不会波及面太广，这种耦合应该是属于面向对象系统里的抽象耦合。也就是说我们最好使用这样的描述
    人 object=new 男人（）；
    而不是
    男人 object=new 男人（）；

    其实面向接口编程的思想也是基于DIP的思想的，抽象方法不实现是为了更灵活的实现。

    在状态模式的运用中，Context类中为什么要引用State，而不是具体的状态类原因也在此：）

    Interface Segregation Principle,Single Responsibility Principle,Composite/Aggregate Reuse Principle原则等下次学明白了再写：（ 
    
    [1]引自《JAVA与模式》P70