此城市区域内容可以配合ip.taobao.com api 使用.

表引擎myisam。有些字段没有添加索引，用的时候根据实际情况做修改。

area.sql

false.toString(); // 'false'
[1, 2, 3].toString(); // '1,2,3'

function Foo(){}
Foo.bar = 1;
Foo.bar; // 1

2.toString(); // 出错：SyntaxError

2..toString(); // 第二个点号可以正常解析
2 .toString(); // 注意点号前面的空格
(2).toString(); // 2先被计算

var foo = {}; // 一个空对象

// 一个新对象，拥有一个值为12的自定义属性'test'
var bar = {test: 12}; 

var foo = {name: 'kitten'}
foo.name; // kitten
foo['name']; // kitten

var get = 'name';
foo[get]; // kitten

foo.1234; // SyntaxError
foo['1234']; // works

var obj = {
    bar: 1,
    foo: 2,
    baz: 3
};
obj.bar = undefined;
obj.foo = null;
delete obj.baz;

for(var i in obj) {
    if (obj.hasOwnProperty(i)) {
        console.log(i, '' + obj[i]);
    }
}

var test = {'case': 'I am a keyword so I must be notated as a string',
    delete: 'I am a keyword too so me' // 出错：SyntaxError
};

function Foo() {
    this.value = 42;
}
Foo.prototype = {
    method: function() {}
};

function Bar() {}

// 设置Bar的prototype属性为Foo的实例对象
Bar.prototype = new Foo();
Bar.prototype.foo = 'Hello World';

// 修正Bar.prototype.constructor为Bar本身
Bar.prototype.constructor = Bar;

var test = new Bar() // 创建Bar的一个新实例

// 原型链
test [Bar的实例]
    Bar.prototype [Foo的实例] 
        { foo: 'Hello World' }
        Foo.prototype
            {method: ...};
            Object.prototype
                {toString: ... /* etc. */};

function Foo() {}
Foo.prototype = 1; // 无效

// 修改Object.prototype
Object.prototype.bar = 1; 
var foo = {goo: undefined};

foo.bar; // 1
'bar' in foo; // true

foo.hasOwnProperty('bar'); // false
foo.hasOwnProperty('goo'); // true

var foo = {
    hasOwnProperty: function() {
        return false;
    },
    bar: 'Here be dragons'
};

foo.hasOwnProperty('bar'); // 总是返回 false

// 使用其它对象的 hasOwnProperty，并将其上下文设置为foo
({}).hasOwnProperty.call(foo, 'bar'); // true

// 修改 Object.prototype
Object.prototype.bar = 1;

var foo = {moo: 2};
for(var i in foo) {
    console.log(i); // 输出两个属性：bar 和 moo
}

// foo 变量是上例中的
for(var i in foo) {
    if (foo.hasOwnProperty(i)) {
        console.log(i);
    }
}

function foo() {}

foo(); // 正常运行，因为foo在代码运行前已经被创建
function foo() {}

var foo = function() {};

foo; // 'undefined'
foo(); // 出错：TypeError
var foo = function() {};

var foo = function bar() {
    bar(); // 正常运行
}
bar(); // 出错：ReferenceError

this;

foo();

test.foo(); 

new foo(); 

function foo(a, b, c) {}

var bar = {};
foo.apply(bar, [1, 2, 3]); // 数组将会被扩展，如下所示
foo.call(bar, 1, 2, 3); // 传递到foo的参数是：a = 1, b = 2, c = 3

Foo.method = function() {
    function test() {
        // this 将会被设置为全局对象（译者注：浏览器环境中也就是 window 对象）
    }
    test();
}

Foo.method = function() {
    var that = this;
    function test() {
        // 使用 that 来指向 Foo 对象
    }
    test();
}

var test = someObject.methodTest;
test();

function Foo() {}
Foo.prototype.method = function() {};

function Bar() {}
Bar.prototype = Foo.prototype;

new Bar().method();

function Counter(start) {
    var count = start;
    return {
        increment: function() {
            count++;
        },

        get: function() {
            return count;
        }
    }
}

var foo = Counter(4);
foo.increment();
foo.get(); // 5

var foo = new Counter(4);
foo.hack = function() {
    count = 1337;
};

for(var i = 0; i < 10; i++) {
    setTimeout(function() {
        console.log(i);  
    }, 1000);
}

for(var i = 0; i < 10; i++) {
    (function(e) {
        setTimeout(function() {
            console.log(e);  
        }, 1000);
    })(i);
}

for(var i = 0; i < 10; i++) {
    setTimeout((function(e) {
        return function() {
            console.log(e);
        }
    })(i), 1000)
}

Array.prototype.slice.call(arguments);

function foo() {
    bar.apply(null, arguments);
}
function bar(a, b, c) {
    // do stuff here
}

function Foo() {}

Foo.prototype.method = function(a, b, c) {
    console.log(this, a, b, c);
};

// Create an unbound version of "method" 
// 输入参数为: this, arg1, arg2...argN
Foo.method = function() {

    // 结果: Foo.prototype.method.call(this, arg1, arg2... argN)
    Function.call.apply(Foo.prototype.method, arguments);
};

Foo.method = function() {
    var args = Array.prototype.slice.call(arguments);
    Foo.prototype.method.apply(args[0], args.slice(1));
};

function foo(a, b, c) {
    arguments[0] = 2;
    a; // 2                                                           

    b = 4;
    arguments[1]; // 4

    var d = c;
    d = 9;
    c; // 3
}
foo(1, 2, 3);

// 阐述在 ES5 的严格模式下 `arguments` 的特性
function f(a) {
  "use strict";
  a = 42;
  return [a, arguments[0]];
}
var pair = f(17);
assert(pair[0] === 42);
assert(pair[1] === 17);

function foo() {
    arguments.callee; // do something with this function object
    arguments.callee.caller; // and the calling function object
}

function bigLoop() {
    for(var i = 0; i < 100000; i++) {
        foo(); // Would normally be inlined...
    }
}

function Foo() {
    this.bla = 1;
}

Foo.prototype.test = function() {
    console.log(this.bla);
};

var test = new Foo();

function Bar() {
    return 2;
}
new Bar(); // 返回新创建的对象

function Test() {
    this.value = 2;

    return {
        foo: 1
    };
}
new Test(); // 返回的对象

function Bar() {
    return new Number(2);
}
new Bar().constructor === Number

(new Test()).value === undefined
(new Test()).foo === 1

function Foo() {
    this.bla = 1; // 获取设置全局参数
}
Foo(); // undefined

function Bar() {
    var value = 1;
    return {
        method: function() {
            return value;
        }
    }
}
Bar.prototype = {
    foo: function() {}
};

new Bar();
Bar();

var bar1 = new Bar();
typeof(bar1.method); // "function"
typeof(bar1.foo); // "undefined"

var bar2 = Bar();
typeof(bar2.method); // "function"
typeof(bar2.foo); // "undefined"

function Foo() {
    var obj = {};
    obj.value = 'blub';

    var private = 2;
    obj.someMethod = function(value) {
        this.value = value;
    }

    obj.getPrivate = function() {
        return private;
    }
    return obj;
}

function test() { // 一个作用域
    for(var i = 0; i < 10; i++) { // 不是一个作用域
        // count
    }
    console.log(i); // 10
}

// 译者注：下面输出 undefined
function add(a, b) {
    return 
        a + b;
}
console.log(add(1, 2));

// 脚本 A
foo = '42';

// 脚本 B
var foo = '42'

// 全局作用域
var foo = 42;
function test() {
    // 局部作用域
    foo = 21;
}
test();
foo; // 21

// 全局作用域
var items = [/* 数组 */];
for(var i = 0; i < 10; i++) {
    subLoop();
}

function subLoop() {
    // subLoop 函数作用域
    for(i = 0; i < 10; i++) { // 没有使用 var 声明变量
        // 干活
    }
}

// 全局变量
var foo = 1;
var bar = 2;
var i = 2;

function test(i) {
    // 函数 test 内的局部作用域
    i = 5;

    var foo = 3;
    bar = 4;
}
test(10);

bar();
var bar = function() {};
var someValue = 42;

test();
function test(data) {
    if (false) {
        goo = 1;

    } else {
        var goo = 2;
    }
    for(var i = 0; i < 100; i++) {
        var e = data[i];
    }
}

// var 表达式被移动到这里
var bar, someValue; // 缺省值是 'undefined'

// 函数声明也会提升
function test(data) {
    var goo, i, e; // 没有块级作用域，这些变量被移动到函数顶部
    if (false) {
        goo = 1;

    } else {
        goo = 2;
    }
    for(i = 0; i < 100; i++) {
        e = data[i];
    }
}

bar(); // 出错：TypeError，因为 bar 依然是 'undefined'
someValue = 42; // 赋值语句不会被提升规则（hoisting）影响
bar = function() {};

test();

// 检查 SomeImportantThing 是否已经被初始化
if (!SomeImportantThing) {
    var SomeImportantThing = {};
}

var SomeImportantThing;

// 其它一些代码，可能会初始化 SomeImportantThing，也可能不会

// 检查是否已经被初始化
if (!SomeImportantThing) {
    SomeImportantThing = {};
}

// 译者注：来自 Nettuts+ 的一段代码，生动的阐述了 JavaScript 中变量声明提升规则
var myvar = 'my value';  

(function() {  
    alert(myvar); // undefined  
    var myvar = 'local value';  
})();  

(function() {
    // 函数创建一个命名空间

    window.foo = function() {
        // 对外公开的函数，创建了闭包
    };

})(); // 立即执行此匿名函数

( // 小括号内的函数首先被执行
function() {}
) // 并且返回函数对象
() // 调用上面的执行结果，也就是函数对象

// 另外两种方式
+function(){}();
(function(){}());

var list = [1, 2, 3, 4, 5, ...... 100000000];
for(var i = 0, l = list.length; i < l; i++) {
    console.log(list[i]);
}

var foo = [1, 2, 3, 4, 5, 6];
foo.length = 3;
foo; // [1, 2, 3]

foo.length = 6;
foo; // [1, 2, 3]

// 译者注：为了验证，我们来执行下面代码，看序号 5 是否存在于 foo 中。
5 in foo; // 不管在 Firebug 或者 Chrome 都返回 false
foo[5] = undefined;
5 in foo; // 不管在 Firebug 或者 Chrome 都返回 true

[1, 2, 3]; // 结果: [1, 2, 3]
new Array(1, 2, 3); // 结果: [1, 2, 3]

[3]; // 结果: [3]
new Array(3); // 结果: [] 
new Array('3') // 结果: ['3']

// 译者注：因此下面的代码将会使人很迷惑
new Array(3, 4, 5); // 结果: [3, 4, 5] 
new Array(3) // 结果: []，此数组长度为 3

var arr = new Array(3);
arr[1]; // undefined
1 in arr; // false, 数组还没有生成

new Array(count + 1).join(stringToRepeat);

""           ==   "0"           // false
0            ==   ""            // true
0            ==   "0"           // true
false        ==   "false"       // false
false        ==   "0"           // true
false        ==   undefined     // false
false        ==   null          // false
null         ==   undefined     // true" \t\r\n"    ==   0             // true

""           ===   "0"           // false
0            ===   ""            // false
0            ===   "0"           // false
false        ===   "false"       // false
false        ===   "0"           // false
false        ===   undefined     // false
false        ===   null          // false
null         ===   undefined     // false" \t\r\n"    ===   0             // false

{} === {};                   // false
new String('foo') === 'foo'; // false
new Number(10) === 10;       // false
var foo = {};
foo === foo;                 // true

Value               Class      Type
-------------------------------------"foo"               String     string
new String("foo")   String     object
1.2                 Number     number
new Number(1.2)     Number     object
true                Boolean    boolean
new Boolean(true)   Boolean    object
new Date()          Date       object
new Error()         Error      object
[1,2,3]             Array      object
new Array(1, 2, 3)  Array      object
new Function("")    Function   function
/abc/g              RegExp     object (function in Nitro/V8)
new RegExp("meow")  RegExp     object (function in Nitro/V8)
{}                  Object     object
new Object()        Object     object

function is(type, obj) {
    var clas = Object.prototype.toString.call(obj).slice(8, -1);
    return obj !== undefined && obj !== null && clas === type;
}

is('String', 'test'); // true
is('String', new String('test')); // true

Object.prototype.toString.call([])    // "[object Array]"
Object.prototype.toString.call({})    // "[object Object]"
Object.prototype.toString.call(2)    // "[object Number]"

// IE8
Object.prototype.toString.call(null)    // "[object Object]"
Object.prototype.toString.call(undefined)    // "[object Object]"

// Firefox 4
Object.prototype.toString.call(null)    // "[object Null]"
Object.prototype.toString.call(undefined)    // "[object Undefined]"

typeof foo !== 'undefined'

function Foo() {}
function Bar() {}
Bar.prototype = new Foo();

new Bar() instanceof Bar; // true
new Bar() instanceof Foo; // true

// 如果仅仅设置 Bar.prototype 为函数 Foo 本身，而不是 Foo 构造函数的一个实例
Bar.prototype = Foo;
new Bar() instanceof Foo; // false

new String('foo') instanceof String; // true
new String('foo') instanceof Object; // true'foo' instanceof String; // false'foo' instanceof Object; // false

// 下面的比较结果是：true
new Number(10) == 10; // Number.toString() 返回的字符串被再次转换为数字

10 == '10';           // 字符串被转换为数字
10 == '+10 ';         // 同上
10 == '010';          // 同上 
isNaN(null) == false; // null 被转换为数字 0
                      // 0 当然不是一个 NaN（译者注：否定之否定）

// 下面的比较结果是：false
10 == 010;
10 == '-10';

new Number(10) === 10;     // False, 对象与数字的比较
Number(10) === 10;         // True, 数字与数字的比较
new Number(10) + 0 === 10; // True, 由于隐式的类型转换

'' + 10 === '10'; // true

+'10' === 10; // true

+'010' === 10
Number('010') === 10
parseInt('010', 10) === 10  // 用来转换为整数

+'010.2' === 10.2
Number('010.2') === 10.2
parseInt('010.2', 10) === 10

!!'foo';   // true
!!'';      // false
!!'0';     // true
!!'1';     // true
!!'-1'     // true
!!{};      // true
!!true;    // true

var foo = 1;
function test() {
    var foo = 2;
    eval('foo = 3');
    return foo;
}
test(); // 3
foo; // 1

var foo = 1;
function test() {
    var foo = 2;
    var bar = eval;
    bar('foo = 3');
    return foo;
}
test(); // 2
foo; // 3

// 写法一：直接调用全局作用域下的 foo 变量
var foo = 1;
function test() {
    var foo = 2;
    window.foo = 3;
    return foo;
}
test(); // 2
foo; // 3

// 写法二：使用 call 函数修改 eval 执行的上下文为全局作用域
var foo = 1;
function test() {
    var foo = 2;
    eval.call(window, 'foo = 3');
    return foo;
}
test(); // 2
foo; // 3

var undefined = 123;
(function(something, foo, undefined) {
    // 局部作用域里的 undefined 变量重新获得了 `undefined` 值

})('Hello World', 42);

var undefined = 123;
(function(something, foo) {
    var undefined;
    ...

})('Hello World', 42);

var foo = function() {
} // 解析错误，分号丢失
test()

var foo = function() {
}; // 没有错误，解析继续
test()

(function(window, undefined) {
    function test(options) {
        log('testing!')

        (options.list || []).forEach(function(i) {

        })

        options.value.test(
            'long string to pass here','and another long string to pass'
        )

        return
        {
            foo: function() {}
        }
    }
    window.test = test

})(window)

(function(window) {
    window.someLibrary = {}
})(window)

(function(window, undefined) {
    function test(options) {

        // 没有插入分号，两行被合并为一行
        log('testing!')(options.list || []).forEach(function(i) {

        }); // <- 插入分号

        options.value.test(
            'long string to pass here','and another long string to pass'
        ); // <- 插入分号

        return; // <- 插入分号, 改变了 return 表达式的行为
        { // 作为一个代码段处理
            foo: function() {} 
        }; // <- 插入分号
    }
    window.test = test; // <- 插入分号

// 两行又被合并了
})(window)(function(window) {
    window.someLibrary = {}; // <- 插入分号
})(window); //<- 插入分号

