发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 376 | 阅读时长 ≈ 1 分钟

设计模式专题系列: 设计模式

外观模式(Facade)

外观模式： 提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

或者说：将一个类或数个类的复杂的一切都隐藏在背后，只显露出一个感觉美好的外观。

外观模式创建一个接口简化而统一的类，用来包装子系统中的一个或者多个复杂的类，而暴露给客户端的是非常简单的接口，让 客户端和子系统解耦。

阅读全文 »

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 374 | 阅读时长 ≈ 1 分钟

设计模式专题系列: 设计模式

装饰者模式

装饰者模式：

动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

装饰者模式可以给类 动态地添加功能，而不需要修改已经存在的类，类似一个Wrapper。

装饰者有弹性，非常符合 开闭原则

阅读全文 »

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 124 | 阅读时长 ≈ 1 分钟

设计模式专题系列: 设计模式

复合模式

复合模式结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。

复合模式在一个解决方案中结合两个或多个模式，已解决一般或重复发生的问题。

MVC就是一个复合模式。（书中把MVC夸得不行不行的-0-~，称它为 复合模式之王！）

多的不说，截一张示意图：

MVC

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 621 | 阅读时长 ≈ 2 分钟

设计模式专题系列: 设计模式

组合模式

组合(Composite)模式：允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

组合模式比较复杂一些，跟迭代器模式配合威力强大。

类图

阅读全文 »

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 609 | 阅读时长 ≈ 2 分钟

设计模式专题系列: 设计模式

适配器模式(Adapter)

适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

适配器非常形象的图：

形象图

非常形象的模式，就像生活中的手机充电器，电脑的电源适配器一样。

阅读全文 »

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 707 | 阅读时长 ≈ 3 分钟

设计模式专题系列: 设计模式

命令模式

命令模式: 将请求封装成对象，这可以让你使用不同的请求、队列，或者日志请求来参数化其他对象。命令模式也可以支持撤销操作。

  1. 将请求封装成对象，比如 Runnable
  2. 将 发出请求的对象 和 接受与执行这些请求的对象 分隔开来。

类图

一些应用：日程安排、线程池、工作队列等。

阅读全文 »

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 1.4k | 阅读时长 ≈ 4 分钟

设计模式专题系列: 设计模式

持续更新中

设计原则

设计模式中的设计原则

封装变化

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

或者说是：把变化的部分取出来并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分。

优势：

代码变化引起的不经意后果变少，系统变得更有弹性

阅读全文 »

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 151 | 阅读时长 ≈ 1 分钟

设计模式专题系列: 设计模式

策略模式

定义了算法族，分别封装起来，让它们之间可以相互转换，此模式让算法的变化独立于使用算法的客户。

其实就是利用多态的特性，使用面向接口的编程方式来做。

阅读全文 »

发表于 | 更新于: | 分类于 | 阅读次数:
字数统计: 641 | 阅读时长 ≈ 2 分钟

前言

于 2016.8.3 更新

今年的目标里有整理设计模式知识点,一直没有整理,最近效率还可以,希望能整理完.

有部分内容(面向对象基础,设计原则)是一年多以前写的,那时候还非常稚嫩,还需慢慢加深理解。

NOTE:主要目的是给自己看,如果你想学设计模式,推荐看书,后面资料有给出.

笔记目录:

需要注意的是，从桥接模式开始,<<深入浅出设计模式>>一书对它们的讲解就非常少了（大概每个设计模式就只有两页的篇幅）,需要自己再买其他书看,学习.

另外这些读书笔记我在Github放了一份,跟其他书籍的读书笔记一起做成了一份Gitbook,阅读体验更好一些!—>ReadingNotes

设计模式整理

感悟

  1. 不需要严格遵照设计模式，可以适当调整以符合需求(模式是死的，人是活的)
  2. 保持简单（KISS原则）
  3. 设计、重构的时候考虑设计模式
  4. 现在不需要，就别做
  5. 可能一直都不需要设计模式（helloworld就不要扯什么设计模式了）
  6. 过度使用设计模式可能导致代码被过度工程化。应该总是用最简单的解决方案完成工作，并在真正需要模式的地方才使用它。

实际上在开发过程中，自己已经不知不觉使用了不少设计模式，设计模式从实践中来，也特别需要在实践中去体会，不遇到困难，就不能真切深入的理解它。

有句话说的好，『没写过一万行代码，就别提什么设计模式』

设计模式只停止于阅读是远远不够的，还需努力！

设计模式推荐资料

HeadFirst设计模式
设计模式：可复用面向对象软件的基础
wiki:Design Patterns
Android源码设计模式解析与实战
EffectiveJava

发表于 | 更新于: | 分类于 ， | 阅读次数:
字数统计: 711 | 阅读时长 ≈ 2 分钟

UML类图

UML，进阶必备专业技能，看不懂UML就会看不懂那些优秀的资料。

这里简单整理

类之间的关系

泛化关系(generalization)

  1. 泛化（generalize）: 一条带空心箭头的线表示
  2. 实现（realize） : 一条带空心箭头的虚线表示
阅读全文 »