Skip to content

Commit 97e10bc

Browse files
hehonghuihehonghui
committed
update
1 parent 1d9fae6 commit 97e10bc

File tree

2 files changed

+226
-30
lines changed

2 files changed

+226
-30
lines changed

‎README.md‎

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -36,12 +36,10 @@
3636
| [享元模式](flyweight/lvtea0105) | [lvtea0105](https://github.com/lvtea0105) | 撒丫子赶稿中 |
3737
| [迭代器模式](iterator/haoxiqiang) | [Haoxiqiang](https://github.com/Haoxiqiang)| 完成 |
3838
| [责任链模式](chain-of-responsibility/AigeStudio) | [AigeStudio](https://github.com/AigeStudio)| 完成 |
39-
| [工厂方法模式](factory-method/AigeStudio) | [AigeStudio](https://github.com/AigeStudio)| 撒丫子赶稿中 |
40-
| [抽象工厂模式](abstract-factory/AigeStudio) | [AigeStudio](https://github.com/AigeStudio)| 撒丫子赶稿中 |
4139
| [状态模式](state/Thinan) | [Thinan](https://www.github.com/Thinan)| 撒丫子赶稿中 |
4240
| [命令模式](command/lijunhuayc) | [lijunhuayc](https://github.com/lijunhuayc)| 待审核 |
43-
| [桥接模式](bridge/shen0834) | [shen0834](https://github.com/shen0834)| 撒丫子赶稿中 |
44-
| [原型模式](prototype/mr.simple) | [Mr.Simple](https://github.com/bboyfeiyu)| 待审核 |
41+
| [桥接模式](bridge/shen0834) | [shen0834](https://github.com/shen0834)| 完成 |
42+
| [原型模式](prototype/mr.simple) | [Mr.Simple](https://github.com/bboyfeiyu)| 完成 |
4543

4644

4745

‎bridge/shen0834/readme.md‎

Lines changed: 224 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -4,55 +4,253 @@ Android设计模式源码解析之${模式名}
44
> Android系统版本： ${系统版本号，例如 4.2.1}
55
> 分析者：[${分析者}](${分析者 Github 地址})，分析状态：未完成，校对者：[Mr.Simple](https://github.com/bboyfeiyu)，校对状态：未开始
66
7+
## 模式介绍
78

8-
`复制一份到自己的项目文件夹下，然后根据自己项目替换掉 ${} 内容，删掉本行及上面两行。`
9-
10-
该任务不仅要用java写出该模式的一个简单示例，还有分析该模式在Android源码中的应用，可以参考[Mr.Simple的单例模式](singleton/mr.simple/readme.md)、[Mr.Simple的观察者模式](observer/mr.simple/readme.md)。
11-
12-
13-
## 1. 模式介绍
14-
15-
### 模式的定义
16-
`模式的一句话定义`
9+
### 模式的定义
1710

11+
将抽象部分与实现部分分离，使它们都可以独立的变化。
1812

1913
### 模式的使用场景
20-
21-
14+
* 如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性，避免在两个层次之间建立静态的联系。
15+
* 设计要求实现化角色的任何改变不应当影响客户端，或者实现化角色的改变对客户端是完全透明的。
16+
* 需要跨越多个平台的图形和窗口系统上。
17+
* 一个类存在两个独立变化的维度，且两个维度都需要进行扩展。
2218

23-
## 2. UML类图
24-
`这里是该设计模式的经典UML图`
19+
### UML类图
20+
21+
![uml](http://img.blog.csdn.net/20150322120730408)
2522

2623
### 角色介绍
27-
`对UML图中的各个角色进行介绍`
2824

25+
* 抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
26+
修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
27+
* 实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接 口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
28+
* 具体实现化(ConcreteImplementor)角色：这个角色给出实现化角色接口的具体实现。
2929

30+
## 模式的简单实现
3031

32+
### 简单实现的介绍
3133

32-
## 3. 模式的简单实现
33-
### 简单实现的介绍
34-
`自己实现一个小型模式案例，通过这个案例让读者了解这个模式的一般应用`
34+
其实Java的虚拟机就是一个很好的例子，在不同平台平台上，用不同的虚拟机进行实现，这样只需把Java程序编译成符合虚拟机规范的文件，且只用编译一次，便在不同平台上都能工作。 但是这样说比较抽象，用一个简单的例子来实现bridge模式。
3535

36-
### 实现源码
37-
`上述案例的源码实现`
36+
编写一个程序，使用两个绘图的程序的其中一个来绘制矩形或者原型，同时，在实例化矩形的时候，它要知道使用绘图程序1（DP1）还是绘图程序2（DP2）。
3837

38+
(ps:假设dp1和dp2的绘制方式不一样，它们是用不同方式进行绘制，示例代码，不讨论过多细节)
3939

40-
### 总结
41-
`对上述的简单示例进行总结说明`
40+
### 实现源码
4241

42+
```java
43+
首先是两个绘图程序dp1,dp2
44+
//具体的绘图程序类dp1
45+
public class DP1 {
46+
47+
public void draw_1_Rantanle(){
48+
System.out.println("使用DP1的程序画矩形");
49+
}
50+
51+
public void draw_1_Circle(){
52+
System.out.println("使用DP1的程序画圆形");
53+
}
54+
}
55+
//具体的绘图程序类dp2
56+
public class DP2 {
4357

58+
public void drawRantanle(){
59+
System.out.println("使用DP2的程序画矩形");
60+
}
61+
62+
public void drawCircle(){
63+
System.out.println("使用DP2的程序画圆形");
64+
}
65+
66+
}
67+
接着​抽象的形状Shape和两个派生类：矩形Rantanle和圆形Circle
68+
//抽象化角色Abstraction
69+
abstract class Shape {
70+
//持有实现的角色Implementor(作图类)
71+
protected Drawing myDrawing;
72+
73+
public Shape(Drawing drawing) {
74+
this.myDrawing = drawing;
75+
}
76+
77+
abstract public void draw();
78+
79+
//保护方法drawRectangle
80+
protected void drawRectangle(){
81+
//this.impl.implmentation()
82+
myDrawing.drawRantangle();
83+
}
84+
85+
//保护方法drawCircle
86+
protected void drawCircle(){
87+
//this.impl.implmentation()
88+
myDrawing.drawCircle();
89+
}
90+
}
91+
//修正抽象化角色Refined Abstraction(矩形)
92+
public class Rantangle extends Shape{
93+
public Rantangle(Drawing drawing) {
94+
super(drawing);
95+
}
96+
97+
@Override
98+
public void draw() {
99+
drawRectangle();
100+
}
101+
}
102+
//修正抽象化角色Refined Abstraction(圆形)
103+
public class Circle extends Shape {
104+
public Circle(Drawing drawing) {
105+
super(drawing);
106+
}
107+
@Override
108+
public void draw() {
109+
drawCircle();
110+
}
111+
}
112+
最后，我们的实现绘图的Drawing和分别实现dp1的V1Drawing和dp2的V2Drawing
113+
//实现化角色Implementor
114+
//implmentation两个方法，画圆和画矩形
115+
public interface Drawing {
116+
public void drawRantangle();
117+
public void drawCircle();
118+
}
119+
//具体实现化逻辑ConcreteImplementor
120+
//实现了接口方法，使用DP1进行绘图
121+
public class V1Drawing implements Drawing{
122+
123+
DP1 dp1;
124+
125+
public V1Drawing() {
126+
dp1 = new DP1();
127+
}
128+
@Override
129+
public void drawRantangle() {
130+
dp1.draw_1_Rantanle();
131+
}
132+
@Override
133+
public void drawCircle() {
134+
dp1.draw_1_Circle();
135+
}
136+
}
137+
//具体实现化逻辑ConcreteImplementor
138+
//实现了接口方法，使用DP2进行绘图
139+
public class V2Drawing implements Drawing{
140+
DP2 dp2;
141+
142+
public V2Drawing() {
143+
dp2 = new DP2();
144+
}
145+
146+
@Override
147+
public void drawRantangle() {
148+
dp2.drawRantanle();
149+
}
150+
@Override
151+
public void drawCircle() {
152+
dp2.drawCircle();
153+
}
154+
}
155+
```
44156

157+
​在这个示例中，图形Shape类有两种类型，圆形和矩形，为了使用不同的绘图程序绘制图形，把实现的部分进行了分离，构成了Drawing类层次结构，包括V1Drawing和V2Drawing。在具体实现类中，V1Drawing控制着DP1程序进行绘图，V2Drawing控制着DP2程序进行绘图，以及保护的方法drawRantangle,drawCircle(Shape类中) 。
45158

46159
## Android源码中的模式实现
47-
`分析源码中的模式实现，列出相关源码，以及使用该模式原因等`
48160

161+
在Android中也运用到了Bridge模式，我们使用很多的ListView和BaseAdpater其实就是Bridge模式的运行，很多人会问这个不是Adapter模式，接下来根据源码来分析。
49162

50-
163+
首先ListAdapter.java：
164+
165+
```java
166+
public interface ListAdapter extends Adapter{
167+
//继承自Adapter，扩展了自己的两个实现方法
168+
public boolean areAllItemsEnabled();
169+
boolean isEnabled(int position);
170+
}
171+
```
172+
173+
这里先来看一下父类AdapterView。
174+
175+
```java
176+
public abstract class AdapterView<T extends Adapter> extends ViewGroup {
177+
//这里需要一个泛型的Adapter
178+
public abstract T getAdapter();
179+
public abstract void setAdapter(T adapter);
180+
}
181+
```
182+
183+
接着来看ListView的父类AbsListView，继承自AdapterView
184+
185+
```java
186+
public abstract class AbsListView extends AdapterView<ListAdapter>
187+
//继承自AdapterView,并且指明了T为ListAdapter
188+
/**
189+
* The adapter containing the data to be displayed by this view
190+
*/
191+
ListAdapter mAdapter;
192+
//代码省略
193+
//这里实现了setAdapter的方法，实例了对实现化对象的引用
194+
public void setAdapter(ListAdapter adapter) {
195+
//这的adapter是从子类传入上来，也就是listview，拿到了具体实现化的对象
196+
if (adapter != null) {
197+
mAdapterHasStableIds = mAdapter.hasStableIds();
198+
if (mChoiceMode != CHOICE_MODE_NONE && mAdapterHasStableIds &&
199+
mCheckedIdStates == null) {
200+
mCheckedIdStates = new LongSparseArray<Integer>();
201+
}
202+
}
203+
if (mCheckStates != null) {
204+
mCheckStates.clear();
205+
}
206+
if (mCheckedIdStates != null) {
207+
mCheckedIdStates.clear();
208+
}
209+
}
210+
```
211+
212+
大家都知道，构建一个listview，adapter中最重要的两个方法，getCount()告知数量，getview()告知具体的view类型，接下来看看AbsListView作为一个视图的集合是如何来根据实现化对象adapter来实现的具体的view呢？
213+
214+
```java
215+
protected void onAttachedToWindow() {
216+
super.onAttachedToWindow();
217+
218+
//省略代码，
219+
//这里在加入window的时候，getCount()确定了集合的个数
220+
mDataChanged = true;
221+
mOldItemCount = mItemCount;
222+
mItemCount = mAdapter.getCount();
223+
}
224+
}
225+
```
226+
227+
接着来看
228+
229+
```java
230+
View obtainView(int position, boolean[] isScrap) {
231+
//代码省略
232+
​//这里根据位置显示具体的view,return的child是从持有的实现对象mAdapter里面的具体实现的
233+
​//方法getview来得到的。
234+
final View child = mAdapter.getView(position, scrapView, this);
235+
//代码省略
236+
return child;
237+
}
238+
```
239+
240+
接下来在ListView中，onMeasure调用了obtainView来确定宽高，在扩展自己的方法来排列这些view。知道了
241+
242+
这些以后，我们来画一个简易的UML图来看下:
243+
244+
![uml](http://img.blog.csdn.net/20150322120809221)
245+
246+
对比下GOF的上图，是不是发现很像呢？实际上最开始研究Adapter模式的时候,越看越不对啊，于是整理结构，画了UML发现这更像是一个bridge模式，那时候对设计模式也是模模糊糊的，于是静下来研究。抽象化的角色一个视图的集合AdapterView，它扩展了AbsListView，AbsSpinner，接下来他们分别扩展了ListView，GridView，Spinner,Gallery，用不同方式来展现这些ItemViews，我们继续扩展类似ListView的PulltoRefreshView等等。而实现化角色Adapter扩展了ListAdpater,SpinnerAdapter，接着具体的实现化角色BaseAdapter实现了他们，我们通过继承BaseAdapter又实现了我们各式各样的ItemView。
51247

52-
## 4. 杂谈
53-
该模式的优缺点以及自己的一些感悟，非所有项目必须。
54248

249+
## 杂谈
55250

251+
这里就是Android工程师的牛X之处了，用一个bridge和adapter来解决了一个大的难题。试想一下，视图的排列方式是无穷尽，是人们每个人开发的视图也是无穷尽的。如果你正常开发，你需要多少类来完成呢？而Android把最常用用的展现方式全部都封装了出来，而在实现角色通过Adapter模式来应变无穷无尽的视图需要。抽象化了一个容器使用适配器来给容器里面添加视图，容器的形状(或理解为展现的方式)以及怎么样来绘制容器内的视图，你都可以独自的变化，双双不会干扰，真正的脱耦，就要最开始说的那样：“将抽象部分与实现部分分离，使它们都可以独立的变化。”
56252

57-
`写完相关内容之后到开发群告知管理员，管理员安排相关人员进行审核，审核通过之后即可。`
253+
从上面的两个案例，我们可以看出，我们在两个解决方案中都用到bridge和adapter模式，那是因为我们必须使用给定的绘图程序(adapter适配器)，绘图程序(adapter适配器)有已经存在的接口必须要遵循，因此需要使用Adapter进行适配，然后才能用同样的方式处理他们,他们经常一起使用，并且相似，但是Adapter并不是Bridge的一部分。
58254

255+
### 优点与缺点
256+
实现与使用实现的对象解耦，提供了可扩展性，客户对象无需担心操作的实现问题。 如果你采用了bridge模式，在处理新的实现将会非常容易。你只需定义一个新的具体实现类，并且实现它就好了，不需要修改任何其他的东西。但是如果你出现了一个新的具体情况，需要对实现进行修改时，就得先修改抽象的接口，再对其派生类进行修改，但是这种修改只会存在于局部,并且这种修改将变化的英雄控制在局部，并且降低了出现副作用的风险，而且类之间的关系十分清晰，如何实现一目了然。

0 commit comments

Comments
 (0)