log('testing!')
(options.list || []).forEach(function(i) {})

log('testing!')(options.list || []).forEach(function(i) {})

function foo() {}
var id = setTimeout(foo, 1000); // 返回一个大于零的数字

function Foo() {
    this.value = 42;
    this.method = function() {
        // this 指向全局对象
        console.log(this.value); // 输出：undefined
    };
    setTimeout(this.method, 500);
}
new Foo();

function foo(){
    // 阻塞执行 1 秒
}
setInterval(foo, 1000);

function foo(){
    // 阻塞执行 1 秒
    setTimeout(foo, 1000);
}
foo();

var id = setTimeout(foo, 1000);
clearTimeout(id);

// 清空"所有"的定时器
for(var i = 1; i < 1000; i++) {
    clearTimeout(i);
}

function foo() {
    // 将会被调用
}

function bar() {
    function foo() {
        // 不会被调用
    }
    setTimeout('foo()', 1000);
}
bar();

function foo(a, b, c) {}

// 不要这样做
setTimeout('foo(1,2, 3)', 1000)

// 可以使用匿名函数完成相同功能
setTimeout(function() {
    foo(a, b, c);
}, 1000)

• —软件人才免语言低担保 赴美带薪读研！—

　　在设计面向对象的程序的时，模式不是一定要套的，但是有一些原则最好是遵守。这些原则已知的有七个，包括：开闭原则、里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则，单一职责原则。

　　原则简介

　　其中Robert C. Martin引入了SOLID的说法，包括了其中的五个原则。另外两个，这里把他们算成额外的两个规则。具体如下。

　　S . Single Responsibility Principle - SRP
　　An object should have only a single responsibility.

　　O . Open-Closed Principle - OCP
　　Software entities should be opened for extension, but closed for modification.

　　L . Liskvo Substitution Principle - LSP
　　If S is a subtype of T, the objects of T in a program may be replaced by objects of Type S.

　　I . Interface Segregation Principle - ISP
　　many client specific interfaces are better than one general purpose interface.

　　D . Dependency Inversion Principle - DIP
　　Depend upon abstractions. Do not depend upon concretions.
　　Program to an interface, not an implementation.

　　Ex1 . Law of Demeter - LoD
  　 -- Principle of Least Knowledge
　　A given object should assume as little as possible about the structure or properties of anything else.

　　Ex2 . Composite/Aggregate Reuse Principle - CARP
　　Use most composition and aggregation, less inheritance.

　　按照个人理解，把这七个原则分成了以下两个部分。

　　Design Method: SRP ISP DIP CARP
　　Design Goal:   OCP LSP LoD

　　各规则详细(本部分为转载)

　　正如牛顿三大定律在经典力学中的位置一样，“开-闭”原则（Open-Closed Principle）是面向对象的可复用设计（Object Oriented Design或OOD）的基石。其他设计原则（里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则）是实现“开-闭”原则的手段和工具。

　　 一、“开-  闭”原则（Open-Closed Principle,OCP  ）

　　1.1  “开-  闭” 原则的定义及优点

　　1）定义：一个软件实体应当对扩展开放，对修改关闭( Software entities should be open for extension, but closed for modification.)。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。

　　2）满足“开-闭”原则的系统的优点

　　　　a) 通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。

　　　　b) 已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。

　　　　c) 这样的系统同时满足了可复用性与可维护性。

　　1.2  如何实现“开-闭” 原则

　　在面向对象设计中，不允许更改的是系统的抽象层，而允许扩展的是系统的实现层。换言之，定义一个一劳永逸的抽象设计层，允许尽可能多的行为在实现层被实现。

　　解决问题关键在于抽象化，抽象化是面向对象设计的第一个核心本质。

　　对一个事物抽象化，实质上是在概括归纳总结它的本质。抽象让我们抓住最最重要的东西， 从更高一层去思考。这降低了思考的复杂度，我们不用同时考虑那么多的东西。换言之，我们封装了事物的本质，看不到任何细节。

　　在面向对象编程中，通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需更改，从而满足“对修改关闭”；而从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。

　　对实体进行扩展时，不必改动软件的源代码或者二进制代码。关键在于抽象。

　　1.3  对可变性的封装原则

　　“开-闭”原则也就是“对可变性的封装原则”（Principle of Encapsulation of Variation ，EVP）。即找到一个系统的可变因素，将之封装起来。换言之，在你的设计中什么可能会发生变化，应使之成为抽象层而封装，而不是什么会导致设计改变才封装。

      “对可变性的封装原则”意味着：

　　a) 一种可变性不应当散落在代码的许多角落，而应当被封装到一个对象里面。同一可变性的不同表象意味着同一个继承等级结构中的具体子类。因此，此处可以期待继承关系的出现。继承是封装变化的方法，而不仅仅是从一般的对象生成特殊的对象。

　　b) 一种可变性不应当与另一种可变性混合在一起。作者认为类图的继承结构如果超过两层，很可能意味着两种不同的可变性混合在了一起。

　　使用“可变性封装原则”来进行设计可以使系统遵守“开-闭”原则。

　　即使无法百分之百的做到“开-闭”原则，但朝这个方向努力，可以显著改善一个系统的结构。

　　二、里氏代换原则（Liskov Substitution Principle, LSP）

　　2.1  概念

　　定义：如果对每一个类型为 T1 的对象 O1 ，都有类型为 T2 的对象 O2 ，使得以 T1 定义的所有程序 P 在所有的对象 O1 都代换为 O2 时，程序 P 的行为没有变化，那么类型 T2 是类型 T1 的子类型。

　　即，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类。而且它觉察不出基类对象和子类对象的区别。 也就是说，在软件里面，把基类都替换成它的子类，程序的行为没有变化。

　　反过来的代换不成立，如果一个软件实体使用的是一个子类的话，那么它不一定适用于基类。

　　任何基类可以出现的地方，子类一定可以出现。

　　基于契约的设计、抽象出公共部分作为抽象基类的设计。

　　2.2  里氏代换原则与“开-  闭” 原则的关系

　　实现“开-闭”原则的关键步骤是抽象化。基类与子类之间的继承关系就是抽象化的体现。因此里氏代换原则是对实现抽象化的具体步骤的规范。

　　违反里氏代换原则意味着违反了“开-闭”原则，反之未必。

　　三、 依赖倒转原则  （  dependence inversion principle, DIP  ）

　　3.1  概念

　　依赖倒转原则就是要依赖于抽象，不要依赖于实现。（Abstractions should not depend upon details. Details should depend upon abstractions.）要针对接口编程，不要针对实现编程。（Program to an interface, not an implementation.）

　　也就是说应当使用接口和抽象类进行变量类型声明、参数类型声明、方法返还类型说明，以及数据类型的转换等。而不要用具体类进行变量的类型声明、参数类型声明、方法返还类型说明，以及数据类型的转换等。要保证做到这一点，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余的方法。

　　传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块，抽象层次依赖于具体层次。倒转原则就是把这个错误的依赖关系倒转过来。

　　面向对象设计的重要原则是创建抽象化，并且从抽象化导出具体化，具体化给出不同的实现。继承关系就是一种从抽象化到具体化的导出。

　　抽象层包含的应该是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现。具体层次含有的是一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层次的代码是经常变动的，不能避免出现错误。

　　从复用的角度来说，高层次的模块是应当复用的，而且是复用的重点，因为它含有一个应用系统最重要的宏观商务逻辑，是较为稳定的。而在传统的过程性设计中，复用则侧重于具体层次模块的复用。

　　依赖倒转原则则是对传统的过程性设计方法的“倒转”，是高层次模块复用及其可维护性的有效规范。

　　特例：对象的创建过程是违背“开—闭”原则以及依赖倒转原则的，但通过工厂模式，能很好地解决对象创建过程中的依赖倒转问题。

　　3.2  关系

　　“开-闭”原则与依赖倒转原则是目标和手段的关系。如果说开闭原则是目标，依赖倒转原则是到达"开闭"原则的手段。如果要达到最好的"开闭"原则，就要尽量的遵守依赖倒转原则，依赖倒转原则是对"抽象化"的最好规范。

　　里氏代换原则是依赖倒转原则的基础，依赖倒转原则是里氏代换原则的重要补充。

　　3.3  耦合（或者依赖）关系的种类：

　　零耦合（Nil Coupling）关系：两个类没有耦合关系。

　　具体耦合（Concrete Coupling）关系：发生在两个具体的（可实例化的）类之间，经由一个类对另一个具体类的直接引用造成。

　　抽象耦合（Abstract Coupling）关系：发生在一个具体类和一个抽象类（或接口）之间，使两个必须发生关系的类之间存有最大的灵活性。

　　3.3.1 如何把握耦合

　　我们应该尽可能的避免实现继承，原因如下：

　　1) 失去灵活性，使用具体类会给底层的修改带来麻烦。

　　2) 耦合问题，耦合是指两个实体相互依赖于对方的一个量度。程序员每天都在（有意识地或者无意识地）做出影响耦合的决定：类耦合、API耦合、应用程序耦合等等。在一个用扩展的继承实现系统中，派生类是非常紧密的与基类耦合，而且这种紧密的连接可能是被不期望的。如B extends A ，当B不全用A中的所有methods时，这时候，B调用的方法可能会产生错误!

　　我们必须客观的评价耦合度，系统之间不可能总是松耦合的，那样肯定什么也做不了。

　　3.3.2 我们决定耦合的程度的依据何在呢 ？

　　简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的），因为这样可以提高效率， 而且我们还可以使用一些更好的技术来提高效率或简化代码，例如c#中的内部类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是抽象的类、具体的类，也可以是接口，或是一组的类。我们可以用一句话来概括降低耦合度的思想：“针对接口编程，而不是针对实现编程。”

　　在我们进行编码的时候，都会留下我们的指纹，如public的多少，代码的格式等等。 我们可以耦合度量评估重新构建代码的风险。因为重新构建实际上是维护编码的一种形式，维护中遇到的那些麻烦事在重新构建时同样会遇到。我们知道在重新构建 之后，最常见的随机bug大部分都是不当耦合造成的 。

　　如果不稳定因素越大，它的耦合度也就越大。

　　某类的不稳定因素=依赖的类个数/被依赖的类个数

　　依赖的类个数＝ 在编译此类的时被编译的其它类的个数总和

　　3.3.3 怎样将大系统拆分成小系统

　　解决这个问题的一个思路是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合，这是我们设计过程中应该着重考虑的问题！

　　耦合的目标是维护依赖的单向性，有时我们也会需要使用坏的耦合。在这种情况下，应当小心记录下原因，以帮助日后该代码的用户了解使用耦合真正的原因。

　　3.4  怎样做到依赖倒转？

　　以抽象方式耦合是依赖倒转原则的关键。抽象耦合关系总要涉及具体类从抽象类继承，并且需要保证在任何引用到基类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础。

　　在抽象层次上的耦合虽然有灵活性，但也带来了额外的复杂性，如果一个具体类发生变化的可能性非常小，那么抽象耦合能发挥的好处便十分有限，这时可以用具体耦合反而会更好。

　　层次化：所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供一组内聚的服务。

　　依赖于抽象：建议不依赖于具体类，即程序中所有的依赖关系都应该终止于抽象类或者接口。尽量做到：

　　1、任何变量都不应该持有一个指向具体类的指针或者引用。

　　2、任何类都不应该从具体类派生。

　　3、任何方法都不应该覆写它的任何基类中的已经实现的方法。

　　3.5  依赖倒转原则的优缺点

　　依赖倒转原则虽然很强大，但却最不容易实现。因为依赖倒转的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用可能还会导致产生大量的类，对不熟悉面向对象技术的工程师来说，维护这样的系统需要较好地理解面向对象设计。

　　依赖倒转原则假定所有的具体类都是会变化的，这也不总是正确。有一些具体类可能是相当 稳定，不会变化的，使用这个具体类实例的应用完全可以依赖于这个具体类型，而不必为此创建一个抽象类型。

　　四、合成/聚合复用原则（  Composite/Aggregate Reuse Principle  或  CARP  ）

      4.1  概念

　　定义：在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。

　　应首先使用合成/聚合，合成/聚合则使系统灵活，其次才考虑继承，达到复用的目的。而使用继承时，要严格遵循里氏代换原则。有效地使用继承会有助于对问题的理解，降低复杂度，而滥用继承会增加系统构建、维护时的难度及系统的复杂度。

　　如果两个类是“Has-a”关系应使用合成、聚合，如果是“Is-a”关系可使用继 承。"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，它表示某一个角色具有某一项责任。

　　4.2  什么是合成？什么是 聚合？

　　合成（Composition）和聚合（Aggregation）都是关联 （Association）的特殊种类。

　　聚合表示整体和部分的关系，表示“拥有”。如奔驰S360汽车，对奔驰S360引擎、奔驰S360轮胎的关系是聚合关系，离开了奔驰S360汽车，引擎、轮胎就失去了存在的意义。在设计中, 聚合不应该频繁出现，这样会增大设计的耦合度。

　　合成则是一种更强的“拥有”，部分和整体的生命周期一样。合成的新的对象完全支 配其组成部分，包括它们的创建和湮灭等。一个合成关系的成分对象是不能与另一个合成关系共享的。

    换句话说，合成是值的聚合（Aggregation by Value），而一般说的聚合是引用的聚合（Aggregation by Reference）。

　　明白了合成和聚合关系，再来理解合成/聚合原则应该就清楚了，要避免在系统设计中出现，一个类的继承层次超过3层，则需考虑重构代码，或者重新设计结构。当然最好的办法就是考虑使用合成/聚合原则。

　　4.3  通过合成/聚合的优缺点

　　优点：

　　1) 新对象存取成分对象的唯一方法是通过成分对象的接口。

　　2) 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的。

　　3) 这种复用支持包装。

　　4) 这种复用所需的依赖较少。

　　5) 每一个新的类可以将焦点集中在一个任务上。

　　6) 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。

　　7) 作为复用手段可以应用到几乎任何环境中去。

　　缺点：就是系统中会有较多的对象需要管理。

　　4.4  通过继承来进行复用的优缺点

　　优点：

　　1) 新的实现较为容易，因为超类的大部分功能可以通过继承的关系自动进入子类。

　　2) 修改和扩展继承而来的实现较为容易。

　　缺点 ：

　　1) 继承复用破坏封装，因为继承将超类的实现细节暴露给子类。由于超类的内部细节常常是对于子类透明的，所以这种复用是透明的复用，又称“白箱”复用。

　　2) 如果超类发生改变，那么子类的实现也不得不发生改变。

　　3) 从超类继承而来的实现是静态的，不可能在运行时间内发生改变，没有足够的灵活性。

　　4) 继承只能在有限的环境中使用。

　　五、 迪米特法则（  Law of Demeter  ，LoD ）

　　5.1  概述

　　定义：一个软件实体应当尽可能少的与其他实体发生相互作用。

　　这样，当一个模块修改时，就会尽量少的影响其他的模块。扩展会相对容易。

　　这是对软件实体之间通信的限制。它要求限制软件实体之间通信的宽度和深度。

　　5.2  迪米特法则的其他表述

　　1）只与你直接的朋友们通信。

　　2）不要跟“陌生人”说话。

　　3）每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

　　5.3  狭义的迪米特法则

　　如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

　　朋友圈的确定，“朋友”条件：

　　1）当前对象本身（this）

　　2）以参量形式传入到当前对象方法中的对象

　　3）当前对象的实例变量直接引用的对象

　　4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友

　　5）当前对象所创建的对象

　　任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”；否则就是“陌生 人”。

　　缺点：会在系统里造出大量的小方法，散落在系统的各个角落。

　　与依赖倒转原则互补使用。

　　5.4  狭义的迪米特法则的缺点：

　　在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。

　　遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

　　5.5  迪米特法则与设计模式

　　门面（外观）模式和调停者（中介者）模式实际上就是迪米特法则的具体应用。

　　5.6  广义的迪米特法则

　　迪米特法则的主要用意是控制信息的过载。在将迪米特法则运用到系统设计中时，要注意下面的几点：

　　1）在类的划分上，应当创建有弱耦合的类。

