专题课程
有没有想过设计模式到底是什么？通过本文可以看到设计模式为什么这么重要，通过几个Python的示例展示为什么需要设计模式，以及如何使用。
设计模式是经过总结、优化的，对我们经常会碰到的一些编程问题的可重用解决方案。一个设计模式并不像一个类或一个库那样能够直接作用于我们的代码。反之，设计模式更为高级，它是一种必须在特定情形下实现的一种方法模板。设计模式不会绑定具体的编程语言。一个好的设计模式应该能够用大部分编程语言实现(如果做不到全部的话，具体取决于语言特性)。最为重要的是，设计模式也是一把双刃剑，如果设计模式被用在不恰当的情形下将会造成灾难，进而带来无穷的麻烦。然而如果设计模式在正确的时间被用在正确地地方，它将是你的救星。
起初，你会认为“模式”就是为了解决一类特定问题而特别想出来的明智之举。说的没错，看起来的确是通过很多人一起工作，从不同的角度看待问题进而形成的一个最通用、最灵活的解决方案。也许这些问题你曾经见过或是曾经解决过，但是你的解决方案很可能没有模式这么完备。
虽然被称为“设计模式”，但是它们同“设计“领域并非紧密联系。设计模式同传统意义上的分析、设计与实现不同，事实上设计模式将一个完整的理念根植于程序中，所以它可能出现在分析阶段或是更高层的设计阶段。很有趣的是因为设计模式的具体体现是程序代码，因此可能会让你认为它不会在具体实现阶段之前出现(事实上在进入具体实现阶段之前你都没有意识到正在使用具体的设计模式)。
可以通过程序设计的基本概念来理解模式：增加一个抽象层。抽象一个事物就是隔离任何具体细节，这么做的目的是为了将那些不变的核心部分从其他细节中分离出来。当你发现你程序中的某些部分经常因为某些原因改动，而你不想让这些改动的部分引发其他部分的改动，这时候你就需要思考那些不会变动的设计方法了。这么做不仅会使代码可维护性更高，而且会让代码更易于理解，从而降低开发成本。
设计出一个优雅的、易于维护的程序难点在于发现我所说的“变化的向量”(在这里，“向量”指的是最大的梯度变化方向(maximum gradient)，而并非指一个容器类)。意思是找出系统中变化的最重要的部分，或者换句话说，发现影响系统最大的花销在哪里。一旦你发现了变化的向量，你就可以围绕这个重点设计你的程序。
所以设计模式的目的就是分离代码中的可变部分。如果你这么去审视这个问题，你会立刻看到多个设计模式。举个例子，面向对象的继承(inheritance)可以看做一种设计模式(虽然是由编译器实现的)。它允许通过同样的接口(不变的部分)来表现不同的行为(变化的部分)。组合也可以被认为是一种设计模式，因为它允许通过动态或静态的方式改变实现类的对象以及他们的行为。
另一个常见的设计模式例子是迭代器。迭代器自Python出现伊始就已经随for循环的使用而存在了，并且在Python2.2版本的时候被明确成为其一个特性。一个迭代器隐藏了容器内部的具体实现，提供一个依次访问容器对象内每个元素的方式。所以，你能够使用通用的代码对一个序列的每个元素做对应操作而不用去理会此序列是怎么建立的。所以你的代码能够对任何能够产生迭代器的对象有效。
这里列举了三种最基本的设计模式：
结构化模式，通常用来处理实体之间的关系，使得这些实体能够更好地协同工作。
创建模式，提供实例化的方法，为适合的状况提供相应的对象创建方法。
行为模式，用于在不同的实体建进行通信，为实体之间的通信提供更容易，更灵活的通信方法。
从理论上来说，设计模式是对程序问题比较好的解决方案。无数的程序员都曾经遇到过这些问题，并且他们使用这些解决方案去处理这些问题。所以当你遇到同样的问题，为什么要去想着创建一个解决方案而不是用现成的并且被证明是有效的呢？
假定现在有一个任务，需要你找到一个有效的方法合并两个做不同事情的类，在已有系统中这两个类在许多不同的地方被大量使用，所以移除这两个类或是改动已有的代码都是异常困难的。不仅如此，更改已有的代码会导致大量的测试工作，因为在这样一种依赖大量不同组件的系统中，这些修改总是会引入一些新的错误。为了避免这些麻烦，你可以实现一个策略模式(Strategy Pattern)和适配器模式(Adapter Pattern)的变体，这两种模式能够很好的处理这种问题。
很简单是吧？现在让我们来仔细研究一下策略模式。
策略模式是一种与行为相关的设计模式，允许你在运行时根据指定的上下文确定程序的动作。你可以在两个类中封装不同的算法，并且在程序运行时确定到底执行哪种策略。
在上面的例子中，策略是根据实例化时context变量的值来决定的。如果给定context变量的值是“class_one”，将会执行class_one，否则就会执行class_two。
假定你现在正在写一个类能够更新或创建一条新的用户记录，接收同样的输入参数(诸如姓名、地址、手机号等)，但是根据不同的情况会调用对应的更新或是创建方法。当然，你可能会用一个if-else判断处理这个问题，但是如果你需要在不同的地方使用这个类呢？那么你就得不停地重写if-else判断。为什么不简单地通过指定上下文来解决这个问题。
常规的策略模式涉及到将算法封装到另一个类中，但如果这样的话，那个类就太浪费了。切记不要死记模板，把握住核心概念灵活的变通，最重要是解决问题。
适配器模式是一个结构性的设计模式，允许通过不同的接口为一个类赋予新的用途，这使得使用不同调用方式的系统都能够使用这个类。
也可以让你改变通过客户端类接收到的输入参数以适应被适配者的相关函数。
另一个使用适配器类的地方是包装器(wrapper)，允许你将一个动作包装成为一个类，然后可以在合适的情形下复用这个类。一个典型的例子是当你为一个table类簇创建一个domain类时，你能够将所有的对应不同表的相同动作封装成为一个适配器类，而不是一个接一个的单独调用这些不同的动作。这不仅使得你能够重用你想要的所有操作，而且当你在不同的地方使用同样的动作时不用重写代码。
比较一下两种实现：
如果我们需要在不同的地方做同样的事，或是在不同的项目中重用这段代码，那么我们需要重新敲一遍。
看看我们怎么反其道而行：
在这种情况下，我们通过一个包装类来实现账户domain类：
这样的话，你就能够在你需要的时候使用账户domain了，你也可以将其他的类包装到domain类下。
收藏(0)
赞 
粤公网安备44010602001432号