《论语》中有一句话：自古皆有死，民无信不立。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

前几天，网上找了套java题目，给项目组成员做了一次考试，意图是让大家知道很多基础概念还不一定清楚，于是应该good good study，day day up。

考试之后，有同事问起一个“by value”知识点相关的题目：

Given the following code:

public class Test{
    public static void main(String args[])
    {
        String str=new String(World);
        char ch[]={'H','e','l','l','o'};
        change(str,ch);

        //System.out.println(str + " and " + ch);
        //这里，根据二楼、三楼兄弟指出的问题修改了题目。(多谢指正)
        System.out.print(str + " and ");
        System.out.println(ch);
    }
   
    public static void change(String str, char ch[])
    {
        str="Changed"; ch[0]='C';
    }
}

What is the result after execution?
A. World and Hello
B. World and Cello
C. Changed and Hello
D. Changed and Cello

其他同事回信解释，涉及到“final class”和“不变类”两个概念。看来非常基础的概念也不是所有人都清楚，此次我把我回信的内容放在博客中，做个备份。可能会对非常非常初学的初学者有用。

String类是final的没错，这只是说明它不能够被其他类extends。跟这里的题目是没有关系的。

同时，String是不变类。没有任何一个语句可以在已经生成的String对象上做改变。比如"CC"是一个String对象，不可能有语句把"CC"的，比方说，第二个字符由"C"改成，比方说，"A"；"CC"自从它被初始化，就永远是"CC"，"CA"是另一个对象。是不是不变类，跟这里的题目也没关系。

再比如另一段代码:

public static void main(String[] args) {
    Person p = new Person("me");
    change(p);
    System.out.print(p.getName());//应该打印什么？
}

public static void change(Person p) {
    p = new Person("another one");
    p.setName("third one");
}

class Person {
    private String name;
    Person(String aName) {
        name = aName;
    }
    void setName(String aName) {//可以看出，Person不是不变类。
        name = aName;
    }
    String getName() {
        return name;
    }
}

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

外部接口没有变化，但内部实现“偷偷”变化了。其实也不是“偷偷”，更应该光明正大地告诉人家，你是经过装饰的，虽然都有“显示鼻子”的接口方法，但你的鼻子可能是垫了东西的。
需要注意的是，修饰过的类和被修饰的类是同类的。比如，实现相同的接口。
装饰过的类要拥有一个未被装饰类的属性。即关联关系。（合成还是聚合我就懒得区分了。）
装饰过的类的方法通常要在未被装饰类的方法基础上做点手脚，以体现装饰。

顺着脑子想到的一个例子，接口PriceGetter，定义了一个方法int getPrice()。
CommonPriceGetter是实现该接口、正常计算价格的。而95DiscountPriceGetter也实现PriceGetter接口，只是计算出来的价格都是打过95折的。具体实现也很容易想到，95DiscountPriceGetter类拥有一个PriceGetter类型的属性，实例化时候塞一个CommonPriceGetter实例给他，getPrice方法在该实例同名方法返回值的基础上乘以0.95返回，即达到目的。
客户端可以任意选择使用那个类实例计算价格，但都是PriceGetter接口的实例，客户端是依赖于抽象的。

书中关于Adapter与Decorator区别的描述也有点意思。
前者是做手脚把让已有类满足其他接口；后者是在已有类实现接口不变的情况下，做手脚使得方法实现发生变化。前者是芯子不变换外观，后者是外观不变换芯子。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

周末再翻《Java与模式》，说说对创建类模式的一点理解。大家交流。

创建类模式，我主要关注的是Simple Factory、Factory Method、Builder这几个。
当然，其他一些模式可能更加常用，比如Singleton、Prototype，但比较简单，不涉及整体脉络，此处略去不述。

首先，说说Simple Factory。
创建类模式，都是对实例创建过程的封装。
Simple Factory，是最容易想到的封装方式，Client无需知道某类的instance是怎么弄出来的，直接跟工厂要实例就行了，而且是静态方法，调用起来也方便。此时，工厂(书中叫做Creator)挑起重担，何时创建什么实例、如何创建全部由他来操办。
当工厂的担子越来越重时，比如，产品种类猛增、各个产品实例的创建过程都比较复杂、判断创建何种产品实例的逻辑也越来越复杂，工厂的改动日趋频繁，而且严重地违反了Open-Close法则，不同产品类的创建代码互相影响，这就说明对变化的封装没有达到应用的效果，产品A的变化影响到了产品B。对Simple Factory的优化产生了Factory Method。