　　2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

　　3）在类的设计上，只要有可能，一个类应当设计成不变类。

　　4）在对其他类的引用上，一个对象对其对象的引用应当降到最低。

　　5.7  广义迪米特法则在类的设计的体现

　　1）优先考虑将一个类设置成不变类

　　2）尽量降低一个类的访问权限

　　3）谨慎使用Serializable

　　4）尽量降低成员的访问权限

　　5）取代C Struct

　　迪米特法则又叫作最少知识原则（Least Knowledge Principle或简写为LKP），就是说一个对象应当对其他对象有尽可能少的了解。

　　5.8  如何实现迪米特法则

　　迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点：

　　1) 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。

　　2) 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。

　　3) 在类的设计上，只要有可能，一个类应当设计成不变类。

　　4) 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。

　　六、 接口隔离原则（Interface Segregation Principle, ISP  ）

      6.1  概念

　　接口隔离原则：使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。     

　　这里的"接口"往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的"接口"定义，有严格的定义和结构。比如C#语言里面的Interface结构。对于这两种不同的含义，ISP的表达方式以及含义都有所不同。(上面说的一个类型，可以理解成一个类，我们定义了一个 类，也就是定义了一种新的类型)     

　　当我们把"接口"理解成一个类所提供的所有方法的特征集合的时候，这就是一种逻辑上的 概念。接口的划分就直接带来类型的划分。这里，我们可以把接口理解成角色，一个接口就只是代表一个角色，每个角色都有它特定的一个接口，这里的这个原则可以叫做"角色隔离原则"。

　　如果把"接口"理解成狭义的特定语言的接口，那么ISP表达的意思是说，对不同的客户端，同一个角色提供宽窄不同的接口，也就是定制服务，个性化服务。就是仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来。

　　应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。

　　这也是对软件实体之间通信的限制。但它限制的只是通信的宽度，就是说通信要尽可能的窄。

　　遵循迪米特法则和接口隔离原则，会使一个软件系统功能扩展时，修改的压力不会传 到别的对象那里。

　　6.2  如何实现接口隔离原则

　　不应该强迫用户依赖于他们不用的方法。

　　1、利用委托分离接口。

　　2、利用多继承分离接口。

　　七、单一职责原则(SRP)

　　单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。

　　在软件设计中，如果一个类承担的职责过多，就等于吧这些职责耦合在一起，而一个职责的变化可能会削弱和抑制这个类完成其他职责的能力。这耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 

　　软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果多于一个的动机去改变一个类，那么这个类就具有多余一个的职责，就应该要考虑类的职责分离。

　　小结

　　在我们进行面向对象系统的设计时，可以不去特意的考虑使用哪些设计模式，但是一定要尽量遵守这些设计原则。这样做的话，即使是设计经验不足，也比较容易设 计出易扩展的系统，并且可能自然的实现了某些模式。这种情况，恐怕算是很理想的一种设计了。

　　参考资料

　　1. 面向对象设计模式原则

　　2.  SOLID (object-oriented design)

GET /domains/example/ HTTP/1.1      //请求行: 请求方法 请求URI HTTP协议/协议版本
Host：www.iana.org             //服务端的主机名
User-Agent：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4   //告诉HTTP服务器， 客户端使用的操作系统和浏览器的名称和版本
Accept：text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8    //客户端能接收的mine
Accept-Encoding：gzip,deflate,sdch     //是否支持流压缩
Accept-Charset：UTF-8,*;q=0.5      //客户端字符编码集
//空行,用于分割请求头和消息体
//消息体,请求资源参数,例如POST传递的参数

HTTP/1.1 200 OK                     //状态行：HTTP协议版本号 状态码 状态消息
Server: nginx/1.0.8                 //服务器使用的WEB软件名及版本
Date:Date: Tue, 30 Oct 2012 04:14:25 GMT        //发送时间
Content-Type: text/html             //服务器发送信息的类型
Transfer-Encoding: chunked          //表示发送HTTP包是分段发的
Connection: keep-alive              //保持连接状态
Content-Length: 90                  //主体内容长度
//空行 用来分割消息头和主体
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"... //消息体

• —软件人才免语言低担保 赴美带薪读研！—

Windows下ADB使用相关问题

适用环境：

在Windows XP，WIN7下均可按本文操作进行；WIN8下没有进行实验，但操作设置大致相同，除了第4步，adb_usb.ini的位置可能有所不同以外，其他各部分可按文中所述进行操作。

Windows下正常使用ADB要注意以下问题：

1.      手机端要打开调试模式

在设置中，打开开发人员选项，并将其中的USB调试选项打开

2.     PC端安装设备驱动

各家设备的USB驱动可能有所不同，这里以展讯为例。

安装驱动时要先把设备与PC断开。

展讯USB驱动 AndroidSCI-android-usb-driver-jungo-v4.zip，解压后里面有详细的驱动安装说明，区分32位或者64位系统，根据不同系统选择各自适配的驱动，进行安装。

手机设备端同时会有如下提示，

程序安装完后，通过USB链接设备；

PC端会提示找到新硬件，正在安装驱动，等待PC端安装驱动成功。

然后在设备管理器中会有新的AndroidPhone

以下各图为驱动正常安装后设备管理器中状态

查看设备属性

可在此查看设备VID信息

3.    修改adb_usb.ini

在任务管理器中结束adb进程，或者在命令行窗口中执行adb kill-server，再进行下面的修改，以排除其可能产生的影响。

在模拟器存放的目录<例如：C:\Documents and Settings\Administrator\.android>下找到或新建一个adb_usb.ini文件，同时增加或写入上面设备的0xVID（VID就是上面的VID_后面跟的数字，例如：0x1782 （展讯USB设备VID）

4.   重启ADB服务

如果ADB命令工具路径已经添加到系统的环境变量中，可直接在打开的命令行窗口中进行下面的操作，如果ADB命令工具路径没有添加到系统的环境变量中，打开命令行窗口后，可切换到ADK所在目录的platform-tools目录(ADK的ADB命令工具所在的目录)。

然后在命令行窗口中执行adb devices

至此，ADB就能够正常链接上设备

5.       ADB常用命令

adbkill-server          #停止adb服务进程

adbstart-server     #打开adb 服务进程

adbdevices                #显示链接到的设备

adbshell                      #进入设备的shell模式

adbversion                #查看adb版本

6.       常见问题

常见的问题为找不到设备，具体现象如下

C:\Users\cc>adb devices
List of devices attached
C:\Users\cc>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached

找不到设备的原因可能有很多种，除了手机设备端调试项没有打开之外，其他原因几乎都是PC端环境配置有问题造成的，大致上可按如下思路去逐一实验直至解决。

------------------------------------------------- 

逐一确认本文档1~4这四个操作完成

       一般情况下，这四步操作完成，设备就能连上，如果还链接不上，原则上请继续进行如下检查和操作

1． 关闭PC上一些手机辅助软件 （类似于豌豆荚，手机助手之类的）

2． 关闭进程中的某些adb，有可能是其他名字，比如tadb之类的封装了adb功能的进程。

3． 保证只有一台android 设备

  4.  断开设备，重启ADB服务

  5.  USB连接设备，即可找到设备

如果还不能找到设备，可重启电脑，重新检查以上各步骤。

----------------------------------

“分天下为三十六郡，郡置守，尉，监” —— 《史记·秦始皇本纪》

 

所有用Maven管理的真实的项目都应该是分模块的，每个模块都对应着一个pom.xml。它们之间通过继承和聚合（也称作多模块，multi- module）相互关联。那么，为什么要这么做呢？我们明明在开发一个项目，划分模块后，导入Eclipse变成了N个项目，这会带来复杂度，给开发带来 不便。

 

为了解释原因，假设有这样一个项目，很常见的Java Web应用。在这个应用中，我们分了几层：

• Dao层负责数据库交互，封装了Hibernate交互的类。
• Service层处理业务逻辑，放一些Service接口和实现相关的Bean。
• Web层负责与客户端交互，主要有一些Structs的Action类。

对应的，在一个项目中，我们会看到一些包名：

• org.myorg.app.dao
• org.myorg.app.service
• org.myorg.app.web
• org.myorg.app.util

这样整个项目的框架就清晰了，但随着项目的进行，你可能会遇到如下问题：

1. 这个应用可能需要有一个前台和一个后台管理端（web或者swing），你发现大部分dao，一些service，和大部分util是在两个应用中可以重用的。这样的问题，你一周内遇到了好几次。
2. pom.xml中的依赖列表越来越长，但是，由于目前只有一个项目（WAR），你不得不新建一个项目依赖这个WAR，这变得非常的恶心， 因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，而且你根本不需要org.myorg.app.web。有人修改了dao，提交到 svn并且不小心导致build失败了，你在编写service的代码，发现编译不过，只能等那人把dao修复了，你才能继续进行，很多人都在修改，到后 来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引入。甚至出现了一个依赖有多个版本存在。
3. build整个项目的时间越来越长，尽管你只是一直在web层工作，但你不得不build整个项目。
4. 某个模块，比如util，你只想让一些经验丰富的人来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不能达到你的要求。

我们会发现，其实这里实际上没有遵守一个设计模式原则：“高内聚，低耦合”。虽然我们通过包名划分了层次，并且你还会说，这些包的依赖都是单向的，没有包的环依赖。这很好，但还不够，因为就构建层次来说，所有东西都被耦合在一起了。因此我们需要使用Maven划分模块。

 

一个简单的Maven模块结构是这样的：

 

---- app-parent

             |-- pom.xml (pom)

             |

             |-- app-util

             |        |-- pom.xml (jar)

             |

             |-- app-dao

             |        |-- pom.xml (jar)

             |

             |-- app-service

             |        |-- pom.xml (jar)

             |

             |-- app-web

                      |-- pom.xml (war)   

 

上述简单示意图中，有一个父项目(app-parent)聚合很多子项目（app-util, app-dao, app-service, app-web）。每个项目，不管是父子，都含有一个pom.xml文件。而且要注意的是，小括号中标出了每个项目的打包类型。父项目是pom,也只能是 pom。子项目有jar，或者war。根据它包含的内容具体考虑。

 

这些模块的依赖关系如下：

 

app-dao      --> app-util

app-service --> app-dao

app-web     --> app-service

 

注意依赖的传递性（大部分情况是传递的，除非你配置了特殊的依赖scope），app-dao依赖于app-util，app-service依赖 于app-dao，于是app-service也依赖于app-util。同理，app-web依赖于app-dao,app-util。

 

用项目层次的划分替代包层次的划分能给我们带来如下好处：

1. 方便重用，如果你有一个新的swing项目需要用到app-dao和app-service，添加对它们的依赖即可，你不再需要去依赖一个WAR。而有些模块，如app-util，完全可以渐渐进化成公司的一份基础工具类库，供所有项目使用。这是模块化最重要的一个目的。
2. 由于你现在划分了模块，每个模块的配置都在各自的pom.xml里，不用再到一个混乱的纷繁复杂的总的POM中寻找自己的配置。
3. 如果你只是在app-dao上工作，你不再需要build整个项目，只要在app-dao目录运行mvn命令进行build即可，这样可以节省时间，尤其是当项目越来越复杂，build越来越耗时后。
4. 某些模块，如app-util被所有人依赖，但你不想给所有人修改，现在你完全可以从这个项目结构出来，做成另外一个项目，svn只给特定的人访问，但仍提供jar给别人使用。
5. 多模块的Maven项目结构支持一些Maven的更有趣的特性（如DepencencyManagement），这留作以后讨论。

接下来讨论一下POM配置细节，实际上非常简单，先看app-parent的pom.xml：

Xml代码  

1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
3.     <modelVersion>4.0.0</modelVersion>  
4.     <groupId>org.myorg.myapp</groupId>  
5.     <artifactId>app-parent</artifactId>  
6.     <packaging>pom</packaging>  
7.     <version>1.0-SNAPSHOT</version>  
8.     <modules>  
9.         <module>app-util</module>  
10.         <module>app-dao</module>  
11.         <module>app-service</module>  
12.         <module>app-web</module>  
13.     </modules>  
14. </project>  

Maven的坐标GAV（groupId, artifactId, version）在这里进行配置，这些都是必须的。特殊的地方在于，这里的packaging为pom。所有带有子模块的项目的packaging都为 pom。packaging如果不进行配置，它的默认值是jar，代表Maven会将项目打成一个jar包。

该配置重要的地方在于modules，例子中包含的子模块有app-util, app-dao, app-service, app-war。在Maven build app-parent的时候，它会根据子模块的相互依赖关系整理一个build顺序，然后依次build。

这就是一个父模块大概需要的配置，接下来看一下子模块符合配置继承父模块。、

Xml代码  

1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
3.     <parent>  
4.         <artifactId>app-parent</artifactId>  
5.         <groupId>org.myorg.myapp</groupId>  
6.         <version>1.0-SNAPSHOT</version>  
7.     </parent>  
8.     <modelVersion>4.0.0</modelVersion>  
9.     <artifactId>app-util</artifactId>  
10.     <dependencies>  
11.         <dependency>  
12.             <groupId>commons-lang</groupId>  
13.             <artifactId>commons-lang</artifactId>  
14.             <version>2.4</version>  
15.         </dependency>  
16.     </dependencies>  
17. </project>  

app-util模块继承了app-parent父模块，因此这个POM的一开始就声明了对app-parent的引用，该引用是通过Maven坐 标GAV实现的。而关于项目app-util本身，它却没有声明完整GAV，这里我们只看到了artifactId。这个POM并没有错，groupId 和version默认从父模块继承了。实际上子模块从父模块继承一切东西，包括依赖，插件配置等等。

此外app-util配置了一个对于commons-lang的简单依赖，这是最简单的依赖配置形式。大部分情况，也是通过GAV引用的。

再看一下app-dao，它也是继承于app-parent，同时依赖于app-util：

Xml代码  

1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
3.     <parent>  
4.         <artifactId>app-parent</artifactId>  
5.         <groupId>org.myorg.myapp</groupId>  
6.         <version>1.0-SNAPSHOT</version>  
7.     </parent>  
8.     <modelVersion>4.0.0</modelVersion>  
9.     <artifactId>app-dao</artifactId>  
10.     <dependencies>  
11.         <dependency>  
12.             <groupId>org.myorg.myapp</groupId>  
13.             <artifactId>app-util</artifactId>  
14.             <version>${project.version}</version>  
15.         </dependency>  
16.     </dependencies>  
17. </project>  

该配置和app-util的配置几乎没什么差别，不同的地方在于，依赖变化了，app-dao依赖于app-util。这里要注意的是 version的值为${project.version}，这个值是一个属性引用，指向了POM的project/version的值，也就是这个 POM对应的version。由于app-dao的version继承于app-parent，因此它的值就是1.0-SNAPSHOT。而app- util也继承了这个值，因此在所有这些项目中，我们做到了保持版本一致。

这里还需要注意的是，app-dao依赖于app-util，而app-util又依赖于commons-lang，根据传递性，app-dao也拥有了对于commons-lang的依赖。

app-service我们跳过不谈，它依赖于app-dao。我们最后看一下app-web：

Xml代码  

1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
3.     <parent>  
4.         <artifactId>app-parent</artifactId>  
5.         <groupId>org.myorg.myapp</groupId>  
6.         <version>1.0-SNAPSHOT</version>  
7.     </parent>  
8.     <modelVersion>4.0.0</modelVersion>  
9.     <artifactId>app-web</artifactId>  
10.     <packaging>war</packaging>  
11.     <dependencies>  
12.         <dependency>  
13.             <groupId>org.myorg.myapp</groupId>  
14.             <artifactId>app-service</artifactId>  
15.             <version>${project.version}</version>  
16.         </dependency>  
17.     </dependencies>  
18. </project>  

app-web依赖于app-service，因此配置了对其的依赖。

由于app-web是我们最终要部署的应用，因此它的packaging是war。为此，你需要有一个目录src/main/webapp。并在这 个目录下拥有web应用需要的文件，如/WEB-INF/web.xml。没有web.xml，Maven会报告build失败，此外你可能还会有这样一 些子目录：/js, /img, /css ... 。

 

