一、设计模式介绍(Introduction of Design Pattern)

introduction

第一章设计模式介绍(Introduction of Design Pattern)

1 概要

设计模式(Design Patterns)是一种通用的、可重复使用的、可用于解决常见问题的软件设计方法。在长年累月的软件开发过程中，开发人员总结了一套软件设计模式，它们能帮助开发人员降低软件的开发难度，提升软件的灵活度(Flexibility)和可扩展性(Extensibility)，使得软件易于阅读(Readability)、易于维护(Maintainability)。

随着设计模式的发展与成熟，设计模式也慢慢的演变成一种开发人员之间交流的语言(Language)。设计模式的名字也越来越多的出现在软件设计文档(Design Documents)、源代码(Source Codes)和演讲(Presentations)中。

2 起源与发展

在《设计模式》这本书面世之后，设计模式一词也随之进入大众视野。这本书由四位作者编写，因此，他们被称为“四人组(Gang of Four)”。在该书中，作者深入讨论了23种设计模式，它们分别属于创建模式(Creational Design Patterns)、结构模式(Structural Design Pattern)和行为模式(Behavior Design Patters)。该书使用C++语言展示各种模式的使用方法。随后，这些模式和示例被其他书籍扩展到Java语言、Python语言和其他面向对象编程语言(Object-Oriented Programming Language)。

Design Patterns: Elements of Reusable Object-Oriented Software, written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, in 1994. ISBN: 978-0201633610

Robert Cecil Martin，常被大家称为Uncle Bob，提出了面向对象程序设计的五大原则SOLID。

Single-responsibility principle(单一功能原则)指出一个类只应具有一种单一的功能，并且该功能应该封装在该类中。Robert Martin称代码的"职责或者功能(Responsibility)"是代码修改的唯一原因。因为，当职责变化时，代码应随着变化。所以，单一功能原则是指一个类只应具有一个可能导致代码修改的原因，即一个类只应具有一个职责或者功能。
Open-closed principle(开闭原则)表示软件应该对于扩展是开放的、对于修改是封闭的。“对于扩展是开放的”是指当需要扩展软件功能时，无需修改已有的代码。已有的代码应支持新功能的扩展。"对于修改是封闭的"是指当有新用户使用已有代码时，已有代码应不需要修改就能支持使用。在理想情况下，代码一旦完成，只有在修改缺陷时才需要修改代码。

开闭原则首先由Bertrand Meyer提出。他认为当需要扩展功能时，可使用继承技术，将新功能实现在子类中。因此，无需修改在基类的已有功能和代码。这种思想被称为梅耶开闭原则(Meyer‘s Open-closed Principle)。随着技术和思想的发展，多态开闭原则(Polymorphic Open-closed Principle)思想逐渐成为较为流行的实践方法。在这种方法中，开发人员首先定义抽象的接口。当需要实现新功能时，开发人员可以将新的功能实现在一个新的实现类中，通过使用面向对象程序设计的多态技术，切换新老功能的实现。
Liskov substitution principle(里氏替换原则)指在程序中，在不改变程序正确性的前提下，对象应该可以被它的子类替换。简单的说，当类型D是类型B的子类时，在程序中，D的对象能够替换任何B类型的对象。里氏替换原则是一种语义层面的替换原则(Semantic Substitution)。在面向对象程序设计过程中，当子类D继承自基类B时，编译器会帮助检查基类B定义的接口是否与子类D实现的接口完全相同。这是一种语法层面上的检查或者替换(Syntactic Substitution)。然而，编译器无法检查D中实现的逻辑和行为。因此，在语义层面上，里氏替换原则指出在不改变程序正确性的前提下，D的实现应能够替换B。
Interface segregation principle(接口隔离原则)指在设计过程中，多个特定接口要好于一个宽泛的接口。接口的功能应该保持功能单一。相互无关联的接口应拆分成多个小接口。因为，这种设计能够帮助更好的管理和维护代码，重构代码。当需求变更时，能够将因需求变更而影响的代码量降到最低。
Dependency inversion principle(依赖反转原则)指对象必须依赖于抽象/接口，而不是依赖于实现。依赖反转原则能够有效的降低代码耦合度(De-coupling)。在设计过程中，当使用某一代码功能时，应使用该功能的接口，而不是使用该功能的实现。因此，在依赖反转原则下，某一功能的实现不会直接依赖于另一个功能的实现，而是依赖于另一个功能的接口，从而分离了两个功能模块之间的实现。

3 质疑的声音

在一片赞美之声下，并不是所有的开发人员都认同和使用设计模式。因为他们发现在刚开始使用设计模式时，的确能为开发人员和产品带来诸多好处。但是，随着开发工作的深入，他们也发现了由使用设计模式而引入的问题，并且这些问题比起其带来的好处要严重的多。其中，主要的问题有：(1) 滥用设计模式，将设计模式应用在错误的场景下；(2) 设计模式令软件设计更为僵化；(3) 经验不足的开发人员不能很好掌握设计模式的使用方法；(4) 设计模式还不够正式，尚未标准化，难以使用。

有意思的是，在此时，有四位作者站了出来，组成了新的四人组(Upstart Gang of Four)，它们于1998年发布了一本书《反模式：在危机中的软件、架构、和项目重构》，并引起了开发人员的反思。

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, written by William J. Brown, Raphael C. Malveau, Hays W. McCormick, and Thomas, J. Mowbray. ISBN: 978-0471197133

4 后续章节安排

为了更好的帮助读者理解和使用设计模式，小水滴再次整理了《设计模式》这本书中讲解的23种设计模式。除此之外，小水滴还收集了目前较为流行的几种设计模式。每个设计模式都配有实例讲解，并展示了在Java标准库中或者其他流行的代码库中使用的设计模式示例。设计模式是一种工具。工具无优劣好坏之分，关键在于开发人员如何使用它们。我们将会在随后的章节依次介绍流行的设计模式，后续章节安排如下。

注册用户登陆后可留言

第一章 设计模式介绍(Introduction of Design Pattern)

1 概要

2 起源与发展

3 质疑的声音

4 后续章节安排

下一章

第一章设计模式介绍(Introduction of Design Pattern)