南贺神社

你写程序有写诗一样的感觉吗?

0%

Posted on Edited on In Views:

思想：将一个类的抽象定义和具体实现解耦。
场景：该 模式的典型应用场景是：一个类的抽象定义已经确定，但是，其实现代码甚至原理可能会不同。比如：我们最熟悉的图形界面中的window的 实现，无论在什么操作系统，什么平台的机器上，一个window应具有的抽象定义基本上是一致的， 但是，其实现代码肯定会因为平台不同，机器的代码指令不同而不同。此时，如果希望您写的window类 能跨平台，应用Bridge模式就是一个好主意。
实现：该 模式的实现方法很简单，就是除了定义类的抽象定义之外，将一个类的所有实现代码独立出一个实现类。这样一来，无论是抽象定义还是实现类都能分别修改和重 用，但只要两部分的交互接口不变，还是可以方便的互相组装。当然，实际上也没有必要隔离出“所有实现代码”，只需要隔离需要的部分就行了。因此，也可以 说，从代码结构来看，Builder模式是一种变种的Bridge模 式的。也经常有人将Bridge模式和接口相比较，如果隔离出所有的实现，那么的确接口的方式也能 做到抽象定义和实现分离，但是，Bridge有其优势如下：一、究竟隔离多少代码到Bridge类 中可以灵活确定，二、减少了总的类的数目，三、允许被隔离出来的Bridge类被其它的类直接共享 使用。

Read more »

Posted on Edited on In Views:

思想：为一个对象已有的子类添加一些额外的职责。
场景：该模式的使用场景，主要是有的时候我们不愿意定义逻辑上新的子类，因为没有新的逻辑含义上的子类概念，而只是想为一个已存在的子类附加 一些职责。
实现：该 模式的实现主要就是定义一个物理上的新的子类，但是，它只是包含要附加职责的类，传递外部对相同接口的调用，在这个传递调用的通道上附加额外的功能。突然 想到，Decorator模式是不是一定程度上也能代替DynamicProxy模 式，从而成为一种AOP实现的方案呢？

Read more »

Posted on Edited on In Views:

思想：将 对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致 性。
场景：该 模式的应用场景极其类似，比如像图形系统，如电路设计、UML建模系统，或者像web的 显示元素等，都是那种需要整体和部分具有使用接口上的一定的一致性的需求的结构，实际上，我觉得这样的系统如果不使用Composite模 式将会是惨不忍睹的。

Read more »

Posted on Edited on In Views:

一、Hadoop2.5.1编译zlib的安装与使用

zlib是一个很好的压缩解压缩库，今天我们分别介绍如何在Linux与Windows上安装与使用：

Read more »

Posted on Edited on In Views:

思想：将一个类的接口转换成另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
场景：该 模式的应用场景太多了，很多需要的功能模块的接口和我们需要的不完全一致或者有多余或不足，但是需要和我们的系统协同工作，通过Adapter把 它包装一下就能让使它接口兼容了。
实现：定 义一个Adapter类，包含需要包装的类，实现需要的其它接口，调用被包装的类的方法来实现需要 的接口。

Read more »

Posted on Edited on In Views:

思想：为子系统中的一组接口提供一个一致的界面，这个接口使得这一子系统更加容易使用。
场景：当 你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性， 也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可 以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他 的子系统分离，可以提高子系统的独立性和可移植性。当你需要构建一个层次结构的子系统时，使用Facade模 式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通 讯，从而简化了它们之间的依赖关系。（这里直接引用了《设计模式迷你手册》，因为觉得它确实已经说得很明了了，下面类似的情形我直接引用原文的就不再注明 了，这里先说明一下，感谢《手册》作者的这些优秀总结。当然，本文的绝大多数文字都是Teddy本 人的原创看法，绝非抄袭，您可以比较本文和附件《手册》，附件同时也会提供本文的Word版本下 载。）
实现：该 模式的实现需要定义一个新的系统构架上的Layer，该层向上提供一组新的接口，向下调用子系统原 有的接口。

Read more »

Posted on Edited on In Views:

定义面包类：

1
2
3
4
5
6
7
8
9
10
11
12
<!-- more -->
package ProducerAndConsumer;

public class Bread {
public int id;
public int producerid;
public Bread(int id,int producerid){
	this.id = id;
	this.producerid = producerid;
}
}

定义一个篮子，里边放一个数组存放面包：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
package ProducerAndConsumer;