Factory Method。
不同产品的创建过程既然都有着各不相同的单独逻辑，很容易想到把这些各自繁衍的变化封装起来，于是，不同的产品由配套的Creator来创建实例。此时，系统更加复合Open-Cloase法则，增加了新产品，同时增加相应的Creator，他们都位于继承结构的叶子端，不影响枝干和其他兄弟叶子。
但，此时，Client就需要知道哪个产品是使用哪个Creator来获得实例的了。让Client知道得多了，并不一定是坏事，个人感觉这里的情况是更加符合接口隔离原则，获得了该原则带来的优势。

Abstract Factory。
用于产品系列，个人不是很喜欢这个模式。当然也欢迎大家讨论。该模式此处不述。

Builder。
如果某类的实例创建需要固定的几个步骤(我理解为几道工序或者几个零件)，想到将生产、组装过程分开(脱开耦合、增加可插入性)，再参考Template Method模式的思路，就产生了Builder模式。

再罗索一遍，创建类模式都是对实例创建过程的封装，不同模式适用于不同情况，使用得是否得当我觉得就是看对变化的封装做得好不好。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

以前写邮件的时候，很多同事都说软件产品的质量属性太多。

周末重看《Java与模式》，发现阎宏博士的一些简短归纳，感觉有些道理，可作参考。

阎宏认为，比较重要的质量属性为可维护性和可重用性。可维护性又分为：可扩展性、灵活性、可插入性。
我认为，可维护性，分为：可读性、可扩展性、可修改性、可插入性，将更加圆整、更加容易理解。
首先，代码要可读，可读才可理解，可理解才可维护。其余的可扩展性、可修改性、可插入性是对系统增加新零件、修改原有零件、更换原有零件的支持，支持了这三种对系统的维护方式，系统当然就可维护了。

另外，我觉得还有一个比较重要的质量属性，是可测试性。不过，怎么样才更加可测试？我还暂时还没有让自己满意的想法。
一般来讲，可插入性好会比较容易测试，因为可以较容易地插入Mock对象模拟系统行为。其次，变化封装得好将更加容易测试，否则，多种干着不同事情的逻辑混杂在一个方法中，显然不容易测试。

参考文献：阎宏《Java与模式》

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Open-Close原则
是一个愿景性质的原则，如果系统能够达到Open-Close原则描述的情形就比较理想了，对扩展开放、对修改关闭，即，不修改原有代码即可完成对系统的扩展。
实现Open-Closed原则，抽象化是关键。
抽象层，因为抽象所以稳定。不变应万变，不用修改，满足Open-Closed原则的Closed一头。
抽象层的具体实现层可以满足扩展要求，满足Open-Closed原则的Open一头。
Open-Closed原则还可表述为“对可变性的封装”原则。“找到一个系统的可变因素，将它封装起来。”
一个可变性因素，不应该被散落在各个角落，而应该被封装到一个对象中。
一种可变性因素，不应该与另一种可变性因素混和在一起，而应各自独立开。
但，单从原则本身来说，它并没有告诉我们如何才能够让系统满足这个原则。

里氏代换原则
指导我们如何去构建一个extends(继承、派生)结构。
子类与父类的关系必须是is-A，即，子类必须在任何场合都敢于大声宣称自己起码(至少)是一个父类。比如，假设某类结构，“男人”、“女人”从“人”派生出来，看起来就是满足里氏代换原则的，因为无论“男人”还是“女人”，在任何场合都是“人”。这个原则大多数情况下，可以用现实世界中的概念来思考，但软件世界与显示世界毕竟有区别，比如，书中的例子，“正方形是不是矩形”问题。
此外，很多问题需要利用OO核心思想来灵活考虑，还是书中的例子(我只说大概意思，可能与书中描述存在差异)，一个类结构，“职工、普通职员、项目经理、科长、部长……”，从“员工”类派生出来，从一般概念来看还不错，职工和部长都是员工嘛，但这里隐含问题，现实世界中，普通职员可能变成项目经理，但软件世界中，普通职员和项目经理被规划成两个类了，于是一个普通职员instance是很难变成项目经理instance的，这说明我们把显示世界映射为软件世界时，出现了问题。更加合理的做法是，把这些职务(角色)抽象出来，比如叫做“职务”类(interface/abstract class)，所有职务从其派生，员工类、职务类是关联关系，任何一个员工实例都一个职务实例作为它的属性，这样就对了，员工的职务是可以变化的。实现这个重构的依据，是OO中的封装变化思想，以及从中演化出来的依赖倒换原则、合成/聚合复用原则。
但凡涉及到extends结构的设计模式都符合着里氏代换原则：
策略模式：一组算法，把他们封装成对象，使之可以互换（满足同一接口，即都is-A这个接口）。
合成模式：Leaf和Composite都is-A Component，于是才可能方便地层层嵌套。
代理模式：Proxy与RealSubject都is-A父类Subject，于是可以插入代理，完成附加功能。
……