看看Maven是如何build整个项目的，我们在 app-parent 根目录中运行 mvn clean install ，输出的末尾会有大致这样的内容：

 

...

...

[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[app-web] in [/home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in[50 msecs]
[INFO] Building war: /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war
[INFO] [install:install]
[INFO] Installing /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war to /home/juven/.m2/repository/org/myorg/myapp/app-web/1.0-SNAPSHOT/app-web-1.0-SNAPSHOT.war
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] app-parent ............................................ SUCCESS [1.191s]
[INFO] app-util .............................................. SUCCESS [1.274s]
[INFO] app-dao ............................................... SUCCESS [0.583s]
[INFO] app-service ........................................... SUCCESS [0.593s]
[INFO] app-web ............................................... SUCCESS [0.976s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Sat Dec 27 08:20:18 PST 2008
[INFO] Final Memory: 3M/17M
[INFO] ------------------------------------------------------------------------

 

注意Reactor Summary，整个项目根据我们希望的顺序进行build。Maven根据我们的依赖配置，智能的安排了顺序，app-util, app-dao, app-service, app-web。

 

最后，你可以在 app-web/target 目录下找到文件 app-web-1.0-SNAPSHOT.war ，打开这个war包，在 /WEB-INF/lib 目录看到了 commons-lang-2.4.jar，以及对应的app-util, app-dao, app-service 的jar包。Maven自动帮你处理了打包的事情，并且根据你的依赖配置帮你引入了相应的jar文件。

 

使用多模块的Maven配置，可以帮助项目划分模块，鼓励重用，防止POM变得过于庞大，方便某个模块的构建，而不用每次都构建整个项目，并且使得针对某个模块的特殊控制更为方便。本文同时给出了一个实际的配置样例，展示了如何使用Maven配置多模块项目。

• —软件人才免语言低担保 赴美带薪读研！—

　　作为全球领先的社区新闻和社交网站，Reddit在2013年就拥有7.3亿独立用户，560亿PV，用户遍及全球186个国家。拥有如此庞大的用户群与访问量，很多人可能认为其社区管理团队必定也是非常庞大的。但令人惊讶的是，该团队还保持在个位数!那么，Reddit究竟是如何做到的呢?Reddit总经理、前任社区管理员Erik Martin将和我们分享其中的运营管理经验。

　　一、时刻盯着时间

　　“重要的一点是，不要把时间耗费于少数群体的用户上，即使他们的反对之声最大。”

　　“当人们觉得事情没有朝着自己有利的方向发展时，他们会以超常规的方式来表达不满。”

　　所谓众口难调，我们不可能做到凡事有求必应，有冲突也在所难免。社区如同客服中心，我们不能做“老好人”，费尽心机地去讨好所有用户。我们所做的，是尝试。特别是对于投诉、用户界面变更造成不变等问题，我们必须要学会使用微操作来确保社区营运于正确的道路上。那么，什么是微操作呢?

　　 1. 不论社区大小，时刻保持友善与有礼。

　　通过丰富的交流方式来向人们展示产品或服务的人性化设计。对善意有益的意见，我们要接受与改进。

　　 2. 快速响应。

　　这个不是要求我们去回复所有问题，而是根据客户提出问题的共性与特性，做好知识库管理，反馈信息库管理。例如帮助中心，FAQ或者像Reddit那样为社区配置一名版主。我们还可以根据实际情况，量力开设更多的沟通渠道。

　 　3. 产生共鸣。

　　不要当面直白地指出用户的错误或可笑的操作。我们要换位思考，与用户沟通的时候，让他们知道我们是能理解他们的。记住，聆听是最强大的共鸣发生器。

　　“有时候人们只是希望另一边有人在倾听他们。”

　　所以，“以人为本”是Reddit礼仪规范的第一条例。所以我们要站在多数人的利益上考虑问题，不能只在某人某讨论组上花费太多的时间。我们要紧盯时间去做事。

　 　二、尝试鸟瞰的视野

　　“每天我都尝试从Reddit中发掘出新事物。”

　　当Martin被某特别或有趣的事物捉住时，他会尝试与其它社区管理员甚至是整个公司一起分享。如果是需要进一步跟进的情况，他会记录到个人手记中。

　　有一次，Martin发现瑞典社区中多了个地图，如果某城市的社区位于地图上某区域，那么该区域会被一个点标示出来。当他在节假日再次访问该页面时，发现标示点被圣诞装饰品代替了。这听起来虽然是可爱的小把戏，但是Martin从中得到了两点启示：

　　 1. 用户自定义。

　　“我从来没有看到过这样的地图。这是值得骄傲的事情。随着内生外延的良性发展，越来越多的社区会以自己的特色去打造属于自己的社区。这是非常有发展潜力的，所以我们要给予用户更多的工具去实现它。”

　　 2. 回访与再回访。

　　对于过时或过气的东西，我们或许相忘于江湖。但是你的多一次回访，或许会发现多一份收获。因为事物是发展的，或许当初这个想法或题目未能成行，但是若干年后当我们再次回顾它，或许就有不同的看法了。

　　尽管个人精力有限，但是Martin仍然坚持通过电邮或评论的方式来保持与社区版主的联系，鼓励他们继续做好做精。特别是做得出色的版主，他会以此为榜样来激励其他版主跟着进步。

　　 三、不要想过头了

　　社区管理者第二大错误是制定过多的指导守则来规范与用户的沟通，特别是刚成立的时候，每日一变也是家常便饭。人们因此也会跟着问不同的问题，但是无论如何，请记住相信个人直觉是重要的事情。

　　“作为一名社区管理者，是不可能完美地制订出一个长久的计划。因此，我们首先要相信自己能做好。不论是做对了，还是做错了，我们都能从中学到新东西。无论怎样，请不要把它束之高阁。”最优秀的社区管理者每天会致力于阅读和聆听用户的所需，想用户之所想，急用户之所急。

　　当人们听到直觉这个词时，第一反应是这是与生俱来的。但是Martin并不认同。他相信直觉来源于实践与时间积累。特别是作为社区管理者，每天每周都有无数的交流沟通机会，这就有可能培养出第六感来快速感知用户的需求，成为用户的知音人。

　　 四、放下身段

　　Martin是第一个承认自己不是十分懂得处理与接受错误的人。人的天性是会尝试掩饰个人错误。但是在社区里，我们的一言一行都会受到注目，甚至还有一些硬性子的成员，所以我们要接受与承认每次突发的意外，每次错误的选择，每个不正确的决定。

　　“情感的弹性是最需要培养的能力。这是你唯一能保持前进的方法。在一帆风顺时要放下身段，在绝处逆境时更要放下身段。”

　　“倘若我们犯了很大的错误，好的一点是往往都能快速地进行处理和修复。”例如，Reddit曾经在版主的评论模块里，在其名字后附加了特殊图标来区分版主身份。有些版主觉得不适应，引起了广泛热议。很快，在该功能上线15分钟后，就把这个改为可选设置，避免了更大的影响。

　　遇到问题时，最错误的处理方法是钻牛角尖，独困其身。不要过分自责，多数情况下用户很快就会忘记我们所犯的错误。但如果你耿耿于怀，用户同样也不能释怀，是我们的错误导致了不愉快的经历被延长了。

　　 五、识别真正的刺头

　　“我们发现不是每个人都是专门来找茬的。有些用户特别是新用户，对操作或条例不熟悉而造成了误会。”换句话说，这样的初级“刺头”也是社区资产的一部分。只要我们义正辞严地予以指正，他们很快就会知道正确的做法，最后或许还会成为礼仪大使。

　　如果运气稍欠，我们会无法阻止部分用户散发垃圾邮件，欺骗信息和不正确的内容。这需要别的处理方式—暂停使用权。在Reddit中，在版主的帮助下，开辟了子社区来识别散发不当内容的用户，不论是新用户还是单次发帖者。这或许是Reddit的特色，但是其它在线社区都会让富有经验或影响力的用户来帮助处理类似的问题。

　　 六、重视线下交流

　　Martin觉得最有学习意义最不能被替代的是面对面的交流。他建议社区管理者尽最大的努力来到线下与成员见面交流。虽然这是个巨大的挑战，但是在不同城市或国家，你或许曾经偶遇过了Martin。

　　“人们会乐于分享生活中重大的事情—或许是找到了室友，或许是找到了终身伴侣，或许是成功找到了工作。”

　　我们所追求的，不正是用户对我们产品或服务的粘度吗?诚然不是每个在线社区都能成为人们生活的重要组成部分，但线下交流仍然值得管理者去为之努力。

　 　七、不要沉迷于数据

　　当很多在线站点沉迷数据说事的时候，Reddit是用平常心来对待的。Martin认为数据只是个辅助工具，但不能成为决策的指引物。

　　“社区管理者精力有限，数据可以协助扩充视野。我们会关注那些访问量异常或有该趋势的主题讨论，以此来判别是否有什么事情正在发生，需要介入处理。”

　　在印度2014年大选的时候，Reddit发现了持续几个星期的流量异常，这引起了社区团队的注意。“我们没有马上就该情况采取特殊的处理措施。事实上，这是印度板块活跃度的历史新高，所以我们想开拓这个市场，去看看这边的人们关心的是什么。这个异常数据表明了这是个很好的介入时机。”Martin说道。

　　“重要的一点是数据不能成为我们直觉的替代物，特别是遇到对社区影响重大的事情时。我们要学会跳出数据，不要被它牵着鼻子走。”

　　 八、顺其自然

　　“对于重视我的人，我会同样重视他;对于冷漠我的人，我也会顺其自然。”

　　“优秀的管理者会适当的在社区条例上留有余地。这是我们给用户营造的抒发意见的空间，我们可以因此避免不必要的争端。”

　　只要我们与人交流时，保持一个有礼，专业的态度，合理地分配好时间，我们或许在工作中能减少不必要的麻烦。Reddit的成功之道，在于成为人们抒发情感，展示个人，分享趣事的地方。这些都是积极的事物，值得鼓励。产生了共鸣，也就产生了共识，拉近了人与人之间的距离。

　　“我不懂得跳伞，但很多人会。所以Reddit会成立以跳伞为主题的社区，让跳伞者与他人分享其中的乐趣。如果人们透过你的产品或平台找到新的角度来看待世界，你会怎么样来庆祝或报答它呢?这就是你的事情啦。”

　　本文译者伍昆,英语原文

经常会有人问“我该如何在机器学习方面更进一步，我不知道我接下来要学什么了。”

一般我都会给出继续钻研教科书的答案。

每当这时候我都会收到一种大惑不解的表情。但是进步确实就是持续的练习，保持较强的求知欲，并尽你可能的完成具有挑战性的工作。其实这些你都懂的，是吧！

但是为什么偏偏是教科书呢？因为他是为数不多的几种可以让你真真让你获取坚实知识的媒介。是的，你可以选择选一门课，注册MOOC，参加一些讨论班。但是只有教材才是会让你持续进步的。教材的每一页都会留下你的印记。你会不知不觉的就记住了章节标题，例子和练习题。你会在边页处写写画画做点笔记，你会把常用的章节折起来，并且还会根据学习内容去寻找一些相关程序来学习。其实你的教科处已经成为了知识的一部分。成功的学习不仅仅只是看看教科书。通过这样的方式来用教科书，你能掌握任何一门学科——当然也包括机器学习。

在下面的内容中，我会循序渐进的列举一些优秀的教科书供你参考。我结合我自己经历并咨询了UC Berkeley的研究生，博士后和教授们后给出了这份参考教科书。当然我是故意少列了的，因为列再多反而是你选择烦恼。

当然，如果你想更换一些学习资料，  Metacademy是个不错的选择。

Level 0: Neophyte

我妹妹是贸易方面的写作者。曾经她问我怎样去简单的了解一些数据科学的基础知识。在阅读了基本这方面的介绍性的书籍后，我推荐了这本Data Smart.通过这本书我妹妹可以基本解决其工作问题，甚至又一次我和她关于逻辑回归还进行了一次比较深入的探讨。

Expectations:你能了解一些基本的机器学习算法，你能够通过Excel完成一些基本的算法编写。（在完成整本书后你还能会点R语言）。

Necessary Background:熟悉Excel操作——假如你有点计算机/数学背景的话你应该能够很好的掌握。另外，它不像典型的教科书那么枯燥。

Key Chapters:书很短，而且每章都通熟易懂，而且我认为你可以跳过工作表相关的内容。第8和10章是一些基本的概述。

Capstone Project:用  this dataset来试一下你是否能够在给出一些属性条件的情况下预测汽车的MPG。这将考验你是否能用机器学习的方式来解读数据，并且能用机器学习的技术解决问题。

Level 1: Apprentice

这是一本例子导向的书，但是同时你可以学习到很多有用的机器学习知识和R编程语言。我是Scipy的忠实用户，但是当我看了几章这本书后，我现在大部分的问题都会选择用R去解决了。

Expectations:你能够判断出哪些机器学习的算法适合哪些问题，并且能够用R语言来完成代码的编写。

必要的背景:没有真正的先决条件,但以下将帮助(这些可以学到/审查时):一些编程经验(R)一些代数概率论的基本微积分一点

Necessary Background:没有特别的要求，但是如果你有以下的知识将会很有帮助：

• R的基本的编程能力
• 基本的代数知识
• 基本的微积分知识
• 一点概率论知识

Key Chapters:这是一本很短的书，因此我推荐大家阅读全文，尤其是好好思考那些例子，并用R语言去完成。如果你时间有限，你也可以略过第8和12章。

Capstone Project:用 this dataset 试试你是否能够在给定相关属性值的情况下预测出食品等级。用三个不同的机器学习方法去解决这个问题，并且选出最合适的一个。建立一个分类器，并能预测评估是“good”还是“bad”，过程中你一定要选好“good”和“bad”之间的阀值。这能测试你的数据滤除能力，处理大数据来那个的能力，机器学习的基本知识还有你编写R代码的能力。

Level 2: Journeyman

这个阶段，再也不是学习一些表面的浅层知识了，我们将逐渐的深入，并且更加的严谨的推导。在一阶段将会有许多数学问题去处理，但是如果你想把机器学习当成你终生的事业来做，那么你必须过掉这关。PRML这本书是一座很好的桥梁，可以让你做的更顺些。你要不断的使用它，阅读他并且爱上他。但是你要时刻保持注意，并不知只有贝叶斯方法是机器学习方法。（译者注，这本书很多都是以贝叶斯方法为基础进行阐述的。）

Expectations：能够识别，完成，调试和解释大部分现有的机器学习方法。当然，对于一些特定问题，你应该有一些自己的想法去研究更高级的机器学习算法。而数据科学家则应该必须至少处于这一步。

Necessary Background:

• 你应该熟悉大部分的聚类和分类算法；
• 线性代数：理解矩阵代数和行列式运算；
• 一些多变量和向量微积分运算能力——比如知道什么是Jacobian
• 能够用R，Matlab，Scipy或者是Julia完成一些机器学习算法的编写。

Key Chapters:详细阅读1——12.1章。至于12.2 – 14章你可以在需要的时候再去阅读。

Capstone Project:完成  Online Variational Bayes Algorithm for Latent Dirichlet Allocation 并且分析一个你选择的数据。证明你写的LDA是正确的。这能测试你是否能够理解并解释前沿的机器学习算法，并且能否进行在线的推理和近似。当然这也测试了你的编写代码能力，数据预处理能力和实际的解决问题的能力。

注意：PRML花了很多的时间在Bayesian机器学习方面。因此如果你对Bayesian统计不熟，我强烈建议你先看看Doing Bayesian Data Analysis 的前五章。

Level 3: Master

这一阶段你有大量的知识需要去钻研：凸优化理论，测度理论，概率论，离散优化，线性代数，微分几何甚至是计算神经学。但是当你真正在这一阶段的时候，你也许也已经知道该去学哪些了。这里我仅仅推荐一本书：  Probabilistic Graphical Models: Principles and Techniques 是一本机器学习研究者都应该去钻研的神书。PGMs是一本机器学习进阶的书，如果你熟读了此书，不管你学习哪一个机器学习方向你都能轻松驾驭了。

Expectations:对于新问题你应该能够构造概率模型，确定合理的推理技术并且能评估你的方法。对于模型之间的关系你也有了更深入的理解，比如深度信念网络也可以看成是因素图模型。

Necessary Background:

• 你应该熟悉大部分的机器学习算法
• 线性代数——知道怎样解释特征值
• 多变量和向量的微积分求解
• 能够用R，Matlab，Scipy或者是Julia完成一些机器学习算法的编写。

Key Chapters:1-8章内容类似于Bishop’s Pattern Recognition and Machine learning的2-8张的内容，但是更深入一些。9-13章是本书的精华部分。第19章对于预处理数据是非常有用的。14和15章当你要用时，你再去读他把。

Capstone Project:这一阶段了，你应该自己去定义和探索自己的机器学习项目了。也许还会知道一点当前最火热的“big data”

Level 4: Grandmaster

如果你获得主人地位,你就会拥有一个足够强大的ML背景小说追求任何ML-related专业化水平:例如:也许你感兴趣深度学习应用程序或刻画小说?也许你应该成为Metacademy贡献者?

当你过了master阶段，你已经有了很强的机器学习背景去探索任何机器学习相关的更专业的领域：比如你想去做深度学习（deep learning）相关的应用或者研究。当然或许你也许会变成一位Metacademy的贡献者。

翻译自： http://metacademy.org

本文转载自： http://www.aitmr.com/index.php/airesearch/331.html

英文链接： Level-Up Your Machine Learning

最近，韩寒 vs 郭敬明、《后会无期》vs《小时代》成了人们热议的话题，除了媒体八卦对抗，他们互相可以从对方身上学习到什么?

这个夏天，“韩寒和郭敬明”话题模式又重启了。

但就“如何为自己的电影做营销”这件事来说，带着自己精挑细选的一众男主角参加“男神季”主题《快乐大本营》大概是韩寒和郭敬明目前做过的唯一“风格”一样的事情了。

一部电影的营销应该从何时开始? 对于郭敬明来说，项目开始的那一刻就是营销的起点。在 2013 年的 11 月 24 日，郭敬明发了一条微博：“《小时代 3 ：刺金时代》12 月将正式启动”。并配上一张海报，上面是沾着血的手术刀。

在随后长达 8 个月的时间里，他一直通过微博向外界——大部分时候是铁粉们——传达着整个项目的进展情况。拍摄完成前会公布新角色、发布定档照、早早锁定 7 月 17 日的档期以及一些片场的拍摄照片，宣传期有密集的海报、预告片、音乐 MV 、特辑和各种“幕后”解密，即使你对这部电影完全没有兴趣，也时不时被有关这部电影的信息“袭击’，即便你没有看过原著小说，也大概能从这些宣传信息中猜出大概的剧情。

但现在距离《后会无期》正式上映只剩 3 天，你可能依然还不知道陈柏霖、冯绍峰、王珞丹、陈乔恩等人在影片中扮演什么角色，这是一个什么样的故事，有什么样的矛盾冲突、笑点和精彩的台词，甚至是片中的那个神秘的东极岛——到底在哪里。

观众对于这部电影的印象还停留在“这是韩寒拍的一部电影”，“看上去还挺文艺”，“海报和歌都还比较有逼格” 这样的阶段，类型片常用的宣传方式——用内容特别是戏剧冲突和夸张的表演去吸引观众的部分在这部电影宣传中并没有出现。

在《小时代 3》上映前的最后一天，郭敬明一共发了 7 条微博，是几个月来最多的一天。7 条微博无一例外都与电影相关。包括一个“剧组七宗罪” 的自黑视频特辑，一套全新的主创海报，“《小时代 3》 100 个小故事” 的最后一个，预告第二天由影片男主角之一陈学东演唱的插曲《不再见》 MV 发布，提醒片尾最后的彩蛋以及两条感谢院线给予大量排片的微博。

那天对于韩寒来说，其实也是重要的一天。朴树 11 年来发布了第一首新歌，这首名为《平凡之路》的歌曲是朴树为《后会无期》而作的主题曲，当天朋友圈被刷屏，《平凡之路》MV 在优酷被播放了超过 350 万次， 大多数人表达了对于朴树以这种方式回归的意外和惊喜，觉得“朴树和《后会无期》的风格很搭”。对于这个被认为是《后会无期》整部电影宣传过程中最成功的一次“运作”，韩寒也只是截取了其中的一句歌词，并将歌曲 MV “置顶”在了他拥有 3870 万粉丝的新浪微博 上。没有提及任何与电影相关的内容。

很难说“把悬念留到最后”和“不让观众错过任何一个精彩瞬间”，哪种营销方式更胜一筹。对于同样是讲述“青春”的两部电影而言，韩寒和郭敬明可能都清楚自己的故事是要拍给谁看，他们都在以自己认为正确的方式到达自己的观众。

《后会无期》影片宣传负责人常杰告诉《好奇心日报》，韩寒希望这部电影是“卖气质”的，通过展现出的文艺气质把大家吸引进电影院中，这是一种策略的选择。所以你可能到现在都不知道《后会无期》其实是一个公路喜剧，甚至会对微博大 V”作业本“贴出的影评“ 35 次小笑，6 次大笑，成了。”感到莫名。因为在整个营销过程中，《后会无期》从电影海报到预告片都透露着一股浓浓的文艺气息。

郭敬明从《小时代 1》开始，就毫不忌讳地传达出“这是一部偶像级电影”信息，“我从全中国找来了四大美女和帅哥”，他总是这样说。“《小时代 3》在营销上的最大变化是一次全面升级，从制作费用到作品质量 ; 另一个就是查漏补缺。”《小时代》电影系列的营销公司麦特文化总裁陈砺志告诉《好奇心日报》，“其实做前两部的营销，郭敬明也不敢讲太多关于电影的内容，前两部获得商业成功之后，他对《小时代 3》自信了很多，所以会有更多内容的曝光和提前几万人观看的典映。”

无论如何，和之前电影宣传不同的是，作为导演的韩寒和郭敬明，都同时承担了他们自己电影的首席营销官角色。这和“粉丝电影”定位有关。不过《后会无期》的宣传方负责人对《好奇心日报》表示，韩寒这次并没有做粉丝电影的打算，《小时代 3》的的宣传方也说这次电影定位是一个全民电影，只不过他们的起点始于 3 亿粉丝，然后才是扩散到 2 亿“其他人”。

郭敬明把个人微博变成了电影营销的中心。这其实也是《小时代》系列电影在营销方面的最大创新。以往电影在线上营销上的做法就是成立一个官方微博，时不时地发一些电影相关的新闻、海报和预告片，更多地是承担线上制造话题，辅助线下宣传的作用。而郭敬明把拥有 3300 万粉丝的个人账号变成了整个电影的营销中心，所有关于《小时代》的重要新闻、物料 (剧照、海报、预告片、歌曲 MV 、视频特辑等) 与合作都通过这个账号发布，然后通过其它账号 (主演个人微博、合作方等) 将这些信息传播出去。

在整个电影宣传期间郭敬明几乎不会发布与电影无关的微博，粉丝和想了解这部电影的人只要到他的个人微博上刷上几页就可以了。

那些被他放在微博上的，看上去丰富多彩的宣传物料的制作和投放计划其实从 9 个月前就开始了。“在电影开拍前他就拿出了平面宣传物料的整体方案，每次发给他视频物料都会收到逐条详细的修改意见。” 《小时代 3》宣传总监刘菲在“小时代 3 的 100 个小故事” 中自述说。郭敬明作为所有物料和消息的统一出口，使得超长的宣传周期并没有让整个过程看上去杂乱无序。在执行过程中，“郭敬明会把每一条视频物料的详细修改意见发回给工作人员，常常凌晨两三点还能’秒回’”。陈砺志说。《小时代 3》共制作视频物料 29 支，其中包括预告片 2 支，MV 6 支，制作特辑及花絮 21 支。平面物料包括 15 个系列、167 张海报，超过 300 张剧照。

郭敬明有自己的营销节奏。首先是根据不同的人群将宣传期分为两步，进行针对性的宣传。最初一轮的宣传针对郭敬明、主演们和《小时代》原著的粉丝，以“互动”，郭敬明、杨幂，微博为核心。之后为了让粉丝们在最短的时间里建立起电影与原著，演员与小说中人物的联系，郭敬明将通常一部电影 4-5 套海报的数量一下子提升到了 18 套，通过不同角度、不同主题呈现出不同的人物关系和视觉效果。

把电影海报做成大片，是郭敬明又一个营销招数。做为一部青春时尚的“造梦” 大片，如果无法一下子在故事上吸引观众，那么“卖相” 一定要好。于是你能看到小时代层出不穷的各种主题的海报，它们往往有一个整体统一的视觉风格，通常是影片中美貌主角们的全身照或者合照，穿着名贵的服装，做出和剧中人物性格相符的动作和神情，每一张海报看上去都可以用做时尚杂志的封面，或是成为粉丝手机上的屏保。

通常一部电影会做 4-5 套海报，但《小时代》在第一部时的海报数量就达到了 18 套，最初这样做的目的是让粉丝们在最短的时间里建立起电影与原著，演员与小说中人物的联系，但随后发现海报本身也成为《小时代》系列一个最重要的“标签”，也是和粉丝进行情感联系的重要方式，几乎每一次的海报发布微博转载量都要高于平常。

这种手法在其实在《小时代 1》中就得到了很好的实践，并在《小时代 3》中得到了很好的继承和调整。

《小时代 3》一共制作了 15 套一共 167 款海报，项目启动来一发“手术刀”海报，原角色演员回归啦? 来一发粉色系海报。四位男主一起的叫“刺金”，四位女主一起的叫“雪迹”，一块儿拍的叫全角色主海报，电影要上线了，还有院线终极海报。不同时间、不同风格，但一眼望上去，你就知道一定是《小时代》的海报。

即使你不是它的粉丝，甚至是对它有些抵触，你也不得不承认海报的精致程度要远远超过一般的国产电影。以至于后来在圈子里出现了一种调侃的说法：如果你做电影能拿出郭敬明做海报的那鼓认真劲儿的话，你早成功了。

不少看过《小时代 3》的人评价这部电影在“中国最好的 PPT 电影这条路上又迈出一大步”，愈加精致的画面吸引了更多的注意，多多少少弥补了剧情上的不健全。

与此同时，原本只是电影附属的“音乐”——包括主题曲和插曲，被提升到了一个前所未有的重要地位。你可能没有看过《将爱》，但你一定在不同场合听过陈奕迅和王菲演唱的《因为爱情》，而 MV 中使用的正是电影中的剧情。

郭敬明充分发挥了这种音乐对于电影营销中的作用。请来合适的歌手 (比如《小时代 1》中请来在年轻人中有很高人气的组合苏打绿，比如《小时代 3》年龄覆盖要更广，所以蔡依林会更合适)、将插曲和主题曲制作成独立的 MV，并分次进行阶梯式的推广。“传统的方式，发 MV 就是几月几号，开一个发布会就完了。但我们这次是先出歌词，过几天发一段围绕这个歌词做的曲，然后再过几天副歌部分也发出来了，最后才发这个 MV。” 陈砺志告诉《好奇心日报》，“这种做法，一般人会很烦的，只有粉丝才不会烦。”

《小时代》 MV 有时候放在情感冲突中用来赚眼泪，有时候放在片尾做为彩蛋让大家乐呵乐呵，夸张点的人会说这就是一部 120 分钟的 MV，郭敬明被质疑多了也会说，“哎呀，你们就把这个当成我的导演风格好了。”

韩寒也把音乐作为了一个极其重要的营销手段，而且运用的相当成功。除了朴树的《平凡之路》，韩寒还请来了邓紫棋演唱同名主题曲，以及另外拍摄了一支《东极岛之歌》的 MV，前者在微博上达到了 17 万次的转发，而后者在优酷的播放量达到了惊人的 515 万次。与《平凡之路》类似的是，韩寒在这两个 MV 中也没有任何台词的叙述。

而被看做影片正式营销起点的是，5 月 29 日上午 9 点左右，韩寒微博和优酷同步首发的先导预告片，这距离《后会无期》正式关机只有 3 天的时间。这条微博在 24 小时的转发量为 33.8 万，优酷播放量为 370 万。

同郭敬明一样，韩寒也会控制每一款海报和物料的创意到执行的过程。只不过比起已经拍摄了三部电影的郭敬明来说，他还没有那么驾轻就熟。他可能并不完全清楚自己想要什么，但他一定知道自己不要什么——“不要那些条条框框的标准和规则，不要和别人一样。”一名《后会无期》项目主要的参与者告诉《好奇心日报》，“所以有的时候会导致进度放缓，大家都在等他的意见，同时微信群里一天到晚都在不停说话，一天只睡 2-3 个小时。”之所以会和其他的类型片显示出不同。也是因为韩寒觉得，那才是自己“想要的感觉”。

除了“将悬念进行到底”，韩寒在整个营销过程中，最强的地方其实不在于制造话题的能力，而是在话题出现之后的放大和持续运营能力。无论是前期的“国民岳父”，还是最近的“依然”体，其实都是无心之举，但当它成为一个热门话题时，韩寒就能将它抓住并形成最大化的关注。

比如针对网友在韩寒微博照片下的神回复，韩寒也会故意时不时地挑选一些拍摄现场有槽点的照片，来供网友发挥和“调戏”，碰到自己觉得好玩的回复，还会转一发。以至于发展到后来，没有任何槽点的照片也会被引发话题。这种卖傻和自黑的做法让韩寒的微博一直保持着很高的关注和活跃度，在电影进入密集宣传期之后这些关注也转化成了对电影的影响力。

韩寒把同样的手法延伸到了 Instagram 上。他在 Instagram 上的粉丝数也已经达到 43.8 万。比如他曾发过一张陈柏霖依偎在他怀中，作势比“嘘”的合照。并配上“柏霖配音工作完成，我们依依惜别”的文字。果然又引来了像微博上一样的炮轰：“想让我大仁哥当女婿，想得美”;“最喜欢看岳父被黑了，岳父你真好”……

“放肆之旅，还有 X 天”的《后会无期》电影海报也被放在了韩寒的 APP “ ONE 一个”上面。现在它有 2000 万的下载量，日活跃用户在 100 万以上——这是一个精准营销的平台。之前有知情者向《好奇心日报》透露，郭敬明曾经想在“ONE 一个”上面为《小时代 3》做推广，不过后来放弃了。

在整个营销过程中，比影片主角出镜率还高的大概就是那辆大众 Cross Polo，而大众的所有营销渠道和 4s 店也都同时发布了《后会无期》的海报和预告片。一个双赢的营销。对了，影片中还有一个“男狗演员”马达加斯加，它的新浪微博粉丝居然也超过了 17 万。在今天上线的终极预告片中，终于出现了它的镜头。

韩寒还参加了创造 6 亿点播的网络剧《万万没想到》第二季其中一集的拍摄，扮演一位被劫持后被剧组无情抛弃的导演。韩寒在转发时自嘲，“看了自己的表演后，我觉得此生我是拿不了影帝了”。

没有人在乎他能不能拿影帝，票房才是眼前最重要的。《小时代 3》 7 月 17 日上映，单日票房超过 1 亿，创造了新的国内 2D 电影票房纪录。《后会无期》能否打破这个记录，可能韩寒和郭敬明比谁都更想知道。

本文来源： 好奇心日报作者：俞斯译

我们非常高兴的向大家介绍我们团队开发的zui框架。我们团队在开发禅道、蝉知和然之系统时，也涉及到ui框架选型的问题。我们先后经历了最初的表 格布局，到后来的yui框架，再到后来的bootstrap框架，再到最后我们综合这些ui布局方法和框架的各种优缺点，逐步形成了我们自己的zui框 架。在此感谢我们团队的catouse同学！

关于zui框架

授权协议：MIT
项目地址： https://github.com/easysoft/zui/
文档示例： http://easysoft.github.io/zui/
下载地址： https://github.com/easysoft/zui/releases

zui框架的主要特点如下：

• 简单美观，易于使用，快速构建简洁大方的现代web应用。

• 新颖健壮，采用HTML5且支持所有流行的移动及桌面浏览器平台，一些旧的浏览器也能够降级支持。

• 轻快独立稳定，最佳的可用性能，最大限度的不依赖于外部组件。

• 全平台响应，一次编写，响应任何尺寸的设备。

• 比较适合中文环境

我们为什么来做zui框架？

zui框架并不是我们完全从头到尾自己写出来的。我们也是在使用bootstrap, yui这些框架中结合我们自己产品的应用场景，逐渐积累形成的。现在最成熟的当推bootstrap了。但是bootstrap的版本跨度比较大，也有很 多功能是我们不需要的，再加上它还是比较适合英文场景的布局。所以我们才决定自己来写zui框架。在写这个框架过程中，我们结合了很多具体的应用场景，比 如大量数据展示、比如手机端响应式布局等，做了很多非常有针对性的改进。最终形成了zui框架。

感谢巨人的肩膀

zui的形成是建立在这些巨人的肩膀上的，在此向这些项目和背后的团队表示感谢！

Grunt
Less
normalize
jQuery
Bootstrap
kindeditor
Chosen
Datetime picker
FontAwesome
google code prettify
jQuery hotkey
Bootbox
Explorer canvas
Chart.js

部分截图示例

10年前我开始自己的职业生涯的时候，Struts还是市场上的主流标准。然而多年过后，我发现Spring MVC已经越来越流行了。对我而言这并不意外，因为它能和Spring容器无缝集成，同时它还提供了灵活性及扩展性。

从我迄今为止对Spring的经验来看，我发现有不少人在配置Spring的时候经常会犯一些常见的错误。跟使用Struts框架相比，这些错误要出现得更频繁一些。我猜想这可能是它在可用性和灵活性之间做出的权衡。不仅如此，Spring的文档中全是例子但缺少解释。为了填充这一空白，本文准备深入阐述三个大家常犯的错误。

在Servlet上下文定义文件中声明bean

我们都知道，Spring使用的是ContextLoaderListener来加载Spring的应用上下文（application context）。还有就是在声明 DispatcherServlet的时候，我们需要用"${servlet.name}-context.xml”的名字来创建servlet的上下文定义文件。你有想过为什么要这样吗？

应用上下文结构

并非所有的人都清楚，Spring应用上下文其实是分层的。我们看一下这个方法

org.springframework.context.ApplicationContext.getParent()

它告诉我们，Spring应用上下文，其实是有父context的。那么，它是用来干什么的？

如果你下载一下源码，搜索一下方法引用，你会发现 Spring Application Context把双亲作为它的扩展。如果你不想读源码的话，我来给你演示一下BeanFactoryUtils.beansOfTypeIncludingAncestors()方法的一个用法 ：

if (lbf instanceof HierarchicalBeanFactory) {
    HierarchicalBeanFactory hbf = (HierarchicalBeanFactory) lbf;
    if (hbf.getParentBeanFactory() instanceof ListableBeanFactory) {
 Map parentResult = 
              beansOfTypeIncludingAncestors((ListableBeanFactory) hbf.getParentBeanFactory(), type);
 ...
    }
}
return result;
}

如果你看完整个方法，你会发现 Spring Application Context 会先在内部的上下文中查找bean，然后再去搜索父context。通过这个策略，Spring可以进行高效的反向广度优先搜索。

ContextLoaderListener

每个开发人员都应该了解这个类。它能帮忙你从预定义的上下文定义文件中加载Spring应用上下文。由于它实现了ServletContextListener接口，因此一旦WEB应用加载完毕，就会立即加载Spring的上下文。毋庸置疑，当加载包含@PostContruct注解或者批处理任务的Spring容器时，这个会非常有用。

反过来，任何在servlet上下文定义文件中定义的bean在servlet初始化前都不会构造。那servlet在何时会被初始化呢？这个是不确定的。最坏的情况下，你可能得等到用户第一次点击对应的servlet所映射的URL的时候，才会加载Spring上下文。

知道了以上这些信息，你认为你的bean声明应该放在哪里好呢？我觉得最佳的位置就是ContextLoaderListener所加载的上下文定义中了，没有其它。这里有个技巧就是将ApplicationContext作为servlet的一个属性进行存储，

org.springframework.web.context.WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE   

然后，DispatcherServlet会从ServletContext中加载这个上下文，并把它赋值给上层的应用上下文。

protected WebApplicationContext initWebApplicationContext() {
   WebApplicationContext rootContext =
      WebApplicationContextUtils.getWebApplicationContext(getServletContext());
   ...
}

由于它的这个行为 ，我强烈建议你只创建一个空的servlet应用上下文定义文件，将你的bean定义在父context中。这能避免当WEB应用加载时bean的重复创建，并能保证批处理作业能立即执行。

理论上说，将bean定义在servlet应用上下文定义文件中会使得bean对该servlet是唯一可见的。然而，在我8年的Spring使用经验来看，我发现这个特性几乎没有什么用处，除了用来定义 WEB service端点。

在ContextLoaderListener后面声明Log4jConfigListener

这是一个小BUG，不过如果你不注意的话，它会让你栽跟头。Log4jConfigListener是我最喜欢的解决-Dlog4j.configuration问题的一个方案，这样我们可以控制log4j的加载而不用改变服务器启动的进程。

很明显，这应该是你在web.xml中声明的第一个监听器。否则，你所声明的所有日志配置都将不会生效。

重复的bean定义

在早期的Spring中，开发人员更多的时间是花在了配置XML文件上，而不是Java类。对每一个新的bean，我们都需要声明它，然后自己将依赖注入，尽管这个做法很干净，整洁，但却非常痛苦。所以后续版本的Spring在可用性上进行了很大的提升这也不足为奇了。现在来说，开发人员只需要声明事务管理器，数据源，属性源，WEB服务endpoint，剩下的工作就交给组件扫描与自动织入来完成吧。

我喜欢这些新特性，但是权利越大，责任越大，否则的话，事情很快就会变得一团糟。XML文件中的组件扫描与bean声明是完全独立的。因此，在同一个bean容器内，如果bean被注解为组件扫描并且是手动声明的，就很有可能会出现相同类的不同bean。所幸的是，这种错误一般只发生在新手身上。

当我们需要集成一些嵌入式组件的时候，事情就变得复杂了。这个时候我们就需要一种策略来避免重复的bean声明。

上图展示了我们在日常工作中可能面临的真实案例。大多数时候，系统是由多个组件组成 的，一个组件服务于多个产品。每个应用和组件都有自己的bean。在这个例子中，怎么做才能最好地避免bean的重复声明？

下面是我个人提出的一个策略：

• 确保每个组件都以一个独特的包名开头。这样当我们需要组件扫描的时候会更容易一些。
• 不要让开发组件的团队将bean声明在组件内部（注解 VS XML声明）。负责将组件打包成最终产品的开发人员，他应该得去确保bean声明是唯一的。
• 如果在组件内部有上下文定义文件，最好将它放在某个包底下，而不是classpath的根目录下。如果能给它分配一个专门的名字则更好。比如说，src/main/resources/spring-core/spring-core-context.xml总比src/main/resource/application-context.xml要好。想像一下如果你打包组件的时候发现同一个包底下存在相同的application-context.xml你会是什么心情。
• 如果你已经将bean声明在一个context文件中了，就不要提供任何组件扫描的注解(@Component, @Service or @Repository)。
• 不要在通用包上进行组件扫描。比如说，不要扫描org.springframework，扫描子包的话会更容易管理，比如说org.springframework.core, org.springframework.context, org.springframework.ui。

原创文章转载请注明出处： Spring MVC的常见错误

英文原文链接

<form id="uploadFileform" action="$!{request.contextPath}/user/uploadImage" method="post"
 enctype="multipart/form-data" ><center><label id="Header" cssClass="HeaderText" value="图片上传" /><hr style="size: 1" /><p id="FileList"><input id="uploadImage" value="" type="file" name="uploadImage" size="50" /></p><hr style="size: 1" /><p>温馨提示：只允许上传.jpg .gif .png 后缀的图片</p><p style="color:green;">(请务必上传真实证件照片或图片 否则不会通过认证)</p><p><input class="btn btn-primary" type="button"  value="上传图片" onclick="uploadImages();"/></p><hr style="size: 1" /></center><p align="center"><span class="GbText" style="width: 100%; color: red;"></span></p></form>

function uploadImages() {
    var str = $("#uploadImage").val();
	if(str.length!=0){
	   var reg = ".*\\.(jpg|png|gif|JPG|PNG|GIF)";
	   var r = str.match(reg);
	   if(r == null){
		alert("对不起，您的图片格式不正确，请重新上传");
	   }
	   else {
		if(window.ActiveXObject) {  
    		var image=new Image();
      		image.dynsrc=str;
    		   if(image.fileSize>5243000){
    		      alert("上传的图片大小不能超过5M，请重新上传");
    		      return false;
    		   }
    	        }
    		else{  
    		   var size = document.getElementById("uploadImage").files[0].size;
    		   if(size>5243000) {
    			alert("上传的图片大小不能超过5M，请重新上传");
    			return false;
    		   }
    		}
		$('#uploadFileform').submit();
	   }
	}
	else {
	   alert("请先上传图片");
	}
}

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

• —软件人才免语言低担保 赴美带薪读研！—

此事可以作为姐妹们查岗查哨或者学习的论文普及，题目我已经想好了—— 论女友的重要性 or 前女友是颗不定时炸弹

其实事情很简单，就是我闲得天灵盖儿疼（蛋疼是男银的事儿！），想知道前男友icloud以及淘宝的密码，看看有木有跟老娘我这么如花似玉打着探照灯都找不到的善良纯情小少女分手后的候补妹纸的照片。因为他的习惯是密码通用，这样顺便还能看一些八卦的东西来提升娱乐精神，给炎炎夏日送来一阵略爽的清凉……呜哈！心飞扬！（以前看到淘宝回收站里有啥飞机杯之类的，不忍直视的郁闷啊，喝水就喝水嘛，同是杯子家族的为毛还要分出来保温杯、马克杯、飞机杯？这不是可耻的搞分裂么？！）

安全小提示：尽量不要用通用密码，老大关于隐私的文章里提到过很多次

废话不多说了，节省口水资源，工作正大光明的在朗朗乾坤下开始展开了……

试过以前用的密码以及模式重组，果断已改，于是我有个迂回的思路，记得前男友管理过一个网站，于是打算从网站入手，看看是否能碰巧找到这个通用密码

1. 第一次找SQL注入漏洞啊 原来是这样找的：

通过在URL数字参数后面加单引号看页面是否报错，判断是否存在注入，运气很好，加了单引号后，页面已经报错了，如上图。

判断注入手段：

http://www.xxx.com/xxx.php?cid=118’

2. 工具验证注射点：

用了同事教我的sqlmap来验证注射点，果然很好用

Sqlmap验证：

Sqlmap.py
–u “http://www.xxx.com/xxx.php?cid=118” –p cpid

3. 然后得到数据库名：cn397073：

Sqlmap注射出数据库名:

Sqlmap.py
–u “http://www.xxx.com/xxx.php?cid=118” –p cpid --dbs

4. 然后注射出所有用户名：

有点小激动，但是找了下没找到跟他相关的用户名，难道不上了？不过看到了最后一个是熟人的名称缩写，虽然没什么用，但好奇也记下了。

Sqlmap注射出库内所有用户名（表名不常见，用了其他办法找到的，不表）：

Sqlmap.py
–u “http://www.xxx.com/xxx.php?cid=118” –p cpid –D cn397073 –T xxx –C
username --dump

5. 不管有没有用 都到这步了，先注射出密码进去看看：

Sqlmap注射出库内所有密码hash：

Sqlmap.py
–u “http://www.xxx.com/xxx.php?cid=118” –p cpid –D cn397073 –T xxx –C
password --dump

6. 对密码hash解密后得到明文，登陆后台

看了下操作日志，时间习惯不像前男友，只好继续观察，另外后台入口是在网站底部链接里发现的，弱~，后台地址应该写个特殊路径，防止别人知道，显然管理员为了方便自己放在了网站底部，不应该！

无聊之旅结束，没搞破坏，没做任何改动，没得到有用信息，默默看过飘过，连在上边插小红旗这么贱贱而又光辉的事情都没做，我太他表弟的高尚了！不夸自己品德都觉得对不起老大和团队大牛们的教导！完了之后给管理员报个漏洞，老娘低调晋级伪小菜鸟白帽了~

不过看了下这些明文密码，不得不感叹没一个有安全意识的呀，密码几乎都是名字or地名缩写与数字的组合，如果是稍微认识的人都可以直接通过套密码登陆进去，进而进一步的渗透。同志们以后都得注意，防患于未然……于未然……未然……然……然……

转自：http://lijiejava.iteye.com/blog/776587

举例如下 

Customer类： 

Java代码  

1. public class Customer {   
2.     private int id;   
3.     private String name;  
4. private Set orders = new HashSet();  
5. •••  
6. }  

即Customer类具有一个set集合属性orders，其中Order是一个普通的类： 

Java代码  

1. public class Order {   
2.     private int id;   
3.     private String orderName;  
4. •••  
5. }  

数据库中表的结构： 

Java代码  

1. t_customer:  两个字段：id  name  
2. t_order:     三个字段：id  orderName  customerid  

Customer类的映射文件：Customer.hbm.xml  (Order类的映射文件忽略) 

Java代码  

1. <hibernate-mapping>  
2.     <class name="test.Customer" table="t_customer" lazy="false">    
3.         <id name="id">   
4.            <generator class="native"/>  
5.         </id>    
6.         <property name="name"/>    
7.         <set name="orders"  cascade="save-update"  lazy="false">  
8.            <key column="customerid"/>  
9.            <one-to-many class="test.Order"/>  
10.         </set>  
11.     </class>   
12. </hibernate-mapping>  

执行如下代码： 

Java代码  

1. Set orders = new HashSet();   
2.               
3. Order o1 = new Order();  
4. o1.setOrderName("o1");   
5. Order o2 = new Order();  
6. o2.setOrderName("o2");     
7. orders.add(o1);  
8. orders.add(o2);       
9.               
10. Customer c = new Customer();  
11. c.setName("aaa");  
12. c.setOrders(orders);    
13.   
14. session.save(c);   

此时Hibernate发出的sql语句如下： 

Java代码  

1. Hibernate: insert into t_customer (name) values (?)  
2. Hibernate: insert into t_order (orderName) values (?)  
3. Hibernate: insert into t_order (orderName) values (?)  
4. Hibernate: update t_order set customerid=? where id=?  
5. Hibernate: update t_order set customerid=? where id=?  

查看数据库： 

Java代码  

1. t_customer :                    t_order:     
2.   
3. id   |  name                   id   |   orderName   |   customerid   
4. 1       aaa                    1           o1              1  
5.                                2           o2              1   

保存Customer对象时，首先发出insert into t_customer (name) values (?)语句将c同步到数据库，由于在<set>映射中设置cascade="save-update"，所以会同时保存orders集合中的Order类型的o1,o2对象（如果没有这个设置，即cascade="save-update"），那么Hibenrate不会自动保存orders集合中的对象，那么在更新时将会抛出如下异常： 

Java代码  

1. Hibernate: insert into t_customer (name) values (?)  
2. Hibernate: update t_order set customerid=? where id=?  
3. org.hibernate.TransientObjectException: test.Order  
4. ••••••  

抛出这一异常的原因是：<set>映射默认"inverse=fasle"即由Customer对象作为主控方，那么它要负责关联的维护工作，在这里也就是负责更新t_order表中的customerid字段的值，但由于未设置cascade="save-update"，所以orders集合中的对象不会在保存customer时自动保存，因此会抛出异常(如果未设置，需要手动保存)。 
现在设置cascade="save-update"，同时设置inverse="true",即： 

Java代码  

1. •••  
2. <set name="orders" cascade="save-update" inverse="true" lazy="false">  
3.     <key column="customerid"/>  
4.     <one-to-many class="test.Order"/>  
5. </set>    
6. •••  

同样执行上述代码，发出如下语句： 

Java代码  

1. Hibernate: insert into t_customer (name) values (?)  
2. Hibernate: insert into t_order (orderName) values (?)  
3. Hibernate: insert into t_order (orderName) values (?)  

相比上一次执行，少了两条update语句，查看数据库： 

Java代码  

1. t_customer :                    t_order:     
2.   
3. id   |  name                   id   |   orderName   |   customerid   
4. 1       aaa                    1           o1              NULL  
5.                                2           o2              NULL  

发现t_order表中customerid的值为NULL,这是由于设置了inverse="true"，它意味着 
Customer不再作为主控方，而将关联关系的维护工作交给关联对象Orders来完成。在保存Customer时，Customer不在关心Orders的customerid属性，必须由Order自己去维护，即设置order.setCustomer(customer); 

如果需要通过Order来维护关联关系，那么这个关联关系转换成双向关联。 
修改Order类代码： 

Java代码  

1. public class Order {   
2.     private int id;   
3.     private String orderName;    
4.     private Customer customer;  
5. •••  
6. }  

Order.hbm.xml： 

Java代码  

1. <hibernate-mapping>  
2.     <class name="test.Order" table="t_order">    
3.         <id name="id">   
4.            <generator class="native"/>  
5.         </id>    
6.         <property name="orderName"/>     
7.         <many-to-one name="customer" column="customerid"/>   
8.     </class>   
9. </hibernate-mapping>  

此时数据库中表的结构不会变化。 

再次执行上述代码，发出如下sql语句： 

Java代码  

1. Hibernate: insert into t_customer (name) values (?)  
2. Hibernate: insert into t_order (orderName, customerid) values (?, ?)  
3. Hibernate: insert into t_order (orderName, customerid) values (?, ?)   

发现在保存Order对象时为customerid字段赋值，因为Order对象中拥有Customer属性，对应customerid字段，查看数据库表： 

Java代码  

1. t_customer :                    t_order:     
2.   
3. id   |  name                   id   |   orderName   |   customerid   
4. 1       aaa                    1           o1              NULL  
5.                                2           o2              NULL  

发现customerid的值仍为NULL,因为在上述代码中并未设置Order对象的Customer属性值，由于设置了inverse="true"，所以Order对象需要维护关联关系，所以必须进行设置，即 
order.setCustomer(customer); 

修改上述代码为： 

Java代码  

1. •••  
2. Customer c = new Customer();  
3.               
4. Set orders = new HashSet();   
5. Order o1 = new Order();  
6. o1.setOrderName("o1");   
7. o1.setCustomer(c);  
8. Order o2 = new Order();  
9. o2.setOrderName("o2");  
10. o2.setCustomer(c);  
11. orders.add(o1);  
12. orders.add(o2);       
13.               
14. c.setName("aaa");  
15. c.setOrders(orders);   
16.               
17. session.save(c);   
18. •••   
19.    

执行上述代码，发出如下语句： 

Java代码  

1. Hibernate: insert into t_customer (name) values (?)  
2. Hibernate: insert into t_order (orderName, customerid) values (?, ?)  
3. Hibernate: insert into t_order (orderName, customerid) values (?, ?)  

查看数据库： 

Java代码  

1. t_customer :                    t_order:     
2.   
3. id   |  name                   id   |   orderName   |   customerid   
4. 1       aaa                    1           o1              1  
5.                                2           o2              1  

发现已经设置了customerid的值。 

在一对多关联中，在多的一方设置inverse="true",有助于性能的改善。通过上述分析可以发现少了update语句。

• —软件人才免语言低担保 赴美带薪读研！—

原文地址： http://netty.io/wiki/user-guide-for-5.x.html    译者:光辉勇士       校对：郭蕾

前言

问题

现如今我们使用通用的应用程序或者类库来实现系统之间地互相访问，比如我们经常使用一个HTTP客户端来从web服务器上获取信息，或者通过web service来执行一个远程的调用。

然而，一个通用的协议和他的实现有时候并没有覆盖一些场景。比如我们无法使用一个通用的http服务器来对庞大的文件和电子邮件进行交互，再比如也无法处理那种准实时消息比如财务信息和多人游戏数据。我们需要一个高效的协议实现用来处理一些特殊的场景。例如你可以实现一个高效的基于Ajax的聊天应用、媒体流传输或者是大文件传输的http服务器，你甚至可能想自己设计和实现一整个新的协议来准确地定制你自己的需求。

另外不可避免的事情是你不得不处理这些私有协议来确保和原有系统的互通。在这个例子中会告诉你实现一个对应该程序不损耗稳定性和性能的协议是多么的快。

解决方案

Netty是一个提供异步事件驱动的网络应用框架，可以为服务端和客户端提供一个快速迭代开发的高性能、高伸缩性的协议。

换句话说，Netty是一个能够快速简单地来开发网络应用程序的NIO框架比如客户端和服务端的协议，Netty大大简化了网络程序的开发过程比如TCP和UDP的 Socket的开发。

快速和简单并不等于一个应用会产生可维护性和性能的问题，Netty是一个被精心设计的框架，他从许多协议的实现中吸收了很多的经验比如FTP,SMTP,HTTP和许多二进制和基于文本的传统协议，Netty已经成功地找出了解决方案并且在不妥协开发效率、性能、稳定性、灵活性情况下。

有一些用户可能已经发现其他的一些网络框架声称自己也有同样的优势，所以你可能会问是Netty和他们有什么不一样。答案就是Netty的哲学设计理念。Netty从第一天开始就把API和实现设计成为你提供最舒适的使用体验。Netty的设计理念会使当你阅读本指南并且和Netty打交道的时候，让你的使用变得更加简单。
，可以为服务端和客户端提供一个快速迭代开发的高性能、高伸缩性的协议。

换句话说，Netty是一个能够快速简单地来开发网络应用程序的NIO框架比如客户端和服务端的协议，Netty大大简化了网络程序的开发过程比如TCP和UDP的 Socket的开发。

快速和简单并不等于一个应用会产生可维护性和性能的问题，Netty是一个被精心设计的框架，他从许多协议的实现中吸收了很多的经验比如FTP,SMTP,HTTP和许多二进制和基于文本的传统协议，Netty已经成功地找出了解决方案并且在不妥协开发效率、性能、稳定性、灵活性情况下。

有一些用户可能已经发现其他的一些网络框架声称自己也有同样的优势，所以你可能会问是Netty和他们有什么不一样。答案就是Netty的哲学设计理念。Netty从第一天开始就把API和实现设计成为你提供最舒适的使用体验。Netty的设计理念会使当你阅读本指南并且和Netty打交道的时候，让你的使用变得更加简单。
是一个提供异步事件驱动的网络应用框架，可以为服务端和客户端提供一个快速迭代开发的高性能、高伸缩性的协议。

换句话说，Netty是一个能够快速简单地来开发网络应用程序的NIO框架比如客户端和服务端的协议，Netty大大简化了网络程序的开发过程比如TCP和UDP的 Socket的开发。

快速和简单并不等于一个应用会产生可维护性和性能的问题，Netty是一个被精心设计的框架，他从许多协议的实现中吸收了很多的经验比如FTP,SMTP,HTTP和许多二进制和基于文本的传统协议，Netty已经成功地找出了解决方案并且在不妥协开发效率、性能、稳定性、灵活性情况下。

有一些用户可能已经发现其他的一些网络框架声称自己也有同样的优势，所以你可能会问是Netty和他们有什么不一样。答案就是Netty的哲学设计理念。Netty从第一天开始就把API和实现设计成为你提供最舒适的使用体验。Netty的设计理念会使当你阅读本指南并且和Netty打交道的时候，让你的使用变得更加简单。

入门指南

这个章节会围绕Netty核心的结构并附上一些简单的例子让你快速的入门。当你读完本章节你马上就可以用Netty写出一个客户端和一个服务端。

如果你在学习某些东西的时候喜欢自顶向下的方法，你可能想要从第二个章节架构概述开始，然后再回到这里。

开始之前

如果要运行本章节中的2个例子最低要求是：Netty的最新版本(Netty5)和JDK1.6及以上。最新的Netty版本在项目 下载页面。为了下载到正确的JDK版本，请到你偏爱的网站下载。

当你在读的过程中，你可能有很多关于本章节介绍的类相关的问题，每当你想知道他们的更多的信息那么请参考API说明文档。为了方便，所有文档中涉及到的类名字都会被关联到一个在线的API说明。当然如果有任何错误信息、语法错误或者你有任何好的建议来改进文档说明，那么请联系 netty社区。

DISCARD服务(丢弃服务，指的是会忽略所有接收的数据的一种协议)

世界上最简单的协议不是”Hello,World!”，是 DISCARD，他是一种丢弃了所有接受到的数据，并不做有任何的响应的协议。

为了实现DISCARD协议，你唯一需要做的就是忽略所有收到的数据。让我们从处理器的实现开始，处理器是由Netty生成用来处理I/O事件的。

package io.netty.example.discard;

import io.netty.buffer.ByteBuf;

import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelHandlerAdapter;

/**
 * Handles a server-side channel.
 */
public class DiscardServerHandler extends ChannelHandlerAdapter { // (1)

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) { // (2)
        // Discard the received data silently.
        ((ByteBuf) msg).release(); // (3)
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { // (4)
        // Close the connection when an exception is raised.
        cause.printStackTrace();
        ctx.close();
    }
}

1. DisCardServerHandler 继承自 ChannelHandlerAdapter，这个类实现了 ChannelHandler接口， ChannelHandler提供了许多事件处理的接口方法，然后你可以覆盖这些方法。现在仅仅只需要继承 ChannelHandlerAdapter类而不是你自己去实现接口方法。
2. 这里我们覆盖了chanelRead()事件处理方法。每当从客户端收到新的数据时，这个方法会在收到消息时被调用，这个例子中，收到的消息的类型是 ByteBuf
3. 为了实现DISCARD协议，处理器不得不忽略所有接受到的消息。 ByteBuf是一个引用计数对象，这个对象必须显示地调用release()方法来释放。请记住处理器的职责是释放所有传递到处理器的引用计数对象。通常，channelRead()方法的实现就像下面的这段代码：

    @Override
   public void channelRead(ChannelHandlerContext ctx, Object msg) {
       try {
           // Do something with msg
       } finally {
           ReferenceCountUtil.release(msg);
       }
   }

4. exceptionCaught()事件处理方法是当出现Throwable对象才会被调用，即当Netty由于IO错误或者处理器在处理事件时抛出的异常时。在大部分情况下，捕获的异常应该被记录下来并且把关联的channel给关闭掉。然而这个方法的处理方式会在遇到不同异常的情况下有不同的实现，比如你可能想在关闭连接之前发送一个错误码的响应消息。

到目前为止一切都还比较顺利，我们已经实现了DISCARD服务的一半功能，剩下的需要编写一个main()方法来启动服务端的DiscardServerHandler。

package io.netty.example.discard;

import io.netty.bootstrap.ServerBootstrap;

import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelOption;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;

/**
 * Discards any incoming data.
 */
public class DiscardServer {

    private int port;

    public DiscardServer(int port) {
        this.port = port;
    }

    public void run() throws Exception {
        EventLoopGroup bossGroup = new NioEventLoopGroup(); // (1)
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap(); // (2)
            b.group(bossGroup, workerGroup)
             .channel(NioServerSocketChannel.class) // (3)
             .childHandler(new ChannelInitializer<SocketChannel>() { // (4)
                 @Override
                 public void initChannel(SocketChannel ch) throws Exception {
                     ch.pipeline().addLast(new DiscardServerHandler());
                 }
             })
             .option(ChannelOption.SO_BACKLOG, 128)          // (5)
             .childOption(ChannelOption.SO_KEEPALIVE, true); // (6)

            // Bind and start to accept incoming connections.
            ChannelFuture f = b.bind(port).sync(); // (7)

            // Wait until the server socket is closed.
            // In this example, this does not happen, but you can do that to gracefully
            // shut down your server.
            f.channel().closeFuture().sync();
        } finally {
            workerGroup.shutdownGracefully();
            bossGroup.shutdownGracefully();
        }
    }

    public static void main(String[] args) throws Exception {
        int port;
        if (args.length > 0) {
            port = Integer.parseInt(args[0]);
        } else {
            port = 8080;
        }
        new DiscardServer(port).run();
    }
}

