1.简单化-信使messenger+集合型参数(collecting parameter)

?

?

以下就开始我们的设计模式之旅吧!其实这里我说一下题外话先，为什么我要写博客，其实写博客这个我很久就想写，一开始想写一个很威的博客，但是发现还是没什么人看我的博客，但是我却发现了意外的收获，有些时候只看书，是发现不了你不懂什么的，必须写出来，通过写这一个途径，你会慢慢的去挖掘这个问题的深度，一步一步的揭开面纱，你会发现这是一个有趣的过程...

?

?

?

?

简单化：

在研究复杂技术之前，了解使代码简单明了的基本方法是很用帮助的。其实这一句说到了我的心里面，很多时候我把问题想的很复杂，功能很全面，考虑了很多东西，但是一开始入手编程，连最基本的功能都遇到了砍，无疑我的心里压力是非常大的，慢慢的编程下去，发现这是一个不可能实现的认为，慢慢的，这个项目就死掉了。对于现在来说，我更偏向于代码的结构是一种思想，而这个是要在实现基本功能的情况前提上，设计模式不是一下子就出来的，先简单后复杂。

?

?

?

?

信使模式(messenger)：

这个我找一下，提及到的资料不多。不过的确是一个很好的东西；其实最简单的东西才是最常用，最有用的，最实际的。而信使模式很好的诠释了这个概念。由名字就可以发现他的含义，把需要传的东西包装在信封内，然后传输。

?

示例代码：

//一个简单的信息类

class message {

public String recName;

public String sendName;

public String msg;

?

?

//构造方法

public message(String?recName,String sendName,String?msg){

this.recName=recName;

this.sendName=msg;

this.msg=msg;

}

}

?

?

?

?

//定义一个测试类

public class TestDemo{

?

public static void main(String[] str){

message m=new message("shadow","dan","hello,are you ok?");

translate(m);

}

?

?

?

//这里就使用了模式，传入一个对象，传输

public static translate(message m){

?

System.out.println(m.recName+m.msg+m.sendName);

}

}

?

?

?

因为messenger 只是用来传送数据，它所传送的数据通常声明为公有的，以便于

存取。但是，你可以根据自己的需要把它们声明成私有的。

?

这个信使模式，是我平时经常用到的，也是非常好用的一个东西;

?

?

?

集合型参数 (collecting parameter)

这个是信使的兄弟啊，为什么这么说呢，因为信使是传输对象，而集合型参数的作用就是将传输进来的对象当成是收集的容器，一个比喻可以这样子，就是你是信使，给我一个信封，这个信封这时候是一个list(一个大信封)，然后我用这个大信封去收集好多个其他的东西，放在里面。

示例

public class test {

public static void main(String[] args){

List list=new ArrayList();

for(int i=0;i<15;i++){

collect(list);

}

System.out.println(list.get(5));

}

?

//通过不断调用这个方法，而达到收集的目的，这里为了简单起见，我只定义一个方法，其实你可以定义几个的

只要传入的参数是list就好

public static void collect(List list){

?

list.add("hello");

}

}

?

其实书上的例子写的很好，不过我尽量将东西简单化，只要将其精髓表现出来就好，然后再进行深一步的变形就ok了

Collecting parameter 必须支持通过某些方法设置或者插入一些值。根据这个定

义，信使可以当作collecting parameter 来用，前提是collecting parameter 是由它所传递给的方法来修改的。

?

?

这两种模式其实可以演变出许多很好的效果的，比如说集合型参数可以用来收集结果等等，有一句话说的很对：设计模式的每一个模式我都理解，他的内涵我都明白，但是我就是不知道在哪里用，什么时候用，用哪个好？ ?其实这个也是困惑了我好久的地方，我的经验就是有很多模式很难在第一次编写这个项目的时候使用上的，只有在下一次重构的时候，发现原来这里是可以用这个模式，然后不断的重构，实现这个模式，等到后面又会发现原来那个模式在这里更加适合，更加好用，一直这样不断的总结，不断的去尝试，然后就会得到一些良好的编程风格，也就是越来越优雅。