依赖倒换原则
很具体地指导我们对抽象类(接口)、实现类的使用。
依赖于抽象的实体(interface/abstract class)，才能够更具有可插入性(但凡实现既有接口的实现类实例都可以在依赖此接口的地方以此接口实例的角色插入进来)，更容易满足Open-Close原则(抽象的层次不变化、实现的层次由于使用不同的类来封装不同的变化，于是可以在增加新类作为扩展的同时不需要修改已有实现类)。

接口隔离原则
这个原则比较孤立，也是从OO封装变化思想演化出来的，要将变化封装到最“贴身”。比如，A/B接口可能在大多数情况下都由同一个实现类提供，但某些情况下，B接口都有些实现类是没有意义的，这时候就需要把A/B分开作为两个接口，某些类实现全部A/B接口、某些类仅实现A接口。A/B单独变化，于是把A/B单独封装，接口隔离。

合成/聚合复用原则
与里氏代换原则关系较为紧密，里氏代换原则告诉我们什么情况下使用extends，在不满足里氏代换原则时，还想达到重用的目的，就引出合成/聚合复用原则。上文中，员工与职务的例子，来说明这个事儿就比较合适。
从复用角度来说：“合成/聚合复用”比“继承”复用灵活。前者是动态复用（因而具有可插入性）、后者是静态复用（编译时就固定了复用关系），而且后者的复用有“不支持多重继承”的限制。

迪米特法则
用于解开类之间的不必要的耦合。“不要与陌生人说话”。说起来容易，实际操作的时候很可能出现些无所适从的问题，而解开类之间的耦合是比较重要的，目前我们设计类的时候，增加属性、增加对其他类的调用都比较随意，不太好。
迪米特法则要求：一个对象应当对其他对象有尽可能少的了解。几种其他的表述：只与你直接的朋友通信、不要跟“陌生人”说话（冯远征？）
每个软件单位对其他单位都具有最少的知识，而且局限于那些与本单位密切相关的软件单位。
狭义迪米特法则-规定了谁是Friends、谁是Stranger。Friends圈子包括：
当前对象自身（this）、Instance field（如果field是Map、List等容器类型，则容器内的对象也是朋友）、当前对象创建的对象（调用其构造方法）、当前对象方法的参数对象。
只跟Friends说话，跟Stranger说的话由Friends转述。
狭义迪米特法则的弊端：传递间接调用的小方法太多！解决办法：遵循依赖倒换原则做些折衷处理，让对象依赖于Stranger的抽象层。虽然没有完全断开耦合，至少降低了耦合。

小结
Open-Close原则是比较总体的要求、是愿景。
实现Open-Close原则的关键，是抽象。
依赖倒换原则就是强调抽象的。
有了抽象层，就要有实现层，实现层无疑要从抽象层extends/implements，实现层/抽象层的关系，要依从里氏代换原则。
很多情况不满足里氏代换原则，又要实现复用，于是引出，合成/聚合复用原则。
两外两个原则是说类之间(接口)关系的。
接口隔离原则，要求类之间的接口更加狭窄，更加确切、更加合身地封装变化。
迪米特法则，要求类之间的接口应该发生在哪些类之间，不应该发生在哪些类之间。帮助我们解开类之间的耦合。

参考文献：
阎宏《Java与模式》
Meilir Page-Jones《UML面向对象设计基础》

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师