1. NioEventLoopGroup是用来处理I/O操作的多线程事件循环器，Netty提供了许多不同的 EventLoopGroup的实现用来处理不同传输协议。在这个例子中我们实现了一个服务端的应用，因此会有2个 NioEventLoopGroup会被使用。第一个经常被叫做‘boss’，用来接收进来的连接。第二个经常被叫做‘worker’，用来处理已经被接收的连接，一旦‘boss’接收到连接，就会把连接信息注册到‘worker’上。如何知道多少个线程已经被使用，如何映射到已经创建的 Channels上都需要依赖于 EventLoopGroup的实现，并且可以通过构造函数来配置他们的关系。
2. ServerBootstrap是一个启动NIO服务的辅助启动类。你可以在这个服务中直接使用 Channel，但是这会是一个复杂的处理过程，在很多情况下你并不需要这样做。
3. 这里我们指定使用 NioServerSocketChannel类来举例说明一个新的 Channel如何接收进来的连接。
4. 这里的事件处理类经常会被用来处理一个最近的已经接收的 Channel。 ChannelInitializer是一个特殊的处理类，他的目的是帮助使用者配置一个新的 Channel。也许你想通过增加一些处理类比如DiscardServerHandle来配置一个新的 Channel或者其对应的 ChannelPipeline来实现你的网络程序。当你的程序变的复杂时，可能你会增加更多的处理类到pipline上，然后提取这些匿名类到最顶层的类上。
5. 你可以设置这里指定的通道实现的配置参数。我们正在写一个TCP/IP的服务端，因此我们被允许设置socket的参数选项比如tcpNoDelay和keepAlive。请参考 ChannelOption和详细的 ChannelConfig实现的接口文档以此可以对ChannelOptions的有一个大概的认识。
6. 你关注过option()和childOption()吗？option()是提供给 NioServerSocketChannel用来接收进来的连接。childOption()是提供给由父管道 ServerChannel接收到的连接，在这个例子中也是 NioServerSocketChannel。
7. 我们继续，剩下的就是绑定端口然后启动服务。这里我们在机器上绑定了机器所有网卡上的8080端口。当然现在你可以多次调用bind()方法(基于不同绑定地址)。

