[从设计到架构]第三回：设计的分寸
1 引言
话书两回[第一回：设计，应该多一点]和[第二回：对象的旅行---对象和人，两个世界，一样情怀]，作者欲言又止，吊起胃口又玩起了捉迷藏。挑起设计与架构之话题，谁料半道杀出程咬金[《你必须知道的.NET》]，招致[从设计到架构系列] 的中道搁浅。不过，搁浅不代表停止，中道不意味绊倒，而是期待更多。以设计为话题来把玩，对任何人来说都有点沉甸甸的分量，所以限于作者的一点点花拳绣 腿，只能说点到一切玄机的皮毛。而更多的期待，则是抛出问题和一点浅见，迎来无数的砖头，由更多的大牛敲打、点缀、重构，形成一个真正称得上设计的架构。
 Zhuangbility |
| 对设计来说，或许永远没有唯一的答案，你只能无限的接近最好。 |
2 回顾
时隔已久，有必要将本系列前面的内容做个简单的回顾。在[第一回：设计，应该多一点]里首次提出了对于设计的理解，提倡更多的人来了解技术世界中最具吸引力和持久力的元素，高举设计与架构的大旗来充当门面，小试牛刀；而在[第二回：对象的旅行---对象和人，两个世界，一样情怀]中，通过一个有趣的对比，将对象的体验和人生的品味凑到一起进行“非议”，可以说来了一次非正常的对象旅行。
小试之后，希望能够专注更多的专题，一切就从本文开始啦:-)，那么首先应该关注的是：设计，究竟从何而来？
3 设计从由何而来？
设计，从何而来？是需求。是重构。
设计原则是系统设计的灵魂，而设计模式是系统开发的模板，灵活自如的应用才是设计以不变应万变的准则。例如，假如实现一个用户注册的方法，你首先想到的可能是：
public void RegistryUser(string name, Int32 age)
{
}
在一定的需求条件下，这个方法已经能够经受系统的考验，安全而平稳的向数据库中不断插入新的用户信息。然而，当需求发生变化时，你可能不得不对此做 出调整，而我们就将调整称为重构。但是重构远不是扩充，而是设计。例如，现在的注册项发生了变化，还需要同时注册性别、电话，没有设计的调整，就被实现 为：
public void RegistryUser(string name, Int32 age, bool sex, Int32 phone)
{
}
通过重载方式，一定程度上解决了这一问题，然而这种不能称为重构的调整，至少存在以下的弊端：
- 有新增的注册信息时，还要通过不断的重载RegistryUser方法来实现更多信息的扩展。
- 方法RegistryUser的参数列表实在太长了，这不是优雅的代码实现。
- 需要修改系统中相关的方法调用来适应新的重载方法。
僵化的调整失去了设计灵魂的灵活性，没有思考的程序只能使程序的扩展和维护变得不可收拾，其实对于上述问题，只需要进行简单的重构，就可轻松避免上述3个弊端，实现更加柔性的系统。例如，我们的重构如下：
{
public string Name { get; set; }
public Int32 Age { get; set; }
public bool Sex { get; set; }
}
通过将用户信息封装为一个类，实现了更加简单的参数列表，同时其带来的好处还远不止避免了3个缺陷，而且能带来对用户信息的封装，实现更可靠的信息隐藏和暴露：
- 可以通过字段和属性封装，实现对于成员的只读、可读可写权限的控制。.NET 3.0的自动属性为属性封装实现了更为优雅的语法游戏，这些特性让C#成为更具有吸引力的高级语言：
public string Mobile { get; set; }
//定义只读属性
public string Password { get; private set; }
- 实现一定的逻辑封装，例如对于电子邮件，可以检查其合法性：
public string Email
{
get { return email; }
set
{
//string emailReg = @"\w+([-+.']\w+)*@(?!163\.)((\w+([-.]\w+)*))\.\w+([-.]\w+)*";
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("No legal Email Address.");
}
}
}
那么，设计是如何实现和建立的，答案就是面向对象。正如上述演化过程一样，我们应用了面向对象中的封装要素，完成了更加柔性的设计。在《你必须知道的.NET》的第1.3节“封装的秘密”中，就对封装展开了详细的探讨，基于实例的应用和对.NET实现本质的分析，能够更加开阔我们对于面向对象基本要素的理解。这些面向对象的思想和应用，来自于实践，来自于重构。
4 从此，重构
设计是如此重要，那么我们的基本设计能力与素质又从何下手来培养呢？
最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。在我认为，设计能力的提升绝非一朝一夕之功，这个行业中的设计大师，往往必须具备多年的修行方可称之为“架构师”。作为涉世未深的我们，该从何下手，下面仅仅是一点浅见之论：
- 面向对象（Object-Oriented），关于面向对象没有必要重复嚼舌了，《你必须知道的.NET》一书的第一章“OO大智慧”中对.NET的面向对象进行了有别于其他专著的介绍方式，除了以实例突出面向对象之思想大成，还以浓墨铺陈了.NET是如何在底层技术上来实现继承、多态和接口映射等机制，从而可以更加有效和深刻的把握面向对象的精髓。
- 面向服务（Service Oriented），SO至少是个时髦的话题，WCF伴着.NET 3.5的发布，一个一统江湖的面向服务的基础架构横空出世。可以想象的是，未来的分布式系统架构将变得更加柔性和统一，简单而有效，我们也期望在本系列的随后部分进行探讨。
- 架 构（Architecture），我理解的架构就是应用系统构建所需的基础设施。应用程序是变化万千的，而基础架构是相对稳定。这正如我们基于.NET Framework来实现数以万计的.NET应用：Windows Form Application、Web Form Application、XML Web Service等等，都体现了架构和应用的关系。.NET Framework本身就是一个基础性架构，而经典的MFC也是一个基础性架构。对于架构的探索和实践，应该是每个意图提高设计能力的人的必经之路。选择 一个或几个典型的架构进行梳理与实践，才能有效的了解软件世界的庞大体系是如何和谐统一的运作。从经典框架设计中，寻找灵感，锻炼体验，而本系列的未来章 节将为大家带来基于Petshop三层架构的实践体验，通过真正的需求、设计、开发和测试，完成一次有意义的项目实践旅程，而在这个旅程中，作者和读者共 同收获对于设计与架构，从概念到实践，从表面到思想的体验。
- 设计原则（Design Principles），是面向对象设计程序开发的思想大成，了解面向对象，深入设计模式，则有必要深入设计原则之精髓。可以不了解全部的设计模式，但必须深入每一个设计原则。一个是内功，一个是招式，设计的第一项修炼就从内功开始。《你必须知道的.NET》第二章“OO大原则”对5大设计原则进行了一些以例说理式的实际探讨和分析，几个看似简单的设计原则：单一职责原则、开放封闭原则、依赖倒置原则、接口隔离原则、Liskov替换原则等，5个原则贯彻了一个简单的思想“面向抽象，松散耦合”。
- 设 计模式（Design Pattern），23个设计模式，23个经典智慧，了解和掌握几个重要的设计模式，是修炼面向对象招式的必经之路。无论如何，做为设计者你应该在自己心 中知道什么是Abstract Factory、Iterator、Singleton、Adapter、Decorator、Observer、Façade、Template、 Command，早在一篇以推荐为性质的[必须知道的设计模式]中有过自己借鉴的历史记录。在博客园中，有着以设计模式为话题的光荣传统，作为学习者我强烈的推荐TerryLee的Design Pattern系列和吕震宇的设计模式系列。
在《你必须知道的.NET》的第一部分，以“OO大智慧”和“OO大原则”两章的篇幅，来分别讲述关于面向对象的实现本质和思想理念，以面向对象技术在.NET中的应用为起点，熟悉和领略面向对象的智慧与原则，修炼深入.NET技术的基本功，为深入理解.NET的程序设计打好必备的基础。
从某种意义上来说，本系列正是通过一个典型简单项目的实践来梳理这些基本架构设计的基本概念，以例说理。在一个项目的实现过程中，逐渐的了解什么是 对象、什么是对抽象编程、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个项目，对于更多人来说是认识一种软件开发 的科学流程。这种体验，才是难能可贵的经验。一个在简历中轻描淡写的“10年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意 可言。
所以，从本文开始，从架构到设计系列将开始一段闯荡江湖的旅程，借助博客园的翅膀飞向天空，重要的是希望更多的朋友能在这里进行探讨和交流，以一个项目的运作为基础来探讨一个个设计与架构中的问题，以期收获更多的共识与争论。
5 结论：其实每个人都是食神
我很喜欢看周星驰的电影，[食神]中的周星驰在大彻大悟之后说了句：其实每个人都是食神，引来他人不屑。不过，现实的情况却真是如此，每个人都是食神，或者说每个人都可以是食神。软件设计与架构，同样如此，不经一番寒彻骨，哪得梅花扑鼻香。
| Zhuangbility |
| 其实每个人都是食神，其实每个人都是设计师。关键在于掌勺的你，是否能让做饭的家伙油光锃亮。 |
 系列预告 |
| 在
2008，我将集中全力对[从架构到设计]系列进行完善，从下一篇开始，我们将以实际的项目开发流程为主线，从需求开始介绍，到设计分析，再到实践操作，
完成一次设计开发的全程之旅，其中重点的应用Petshop框架给我们的分层架构概念为核心，通过不断的设计和重构来完成一个系统的体验。 而在这个过程中，我们会逐一分享关于设计、面向对象、设计原则、设计模式等基本概念的探讨，从而能够有效的进行循序渐进的认识旅程。 限于作者能力有限，诸多不足之处还望朋友们尽情指正，对我来说伴着从设计到架构系列，我将继续分享自己在技术之路上的体验和快乐。 |
© 2008 Anytao.com 原创作品，转贴请注明作者和出处，留此信息。
本文以“现状”提供且没有任何担保，同时也没有授予任何权利。
This posting is provided "AS IS" with no warranties, and confers no rights.
