| |
真爱的事业和真正的爱情一生只有一次，都值得我们温柔地相待，因为那种感觉是永远都无法复制的， 这世界真正属于你的东西其实并不多，你不好好珍惜，它便会离你而去，包括机遇，包括爱情，包括生命。
不要找任何理由， 当幸福在你身边的时候就抓住它，你就一定会很幸福！
|
| 时 间 记 忆 |
| « | October 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | 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 | | |
|
blog名称:玻璃杯中的花生壳
日志总数:162
评论数量:249
留言数量:1
访问次数:829461
建立时间:2004年11月4日 |
 | | |
|
| |
|
使用设计模式改善程序结构（2）
3、问题分析
熟悉面向对象的读者很快就会发现上面的代码是典型的结构化的方法，结构化的方法是以具体的功能为核心来组织程序的结构，它的封装度仅为1级，即仅有对于特定的功能的封装（函数）。这使得结构化的方法很难适应需求的变化，面向对象的方法正是在这一点上优于结构化的方法。在面向对象领域，是以对象来组成程序结构的，一个对象有自己的职责，通过对象间的交互来完成系统的功能，这使得它的封装度至少为2级，即封装了为完成自己职责的方法和数据。另外面向对象的方法还支持更高层次的封装，比如：通过对于不同的具体对象的共同的概念行为进行描述，我们可以达到3级的封装度－ 抽象的类（在Java中就是接口）。封装的层次越高，抽象的层次就越高，使得设计、代码有越高的弹性，越容易适应变化。
考虑对上一节中的代码，如果在系统的开发过程中发现需要对一种新的错误进行处理，比如：用户认证错误，我们该如何做使得我们的系统能够增加对于此项功能的需求呢？一种比较简单、直接的做法就是在增加一条用来处理此项错误的case语句。是的，这种方法的确能够工作，但是这样做是要付出代价的。
首先，随着系统的进一步开发，可能会出现更多的错误类型，那么就会导致对于错误的处理部分代码冗长，不利于维护。其次，也是最根本的一点，修改已经能够工作的代码，很容易引入错误，并且在很多的情况下，错误都是在不经意下引入的，对于这种类型的错误很难定位。有调查表明，我们在开发过程中，用于修正错误的时间并不多，大部分的时间是在调试、发现错误。在面向对象领域，有一个很著名的原则：OCP（Open-Closed Principle），它的核心含意是：一个好的设计应该能够容纳新的功能需求的增加，但是增加的方式不是通过修改又有的模块（类），而是通过增加新的模块（类）来完成的。如果一个设计能够遵循OCP，那么就能够有效的避免上述的问题。
要是一个设计能够符合OCP原则，就要求我们在进行设计时不能简单的以功能为核心。要实现OCP的关键是抽象，抽象表征了一个固定的行为，但是对于这个行为可以有很多个不同的具体实现方法。通过抽象，我们就可以用一个固定的抽象的概念来代替哪些容易变化的数量众多的具体的概念，并且使得原来依赖于哪些容易变化的概念的模块，依赖于这个固定的抽象的概念，这样的结果就是：系统新的需求的增加，仅仅会引起具体的概念的增加，而不会影响依赖于具体概念的抽象体的其他模块。在实现的层面上，抽象体是通过抽象类来描述的，在Java中是接口（interface）。关于OCP的更详细描述，请参见参考文献[2]。
既然知道了问题的本质以及相应的解决方法，下面就来改善我们的代码结构。
4、初步方案
让我们重新审视代码，看看该如何进行抽象。在错误处理中，需要处理不同类型的错误，每个具体的错误具有特定于自己本身的一些信息，但是它们在概念层面上又是一致的，比如：都可以通过特定的方法接口获取自已内部的错误信息，每一个错误都有自己的处理方法。由此可以得到一个初步的方案：可以定义一个抽象的错误基类，在这个基类里面定义一些在概念上适用于所有不同的具体错误的方法，每个具体的错误可以有自己的不同的对于这些方法的实现。代码示例如下：
interface ErrorBase
{
public void handle()；
public String getInfo();
}
class DBAccessError implements ErrorBase
{
public void handle() {
/* 进行关于数据库访问错误的处理 */
}
public String getInfo() {
/* 构造返回关于数据库访问错误的信息 */
}
}
class CommunicationError implements ErrorBase
{
public void handle() {
/* 进行关于通信错误的处理 */
}
public String getInfo() {
/* 构造返回关于通信错误的信息 */
}
}
这样，我们就可以在错误发生处，构造一个实际的错误对象，并以ErrorBase引用它。然后，交给给错误处理模块，此时错误处理模块就仅仅知道一个类型ErrorBase，而无需知道每一个具体的错误类型，这样就可以使用统一的方式来处理错误了。代码示例如下：
class GUISys
{
public void announceError(ErrorBase error) {
/* 使用一致的方式处理错误 */
error.handle();
}
}
可以看出，对于新的错误类型的增加，仅仅需要增加一个具体的错误类，对于错误处理部分没有任何影响。看上去很完美，也符合OCP原则，但是进一步分析就会发现，这个方案一样存在着问题，我们将在下一个小节进行详细的说明。
5、进一步分析
上一个小节给出了一个方案，对于只有GUISys这一个错误处理者是很完美的，但是情况往往不是这样的。前面也曾经提到过，对于发生的错误，除了要通知系统的使用者外，还要进行其他的处理，比如：试图恢复，记如日志等。可以看出，这些处理方法和把错误通告给使用者是非常不同的，完全没有办法仅仅用一个handle方法来统一所有的不同的处理。但是，如果我们在ErrorBase中增加不同的处理方法声明，在具体的错误类中，根据自身的需要来相应的实现这些方法，好像也是一个不错的方案。代码示例如下：
interface ErrorBase
{
public void guiHandle();
public void logHandle();
}
class DBAccessError implements ErrorBase
{
public void guiHandle() {
/* 通知用户界面的数据库访问错误处理 */
}
public void logHandle() {
/* 通知日志系统的数据库访问错误处理 */
}
}
class CommunicationError implements ErrorBase
{
public void guiHandle() {
/* 通知用户界面的通信错误处理 */
}
public void logHandle() {
/* 通知日志系统的通信错误处理 */
}
}
class GUISys
{
public void announceError(ErrorBase error) {
error.guiHandle();
}
}
class LogSys
{
public void announceError(ErrorBase error) {
error.logHandle();
}
}
读者可能已经注意到，这种做法其实也不是十分符合OCP，虽然它把变化局限在ErrorBase这个类层次架构中，但是增加新的处理方法，还是更改了已经存在的ErrorBase类。其实，这种设计方法，还违反了另外一个著名的面向对象的设计原则：SRP（Single Responsibility Principle）。这个原则的核心含意是：一个类应该有且仅有一个职责。关于职责的含意，面向对象大师Robert.C Martin有一个著名的定义：所谓一个类的职责是指引起该类变化的原因，如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，其实就是耦合了多个互不相关的职责，就会降低这个类的内聚性。错误类的职责就是，保存和自己相关的错误状态，并且提供方法用于获取这些状态。上面的设计中把不同的处理方法也放到错误类中，从而增加了错误类的职责，这样即使和错误类本身没有关系的对于错误处理方式的变化，增加、修改都会导致错误类的修改。这种设计方法一样会在需求变化时，带来没有预料到的问题。那么能否将对错误的处理方法从中剥离出来呢？如果读者比较熟悉设计模式（这里的熟悉是指，设计模式的意图、动机，而不是指怎样去实现一个具体的设计模式），应该会隐隐约约感觉到一个更好的设计方案即将出现。
6、设计模式浮出水面
让我们对问题重新描述一下：我们已经有了一个关于错误的类层次结构，现在我们需要在不改变这个类层次结构的前提下允许我们增加对于这个类层次的新的处理方法。听起来很耳熟吧，不错，这正是过于visitor设计模式的意图的描述。通过对于该模式动机的分析，我们很容易知道，要想使用visitor模式，需要定义两个类层次：一个对应于接收操作的元素的类层次（就是我们的错误类），另一个对应于定义对元素的操作的访问者（就是我们的对于错误的不同处理方法）。这样，我们就转换了问题视角，即把需要不同的错误处理方法的问题转变为需要不同的错误处理类，这样的结果就是我们可以通过增加新的模块（类）来增加新的错误处理方法，而不是通过增加新的错误处理方法（这样做，就势必要修改已经存在的类）。
一旦到了这一部，下面的工作就比较简单了，因为visitor模式已经为我们搭建了一个设计的上下文，此时我们就可以关注visitor模式的实现部分来指导我们下面的具体实现了。下面仅仅给出最终的程序结构的UML图以及代码示例，其中忽略了错误类中的属于错误本身的方法，各个具体的错误处理方法通过这些方法和具体的错误类对象交互，来完成各自的处理功能。
最终的设计的程序结构图
最终的代码示例
interface ErrorBase
{
public void handle(ErrorHandler handler);
}
class DBError implements ErrorBase
{
public void handle(ErrorHandler handler) {
handler.handle(this);
}
}
class CommError implements ErrorBase
{
public void handle(ErrorHandler handler) {
handler.handle(this);
}
}
interface ErrorHandler
{
public void handle(DBrror dbError);
public void handle(CommError commError);
}
class GUISys implements ErrorHandler
{
public void announceError(ErrorBase error) {
error.handle(this);
}
public void handle(DBError dbError) {
/* 通知用户界面进行有关数据库错误的处理 */
}
public void handle(CommError commError) {
/* 通知用户界面进行有关通信错误的处理 */
}
}
class LogSys implements ErrorHandler
{
public void announceError(ErrorBase error) {
error.handle(this);
}
public void handle(DBError dbError) {
/* 通知日志系统进行有关数据库错误的处理 */
}
public void handle(CommError commError) {
/* 通知日志系统进行有关通信错误的处理 */
}
}
7、结论
设计模式并不仅仅是一个有关特定问题的解决方案这个结果，它的意图以及它的动机往往更重要，因为一旦我们理解了一个设计模式的意图、动机，那么在设计过程中，就很容易的发现适用于我们自己的设计模式，从而大大简化设计工作，并且可以得到一个比较理想的设计方案。
另外，在学习设计模式的过程中，应该更加注意设计模式背后的东西，即具体设计模式所共有的的一些优秀的指导原则，这些原则在参考文献[1]的第一章中有详细的论述，基本上有两点：
发现变化，封装变化
优先使用组合（Composition），而不是继承
如果注意从这些方面来学习、理解设计模式，就会得到一些比单个具体设计模式本身更有用的知识，并且即使在没有现成模式可用的情况下，我们也一样可以设计出一个好的系统来。 （全文完） |
|
| | |
|
