在Matz的一篇PPT“Object-Oriented scripting in Ruby”中，Matz提到Ruby提供一种语言机制Mix-in，在其PPT中如是描述的“No Multiple Inheritance，but Mix-in”、“Mix-in is as strong as multiple inheritance，but simple”。

* “module” in Ruby
在C++、Java、C#中都有namespace的概念，是用来隔离代码，防止代码冲突的。在Ruby中是采用“module”这个关键字来完成namespace功能的。

//considering the following code:
//MicrosoftCompiler.rb
module Microsoft
    def Microsoft.compile
        print "This is microsoft's compiler", "\n"
    end
end

//SunCompiler.rb
module Sun
    def Sun.compile
        print "This is Sun's compiler", "\n"
    end
end
    
//TestCompiler.rb
require "D:\\Ruby\\MicrosoftCompiler.rb"
require "D:\\Ruby\\SunCompiler.rb"

Microsoft.compile
Sun.compile

//output:
>ruby TestComplier.rb
This is microsoft's compiler
This is Sun's compiler
>Exit code: 0

module除了体现namespace的概念外，从上面代码中我们还可以看到在两个module中定义的method和调用这个method时都在其前面加上其所在module的名字了。这样定义的函数叫module method。但是不是所有要使用module中函数都要显式的加上module名字呢？答案：不是。请往下看。

* Mix-in ：Another wonderful use of “module”
由module method的定义和调用方式让我们联想到class method（注意不是class instance method），也让我们从module联想到class了。但是A module是不能像class那样拥有实例的，module毕竟还不是class，但是我们可以在class的定义中“include”一个module，这样会发生什么呢？

//considering the following code:
module Mammal  # 哺乳动物
    def suckle     # 哺乳
        print "I can suckle my baby" ,"\n"
    end
end

module Flyable    #可飞行的
    def fly    #飞行    
        print "I can fly", "\n"
    end
end

class Chiropter    #蝙蝠
    include Mammal        #蝙蝠是哺乳动物
    include Flying        #蝙蝠可以飞行
end

aChiropter = Chiropter.new
aChiropter.suckle
aChiropter.fly

//output：
>ruby TestMixin.rb
I can suckle my baby
I can fly
>Exit code: 0

如上面代码得出的结果我们可以看出，一旦一个class中include了一个module,那么所有module中的methods就好像成为class’s instance methods一样，这就是mix-in，看起来被mix-in的modules的行为更像是这个class的super class，通过这种方法我们可以间接实现多重继承。但是注意看看被mixin的module中的函数是如何定义的？和前面代表namespace概念的module中的method定义不同的是在于定义时method name前不见了module name，这样定义出来的method叫module instance method,虽然module不能实例化，但是一旦被mixin到某个class中，这些module instance method的使用就等价于class instance method了。

总结：
1.Module的两种用法
 a) 体现namespace概念；
 b) 被mixin到class中间接的实现类的多重继承。
2.Module中的两种method定义和用法
module module_name
    def module_name.module_method_name
        # module method , for representing namespace concept
    end

    def module_instance_method_name
        # module instance method
        # Once the module has been mixed in,
        #the method will be equal to a class instance method
    end
end

敏捷设计最基本原则：“开放封闭原则（OCP，Open-Close Principle）”

* 回顾SRP
在开始谈OCP之前，我们还是简单回顾一下Bob大叔在其书中所论述的敏捷设计的第一个原则“单一职责原则（SRP，Single Responsibility Principle）”。

Bob大叔在其书中将职责理解为“变化的原因”。一般当需求变化时，该变化就会反映为类的职责的变化。按书中所述“如果一个类的职责过多，会使职责间产生耦合，一个职责的变化可能会削弱或抑制另一个类完成其他职责的能力，导致该设计的脆弱性。”根据这点论述得出结论：“就一个类而言，应该仅有一个引起它变化的原因”。

简单举个书中的例子理解一下（这里不作详细说明）：
//Modem.java
public interface Modem{
    void dial(String portNo);
    void hangup();
    void send(char c);
    void recv();
}
缺点：Modem有两个职责，分别是连接管理和数据通信。经过单一职责分解后==〉
//DataChannel.java
public interface DataChannel{
    void send(char c);
    void recv();
}
//Connection.java
public interface Connection{
    void dial(String portNo);
    void hangup();
}
//Modem.java
public class Modem implements DateChannel , Connection{
    //…
}

曾经在大学的时候用MFC开发程序，当然现在看起来那些程序的设计很糟糕。其中一个典型的缺点就是类的职责分配不明确，当时我常常在一个界面类中写入业务逻辑代码，比如email处理等等。也看过很多网友的MFC代码，出现此类糟糕设计的还是很多的。

* OCP-Open for extension，Closed for modification

引用书中论述“软件实体（类、模块、函数等等）应该是可以扩展的，但是不可修改”。

如何做到OCP？– 抽象
让A模块依赖一个接口或一个抽象类，这样对A模块的修改可以是Closed的。那么如何对A模块进行扩展呢？我们可以通过扩展那个接口的多种实现或者继承那个抽象基类做到这点。

Template Method模式的应用可以很好的解释上面的论述。
//某一个功能模块A是这样依赖一个抽象类AbsBase的：
void callSomething(AbsBase a){
    a.templateMethod();
}

//AbsBase的定义，一个即开放又封闭的基类。
public abstract class AbsBase{
    public abstract void method1();
    public abstract void method2();
    public void templateMethod(){
        method1();
        method2();
    }
}

下面我们就可以通过AbsBase的子类来扩展功能模块A的行为了
public class DerivedClass extends AbsBase{
    public void method1(){
        //…
    }
    Public void method2(){
        //…
    }
}

从上面可以看出Template method模式可以帮助我们去OCP。请时刻想着“抽象”这一实现OCP的基本原则。

在看书的过程中，我感觉到有时候不能为了OCP而去OCP，还需考虑实际情况和系统的整体架构。作者在书中也提到“仅对程序中呈现出的频繁变化的那些部分做抽象。拒绝不成熟的抽象和抽象本身一样重要。”