OO 之美：设计的分寸

本节将介绍以下内容：

• 设计的由来
• 浅谈重构

设计的分寸

引言

有了前面两章“OO 大智慧”和“OO 大原则”的铺垫，相信读者已经有了对面向对象的基本认知。而本章将继续深入关于面向对象和设计问题的讨论，挑起设计与架构的话题。在高级语言横行的今天，对于静态语言的设计都源于面向对象思想，重构与设计都基于这些简单的标准。

然而，对于设计，还有很多看似“惯常”的法则与经验广泛存在于软件系统中，例如除了经典的 23 种设计模式，还有很多模式之外的模式，按照粒度的大小、系统的特点、规模的大小，而形成的架构规则。

对设计来说，或许永远没有唯一的答案，你只能无限地接近最好。

设计，没有唯一的答案，但是把握分寸，却是软件设计中需要“用心良苦”的部分。

设计由何而来

设计，从何而来？是需求。是重构。

设计原则是系统设计的灵魂，而设计模式是系统开发的模板，灵活自如的应用才是设计以不变应万变的准则。例如，实现一个用户注册的方法，首先会想到：

// 初次设计
public void Register(string name, Int32 age)
{
}

在一定的需求条件下，这个方法已经能够经受系统的考验，安全而平稳地向数据库中不断插入新的用户信息。然而，当需求发生变化时，你可能不得不对此做出调整，而我们就将这种调整称为重构。但是重构远不是扩充，而是设计。例如，现在的注册项发生了变化，还需要同时注册性别、电话，没有设计的调整，就被实现为：

// 需求变更
 public void Register(string name, Int32 age, bool isMale, Int32 phone)
 {
 }

通过重载方式，一定程度上解决了这一问题，然而这种不能称为重构的调整，至少存在以下的弊端：

• 有新增的注册信息时，还要通过不断地重载 Register 方法来实现更多信息的扩展。
• 方法 Register 的参数列表实在太长了，这不是优雅的代码实现。
• 需要修改系统中相关的方法调用来适应新的重载方法。

僵化的调整失去了设计的灵活性，没有思考的程序只能使程序的扩展和维护变得不可收拾，其实对于上述问题，只需要进行简单的重构，就可轻松避免上述3个弊端，实现更加柔性的系统。例如，简单重构如下：

public class UserInfo
{
    public string Name { get; set; }
    public Int32 Age { get; set; }
    public bool Gender { get; set; } 
}

通过将用户信息封装为一个类，实现更加简单的参数列表，同时其带来的好处还远不止避免了上述3个缺陷，而且能带来对用户信息的封装，实现更可靠的信息隐藏和暴露：可以通过字段和属性封装，实现对于成员的只读、可读可写权限的控制。.NET 3.0 的自动属性为属性封装实现了更为优雅的语法游戏，这些特性让 C# 成为更具有吸引力的高级语言（详见13.2节“赏析C# 3.0”）：

// 定义可读可写属性
public string Mobile { get; set; }

// 定义只读属性
public string Password { get; private set; }

实现一定的逻辑封装，例如对于电子邮件，可以检查其合法性：

private string email;

public string Email
{
    get { return email; }

    set
    {
        string strReg = @"^([\w-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([\w-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";
        
        if (Regex.IsMatch(value, strReg))
            email = value;
         else 
            throw new InvalidCastException("Invalid Email Address.");
    }
}

那么，设计是如何实现和建立的呢？答案就是面向对象。正如上述演化过程一样，其中应用了面向对象中的封装要素，完成了更加柔性的设计。在1.3节“封装的秘密”中，我们就对封装展开了详细的探讨，基于实例的应用和对 .NET 实现本质的分析，能够更加强化对于面向对象基本要素的理解。这些面向对象的思想和应用，来自于实践，完善于重构。

从此重构

设计是如此重要，那么开发者的基本设计能力与素质又从何下手来培养呢？最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。然而，设计能力的提升绝非一朝一夕之功，软件开发中的设计大师，往往必须具备多年的修行方可称之为“架构师”。

一个在简历中轻描淡写的“10年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意可言。在一个项目的实现过程中，逐渐了解什么是对象、什么是对抽象编程、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个软件项目，对于更多人来说是认识一种软件开发的科学流程。这种体验，才是难能可贵的经验。在设计的广义概念里，几个必需的概念是应该首先被了解和认知的，以排名不分先后的原则罗列，它们大概包括：

• 面向对象（Object-Oriented）
  关于面向对象没有必要重复嚼舌了，本书的第1章“OO 大智慧”中对 .NET 的面向对象进行了有别于其他专著的介绍，除了以实例突出面向对象之思想大成，还以浓墨铺陈了 .NET 是如何在底层技术上来实现继承、多态和接口映射等机制，从而使读者可以更加有效和深刻地把握面向对象之精髓。