public class Basket {
	private Bread[] basket = new Bread[10];
    private int index = 0;
	public synchronized void push(Bread bread) {
	//发现篮子满了，就在那里不停的等着
	System.out.println("生产者等待。。。。。。");
		while(this.index==basket.length){
			try {
			//（一个生产线程）开始不停等待  
                // 他需要等待顾客(一个消费线程)把它叫醒
				this.wait();
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
		     // 唤醒一个正在等待的线程，如果唤醒的线程为生产线程，则又会进入等待状态，  
        // 如果为消费线程，则因生产线程生产了面包的缘故，消费线程可以进行消费  
		this.notify();
		basket[this.index] = bread;
		this.index++;
		System.out.println("生产者"+bread.producerid+"生产一个面包");		
	}

	public synchronized void pop(int index){
		while(this.index==0){
			System.out.println("消费者等待。。。。。。。。");
			try {
				this.wait();
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
		this.notify();
		basket[this.index]=null;
		this.index--;
		System.out.println("消费者"+index+"取走一个面包");
	}

}

定义生产者者：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package ProducerAndConsumer;

public class Producer implements Runnable{
private int id;
private Basket basket;
public Producer(int id,Basket basket){
	this.id = id;
	this.basket = basket;
}
	public void run() {
		for(int i=0;i<=10;i++){
			Bread bread = new Bread(i,this.id);
			basket.push(bread);
			try {
				Thread.sleep(1);
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}

}

定义消费者：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package ProducerAndConsumer;

public class Consumer implements Runnable{
private int id;
private Basket basket;
	public Consumer(int id,Basket basket){
		this.id=id;
		this.basket = basket;
	}
	public void run() {
		for(int i=0;i<=10;i++){
			basket.pop(id);
			try {
				Thread.sleep(1);
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}

}

测试类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package ProducerAndConsumer;

public class Launcher {

	public static void main(String[] args) {
		Basket basket = new Basket();
		Producer p1 = new Producer(1,basket);
		Producer p2 = new Producer(2,basket);

		Consumer c1 = new Consumer(1,basket);
		Consumer c2 = new Consumer(2,basket);

		new Thread(p1).start();
		new Thread(p2).start();
		new Thread(c1).start();
		new Thread(c2).start();
	}
}

数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
生产者1生产一个面包
生产者2生产一个面包
消费者1取走一个面包
消费者2取走一个面包
生产者2生产一个面包
消费者1取走一个面包
消费者等待。。。。。。。。
生产者1生产一个面包
消费者2取走一个面包
生产者2生产一个面包
消费者2取走一个面包
生产者1生产一个面包
消费者1取走一个面包
生产者1生产一个面包
消费者1取走一个面包
消费者等待。。。。。。。。
生产者2生产一个面包
消费者2取走一个面包
生产者2生产一个面包
消费者2取走一个面包
消费者等待。。。。。。。。
生产者1生产一个面包
消费者1取走一个面包
生产者2生产一个面包
消费者2取走一个面包
消费者等待。。。。。。。。
生产者1生产一个面包
消费者1取走一个面包
消费者等待。。。。。。。。
消费者等待。。。。。。。。
生产者2生产一个面包
消费者2取走一个面包
消费者等待。。。。。。。。
生产者1生产一个面包
消费者1取走一个面包
生产者2生产一个面包
生产者1生产一个面包
消费者2取走一个面包
消费者1取走一个面包
生产者2生产一个面包
消费者2取走一个面包
消费者等待。。。。。。。。
生产者1生产一个面包
消费者1取走一个面包
消费者等待。。。。。。。。
生产者2生产一个面包
生产者1生产一个面包
消费者2取走一个面包
消费者1取走一个面包
生产者2生产一个面包
消费者2取走一个面包
消费者等待。。。。。。。。
生产者1生产一个面包
消费者1取走一个面包


Posted on Edited on In Views:

思想：将一个类的创建过程和他的主体部分分离。
场景：该模式的典型的应用场景是：一个类的创建过程可能比较复杂，或者创建过程中的某些阶段可能会容易变化；或者多个类的创建过程比较类似， 但是主体不同。

Read more »

Posted on Edited on In Views:

这里写图片描述
思想：克 隆一个已有的类的实例（大家相比都用过甚至写过类的Clone实现，应该很容易理解了）。
场景：应 用Clone的场景应该说非常多，理想情况下我当然希望任何类都能Clone， 需要的时候就能Clone一份一模一样的出来。

Read more »