恭喜！你已经完成熟练地完成了第一个基于Netty的服务端程序。

观察接收到的数据

现在我们已经编写出我们第一个服务端，我们需要测试一下他是否真的可以运行。最简单的测试方法是用telnet 命令。例如，你可以在命令行上输入telnet localhost 8080或者其他类型参数。

然而我们能说这个服务端是正常运行了吗？事实上我们也不知道因为他是一个discard服务，你根本不可能得到任何的响应。为了证明他仍然是在工作的，让我们修改服务端的程序来打印出他到底接收到了什么。

我们已经知道channelRead()方法是在数据被接收的时候调用。让我们放一些代码到DiscardServerHandler类的channelRead()方法。

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
    ByteBuf in = (ByteBuf) msg;
    try {
        while (in.isReadable()) { // (1)
            System.out.print((char) in.readByte());
            System.out.flush();
        }
    } finally {
        ReferenceCountUtil.release(msg); // (2)
    }
}

1. 这个低效的循环事实上可以简化为:System.out.println(in.toString(io.netty.util.CharsetUtil.US_ASCII))
2. 或者，你可以在这里调用in.release()。

如果你再次运行telnet命令，你将会看到服务端打印出了他所接收到的消息。
完整的discard server代码放在了 io.netty.example.discard包下面。