• 面向服务（Service Oriented）
  SO至少是个时髦的话题，WCF 伴着.NET 3.5 的发布，一个一统江湖的面向服务的基础架构横空出世。可以想象的是，未来的分布式系统架构将变得更加柔性和统一，简单而有效。
• 框架（Framework），所谓框架就是应用系统构建所需的基础设施。
  应用程序是变化万千的，而基础架构则是相对稳定的。这正如我们基于 .NET Framework 来实现数以万计的 .NET 应用：Windows Form Application、Web Form Application、XML Web Service 等，都体现了框架和应用的关系。.NET Framework 本身就是一个基础性架构，正如经典的MFC一样，提供了.NET应用赖以生存的基础性支持。对于框架的探索和实践，应该是每个有意提高设计能力的开发者的必经之路。选择一个或几个典型的框架进行梳理与实践，才能有效地了解软件世界的庞大体系是如何和谐统一地运作。从经典框架设计中，寻找灵感，锻炼体验，例如分享经典案例 Petshop 三层架构的实践体验，通过真正的需求、设计、开发和测试，而在这个旅程中我们就能完成从概念到实践、从表面到思想的体验。
• 设计原则（Design Principles），是面向对象设计程序开发的思想大成，了解面向对象，深入设计模式，则有必要深入设计原则之精髓。可以不了解全部的设计模式，但必须深入每一个设计原则。一个是内功，一个是招式，设计的第一项修炼就从内功开始。本书第2章“OO大原则”对5大设计原则进行了一些以例说理式的实际探讨和分析，几个看似简单的设计原则：单一职责原则、开放封闭原则、依赖倒置原则、接口隔离原则、Liskov 替换原则，这 5 个原则贯彻了一个简单的思想——“面向抽象，松散耦合”。
• 设计模式（Design Pattern）
  23个设计模式，23个经典智慧，了解和掌握几个重要的设计模式，是修炼面向对象招式的必经之路。无论如何，作为设计者你应该在自己心中知道什么是 Abstract Factory、Iterator、Singleton、Adapter、Decorator、Observer、Façade、Template、Command。
• 模式之外，除了23个经典的设计模式，其实还存在很多模式之外的模式，按照粒度的不同而广泛应用在实际的项目系统中。
  例如，在 SOA 系统中的 Event driven Architecture、Message Bus 以及分布式 Broker 模式；数据持久层的 Repository、Active Record 还有 Identity Map模式；可伸缩系统下的 Map/Reduce、Load Balancer 以及 Result Cache 模式；更高架构层面的MVC、MVP 以及 Pipeline/Filter 模式。在某种意义上而言，模式是一种经验的积累和总结，对于系统设计与架构考量，架构师要完成的不仅仅是对功能性需求的把握，还包括非功能性需求、平台与框架的平衡、性能与安全的考量。

在本书第1部分，以“OO大智慧”和“OO大原则”两章的篇幅，分别讲述了关于面向对象的实现本质和思想理念，以面向对象技术在 .NET 中的应用为起点，熟悉和领略面向对象的智慧与原则，修炼深入 .NET 技术的基本功，为深入理解 .NET 的程序设计打好必备的基础。而本章将对以上设计问题继续探讨，从点点滴滴入手来关注设计环节的下一个据点。

所以，下面我们将对软件开发中的设计与架构进行更多的探讨，以期收获更多的共识与争论。

结论

周星驰在《食神》中历经磨难之后参加食神大赛，做了一顿令人抓狂的黯然销魂饭，并对对手说了句：其实每个人都是食神，引来对手不屑。同样，现实世界的历练也渗透着同样的感悟，每个人都是食神，或者说每个人都可以是食神。软件设计与架构同样如此，不经一番寒彻骨，哪得梅花扑鼻香。

其实每个人都是食神，其实开发者都是设计师。关键在于掌勺的你，是否能让做饭的家伙油光锃亮。

其实，在设计的领域，你大可不必为看似高深的框架吓倒，也不必为没有经验而怯场。在每个人的代码生涯中，你随时可以是食神，就像上例中通过简单 Extract Class 重构方法，你就可以体验一次化腐朽为神奇的力量。所以，设计无处不在，架构如影随形。而如何将三层架构、Abstract Factory、Extract Method、MVC、OCP 这一竿子打不着的概念有机地、科学地、合理地体现在活生生的软件系统中，是一种功力和经验的体现。

作为学习者，如果还不具备在宏观上把握如何将上述模糊的概念进行统筹和消化，那么作为预备设计师，首先要做好的工作就是先逐个认识 SOA、Mapper、Pipeline、DTO、Message Bus 这些概念，有了基本功之后再看着唱本骑驴走远。