ECHO服务（响应式协议）

到目前为止，我们虽然接收到了数据，但没有做任何的响应。然而一个服务端通常会对一个请求作出响应。让我们学习怎样在 ECHO协议的实现下编写一个响应消息给客户端，这个协议针对任何接收的数据都会返回一个响应。

和discard server唯一不同的是把在此之前我们实现的channelRead()方法，返回所有的数据替代打印接收数据到控制台上的逻辑。因此，需要把channelRead()方法修改如下：

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
    ctx.write(msg); // (1)
    ctx.flush(); // (2)
}

1. ChannelHandlerContext对象提供了许多操作，使你能够触发各种各样的I/O事件和操作。这里我们调用了write(Object)方法来逐字地把接受到的消息写入。请注意不同于DISCARD的例子我们并没有释放接受到的消息，这是因为当写入的时候Netty已经帮我们释放了。
2. ctx.write(Object)方法不会使消息写入到通道上，他被缓冲在了内部，你需要调用ctx.flush()方法来把缓冲区中数据强行输出。或者你可以用更简洁的cxt.writeAndFlush(msg)以达到同样的目的。

如果你再一次运行telnet命令，你会看到服务端会发回一个你已经发送的消息。
完整的echo服务的代码放在了 io.netty.example.echo包下面。

TIME服务(时间协议的服务)

在这个部分被实现的协议是 TIME协议。和之前的例子不同的是在不接受任何请求时他会发送一个含32位的整数的消息，并且一旦消息发送就会立即关闭连接。在这个例子中，你会学习到如何构建和发送一个消息，然后在完成时主动关闭连接。

因为我们将会忽略任何接收到的数据，而只是在连接被创建发送一个消息，所以这次我们不能使用channelRead()方法了，代替他的是，我们需要覆盖channelActive()方法，下面的就是实现的内容：

package io.netty.example.time;

public class TimeServerHandler extends ChannelHandlerAdapter {

    @Override
    public void channelActive(final ChannelHandlerContext ctx) { // (1)
        final ByteBuf time = ctx.alloc().buffer(4); // (2)
        time.writeInt((int) (System.currentTimeMillis() / 1000L + 2208988800L));

        final ChannelFuture f = ctx.writeAndFlush(time); // (3)
        f.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture future) {
                assert f == future;
                ctx.close();
            }
        }); // (4)
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
        cause.printStackTrace();
        ctx.close();
    }
}

1. channelActive()方法将会在连接被建立并且准备进行通信时被调用。因此让我们在这个方法里完成一个代表当前时间的32位整数消息的构建工作。
2. 为了发送一个新的消息，我们需要分配一个包含这个消息的新的缓冲。因为我们需要写入一个32位的整数，因此我们需要一个至少有4个字节的 ByteBuf。通过ChannelHandlerContext.alloc()得到一个当前的ByteBufAllocator，然后分配一个新的缓冲。
3. 和往常一样我们需要编写一个构建好的消息。但是等一等，flip在哪？难道我们使用NIO发送消息时不是调用java.nio.ByteBuffer.flip()吗？ByteBuf之所以没有这个方法因为有两个指针，一个对应读操作一个对应写操作。当你向ByteBuf里写入数据的时候写指针的索引就会增加，同时读指针的索引没有变化。读指针索引和写指针索引分别代表了消息的开始和结束。比较起来，NIO缓冲并没有提供一种简洁的方式来计算出消息内容的开始和结尾，除非你调用flip方法。当你忘记调用flip方法而引起没有数据或者错误数据被发送时，你会陷入困境。这样的一个错误不会发生在Netty上，因为我们对于不同的操作类型有不同的指针。你会发现这样的使用方法会让你过程变得更加的容易，因为你已经习惯一种没有使用flip的方式。另外一个点需要注意的是ChannelHandlerContext.write()(和writeAndFlush())方法会返回一个 ChannelFuture对象，一个 ChannelFuture代表了一个还没有发生的I/O操作。这意味着任何一个请求操作都不会马上被执行，因为在Netty里所有的操作都是异步的。举个例子下面的代码中在消息被发送之前可能会先关闭连接。

   Channel ch = ...;
   ch.writeAndFlush(message);
   ch.close();

   因此你需要在write()方法返回的ChannelFuture完成后调用close()方法，然后当他的写操作已经完成他会通知他的监听者。请注意,close()方法也可能不会立马关闭，他也会返回一个 ChannelFuture。

4. 当一个写请求已经完成是如何通知到我们？这个只需要简单地在返回的ChannelFuture上增加一个 ChannelFutureListener。这里我们构建了一个匿名的 ChannelFutureListener类用来在操作完成时关闭Channel。或者，你可以使用简单的预定义监听器代码:

   f.addListener(ChannelFutureListener.CLOSE);

为了测试我们的time服务如我们期望的一样工作，你可以使用UNIX的rdate命令

    $ rdate -o <port> -p <host>

Port是你在main()函数中指定的端口，host使用locahost就可以了。

Time客户端

不像DISCARD和ECHO的服务端，对于TIME协议我们需要一个客户端因为人们不能把一个32位的二进制数据翻译成一个日期或者日历。在这一部分，我们将会讨论如何确保服务端是正常工作的，并且学习怎样用Netty编写一个客户端。

在Netty中,编写服务端和客户端最大的并且唯一不同的使用了不同的 BootStrap和 Channel的实现。请看一下下面的代码：

package io.netty.example.time;

public class TimeClient {
    public static void main(String[] args) throws Exception {
        String host = args[0];
        int port = Integer.parseInt(args[1]);
        EventLoopGroup workerGroup = new NioEventLoopGroup();

        try {
            Bootstrap b = new Bootstrap(); // (1)
            b.group(workerGroup); // (2)
            b.channel(NioSocketChannel.class); // (3)
            b.option(ChannelOption.SO_KEEPALIVE, true); // (4)
            b.handler(new ChannelInitializer<SocketChannel>() {
                @Override
                public void initChannel(SocketChannel ch) throws Exception {
                    ch.pipeline().addLast(new TimeClientHandler());
                }
            });

            // Start the client.
            ChannelFuture f = b.connect(host, port).sync(); // (5)

            // Wait until the connection is closed.
            f.channel().closeFuture().sync();
        } finally {
            workerGroup.shutdownGracefully();
        }
    }
}

1. BootStrap和 ServerBootstrap类似,不过他是对非服务端的channel而言，比如客户端或者无连接传输模式的channel。
2. 如果你只指定了一个 EventLoopGroup，那他就会即作为一个‘boss’线程，也会作为一个‘workder’线程，尽管客户端不需要使用到‘boss’线程。
3. 代替 NioServerSocketChannel的是 NioSocketChannel,这个类在客户端channel被创建时使用。
4. 不像在使用ServerBootstrap时需要用childOption()方法，因为客户端的 SocketChannel没有父channel的概念。
5. 我们用connect()方法代替了bind()方法。

正如你看到的，他和服务端的代码是不一样的。 ChannelHandler是如何实现的?他应该从服务端接受一个32位的整数消息，把他翻译成人们能读懂的格式，并打印翻译好的时间，最后关闭连接:

package io.netty.example.time;

import java.util.Date;

public class TimeClientHandler extends ChannelHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {
        ByteBuf m = (ByteBuf) msg; // (1)
        try {
            long currentTimeMillis = (m.readUnsignedInt() - 2208988800L) * 1000L;
            System.out.println(new Date(currentTimeMillis));
            ctx.close();
        } finally {
            m.release();
        }
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
        cause.printStackTrace();
        ctx.close();
    }
}

1. 在TCP/IP中，NETTY会把读到的数据放到ByteBuf的数据结构中。

这样看起来非常简单，并且和服务端的那个例子的代码也相差不多。然而，处理器有时候会因为抛出IndexOutOfBoundsException而拒绝工作。在下个部分我们会讨论为什么会发生这种情况。

流数据的传输处理

一个小的Socket Buffer问题

在基于流的传输里比如TCP/IP，接收到的数据会先被存储到一个socket接收缓冲里。不幸的是，基于流的传输并不是一个数据包队列，而是一个字节队列。即使你发送了2个独立的数据包，操作系统也不会作为2个消息处理而仅仅是作为一连串的字节而言。因此这是不能保证你远程写入的数据就会准确地读取。举个例子，让我们假设操作系统的TCP/TP协议栈已经接收了3个数据包：

由于基于流传输的协议的这种普通的性质，在你的应用程序里读取数据的时候会有很高的可能性被分成下面的片段。

因此，一个接收方不管他是客户端还是服务端，都应该把接收到的数据整理成一个或者多个更有意思并且能够让程序的业务逻辑更好理解的数据。在上面的例子中，接收到的数据应该被构造成下面的格式：

第一个解决方案

现在让我们回到TIME客户端的例子上。这里我们遇到了同样的问题，一个32字节数据是非常小的数据量，他并不见得会被经常拆分到到不同的数据段内。然而，问题是他确实可能会被拆分到不同的数据段内，并且拆分的可能性会随着通信量的增加而增加。

最简单的方案是构造一个内部的可积累的缓冲，直到4个字节全部接收到了内部缓冲。下面的代码修改了TimeClientHandler的实现类修复了这个问题

package io.netty.example.time;

import java.util.Date;

public class TimeClientHandler extends ChannelHandlerAdapter {
    private ByteBuf buf;

    @Override
    public void handlerAdded(ChannelHandlerContext ctx) {
        buf = ctx.alloc().buffer(4); // (1)
    }

    @Override
    public void handlerRemoved(ChannelHandlerContext ctx) {
        buf.release(); // (1)
        buf = null;
    }

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {
        ByteBuf m = (ByteBuf) msg;
        buf.writeBytes(m); // (2)
        m.release();

        if (buf.readableBytes() >= 4) { // (3)
            long currentTimeMillis = (buf.readInt() - 2208988800L) * 1000L;
            System.out.println(new Date(currentTimeMillis));
            ctx.close();
        }
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
        cause.printStackTrace();
        ctx.close();
    }
}

1. ChannelHandler有2个生命周期的监听方法：handlerAdded()和handlerRemoved()。你可以完成任意初始化任务只要他不会被阻塞很长的时间。
2. 首先，所有接收的数据都应该被累积在buf变量里。
3. 然后，处理器必须检查buf变量是否有足够的数据，在这个例子中是4个字节，然后处理实际的业务逻辑。否则，Netty会重复调用channelRead()当有更多数据到达直到4个字节的数据被积累。

第二个解决方案

尽管第一个解决方案已经解决了Time客户端的问题了，但是修改后的处理器看起来不那么的简洁，想象一下如果由多个字段比如可变长度的字段组成的更为复杂的协议时，你的 ChannelHandler的实现将很快地变得难以维护。

正如你所知的，你可以增加多个 ChannelHandler到 ChannelPipeline ,因此你可以把一整个 ChannelHandler拆分成多个模块以减少应用的复杂程度，比如你可以把TimeClientHandler拆分成2个处理器：

• TimeDecoder处理数据拆分的问题
• TimeClientHandler原始版本的实现

幸运地是，Netty提供了一个可扩展的类，帮你完成TimeDecoder的开发。

package io.netty.example.time;

public class TimeDecoder extends ByteToMessageDecoder { // (1)
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) { // (2)
        if (in.readableBytes() < 4) {
            return; // (3)
        }

        out.add(in.readBytes(4)); // (4)
    }
}

1. ByteToMessageDecoder是 ChannelHandler的一个实现类，他可以在处理数据拆分的问题上变得很简单。
2. 每当有新数据接收的时候， ByteToMessageDecoder都会调用decode()方法来处理内部的那个累积缓冲。
3. Decode()方法可以决定当累积缓冲里没有足够数据时可以往out对象里放任意数据。当有更多的数据被接收了 ByteToMessageDecoder会再一次调用decode()方法。
4. 如果在decode()方法里增加了一个对象到out对象里，这意味着解码器解码消息成功。 ByteToMessageDecoder将会丢弃在累积缓冲里已经被读过的数据。请记得你不需要对多条消息调用decode()， ByteToMessageDecoder会持续调用decode()直到不放任何数据到out里。

现在我们有另外一个处理器插入到 ChannelPipeline里，我们应该在TimeClient里修改 ChannelInitializer的实现：

b.handler(new ChannelInitializer<SocketChannel>() {
    @Override
    public void initChannel(SocketChannel ch) throws Exception {
        ch.pipeline().addLast(new TimeDecoder(), new TimeClientHandler());
    }
});

如果你是一个大胆的人，你可能会尝试使用更简单的解码类 ReplayingDecoder。不过你还是需要参考一下API文档来获取更多的信息。

public class TimeDecoder extends ReplayingDecoder {
@Override
protected void decode(
ChannelHandlerContext ctx, ByteBuf in, Listout) {out.add(in.readBytes(4));}}此外，Netty还提供了更多可以直接拿来用的解码器使你可以更简单地实现更多的协议，帮助你避免开发一个难以维护的处理器实现。请参考下面的包以获取更多更详细的例子：

• 对于二进制协议请看 io.netty.example.factorial
• 对于基于文本协议请看 io.netty.example.telnet

用POJO代替ByteBuf

我们已经讨论了所有的例子，到目前为止一个消息的消息都是使用 ByteBuf作为一个基本的数据结构。在这一部分，我们会改进TIME协议的客户端和服务端的例子，用POJO替代 ByteBuf。在你的 ChannelHandlerS中使用POJO优势是比较明显的。通过从 ChannelHandler中提取出ByteBuf的代码，将会使 ChannelHandler的实现变得更加可维护和可重用。在TIME客户端和服务端的例子中，我们读取的仅仅是一个32位的整形数据，直接使用ByteBuf不会是一个主要的问题。然后，你会发现当你需要实现一个真实的协议，分离代码变得非常的必要。首先，让我们定义一个新的类型叫做UnixTime。

package io.netty.example.time;import java.util.Date;public class UnixTime {    private final int value;    public UnixTime() {        this((int) (System.currentTimeMillis() / 1000L + 2208988800L));    }    public UnixTime(int value) {        this.value = value;    }    public int value() {        return value;    }    @Override    public String toString() {        return new Date((value() - 2208988800L) * 1000L).toString();    }}

现在我们可以修改下TimeDecoder类，返回一个UnixTime，以替代 ByteBuf

@Overrideprotected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {    if (in.readableBytes() < 4) {        return;    }    out.add(new UnixTime(in.readInt()));}

下面是修改后的解码器，TimeClientHandler不再有任何的 ByteBuf代码了。

@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg) {    UnixTime m = (UnixTime) msg;    System.out.println(m);    ctx.close();}

是不是变得更加简单和优雅了？相同的技术可以被运用到服务端。让我们修改一下TimeServerHandler的代码。

@Overridepublic void channelActive(ChannelHandlerContext ctx) {    ChannelFuture f = ctx.writeAndFlush(new UnixTime());    f.addListener(ChannelFutureListener.CLOSE);}

现在，仅仅需要修改的是 ChannelHandler的实现，这里需要把UnixTime对象重新转化为一个 ByteBuf。不过这已经是非常简单了，因为当你对一个消息编码的时候，你不需要再处理拆包和组装的过程。

package io.netty.example.time;public class TimeEncoder extends ChannelHandlerAdapter {    @Override    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) {        UnixTime m = (UnixTime) msg;        ByteBuf encoded = ctx.alloc().buffer(4);        encoded.writeInt(m.value());        ctx.write(encoded, promise); // (1)    }}

1. 在这几行代码里还有几个重要的事情。第一， 通过 ChannelPromise，当编码后的数据被写到了通道上Netty可以通过这个对象标记是成功还是失败。第二， 我们不需要调用cxt.flush()。因为处理器已经单独分离出了一个方法void flush(ChannelHandlerContext cxt),如果像自己实现flush方法内容可以自行覆盖这个方法。

进一步简化操作，你可以使用 MessageToByteEncode:

public class TimeEncoder extends MessageToByteEncoder<UnixTime> {    @Override    protected void encode(ChannelHandlerContext ctx, UnixTime msg, ByteBuf out) {        out.writeInt(msg.value());    }}

最后的任务就是在TimeServerHandler之前把TimeEncoder插入到 ChannelPipeline。但这是不那么重要的工作。

关闭你的应用

关闭一个Netty应用往往只需要简单地通过shutdownGracefully()方法来关闭你构建的所有的 NioEventLoopGroupS.当 EventLoopGroup被完全地终止,并且对应的所有 channels都已经被关闭时，Netty会返回一个 Future对象。

概述

在这一章节中，我们会快速地回顾下如果在熟练掌握Netty的情况下编写出一个健壮能运行的网络应用程序。在Netty接下去的章节中还会有更多更相信的信息。我们也鼓励你去重新复习下在 io.netty.example包下的例子。请注意 社区一直在等待你的问题和想法以帮助Netty的持续改进，Netty的文档也是基于你们的快速反馈上。

（全文完）如果您喜欢此文请点赞，分享，评论。

• 原创文章转载请注明出处： Netty 5用户指南
• 小额赞助本站：： 我要赞助