【IT168 专稿】我想通过本系列文章从头到尾构建一个完整的ASP.NET MVC论坛应用程序，最终的目的是探讨和推动使用ASP.NET MVC框架构建应用程序的非常好的实践。
1、 简介
在本篇中，我想先从全局方面介绍一下论坛应用程序的总体目标。在本篇中，我将讨论一下避免代码坏味道的重要性，还将讨论如何利用软件设计原则和模式来帮助你编写适合未来改变的富有弹性的代码。最后，我还将论证一下为什么我选择使用测试驱动开发方式构建本系列文章中的论坛应用程序。
2、 什么样的软件是好的软件
我不想仅仅为了构建论坛应用程序而任意构建此论坛应用程序。我的目标是尽可能构建最棒的论坛应用程序。
这个目标立即引发这样一个问题：什么样的软件是好的软件？是什么导致一个应用程序比另一个应用程序更好一些或更差一些呢？在事先没有一个关于“好软件”的定义之前，我无法声明我构建了一个完美的论坛应用程序。
因此，下面是我对于“好软件”的定义。
3、 好软件是设计得易于修改的软件
存在多种原因可能需要你改变软件：
1)你可能需要在一个现有软件上添加新的特征
2)你可能需要修改一个现有软件中的错误
3)你可能需要优化现有软件
4)你可能需要改进现有软件的设计
一般说来，设计糟糕的软件是难于改变的。有些软件设计得如此糟糕，以致于每个人都害怕碰一碰它。我们大家应该都使用过设计得糟糕的软件。当软件不好时，你很希望它干脆走开；甚至如果有机会的话，你可能想从头开始重新编写这款软件。
4、 避免代码坏味道
Robert和Micah Martin把糟糕的软件部分描述为代码坏味道。下列代码坏味道意味着此软件的书写是相当糟糕的：
1)僵化性（Rigidity）—僵化的软件是这样的软件，当你在某个位置作一改动时即要求对系统作出相应的一系列的更改。
2)脆弱性（Fragility）—脆弱的软件是这样的软件，你在某个位置作一改动时即打断另外多处的正常运行。
3)不必要的复杂性—不必要的复杂软件是指过度设计的软件，其目的是为了处理任何可能的改变。
4)不必要的重复—不必要的重复软件中包含大量的重复性代码。
5)晦涩性—晦涩的软件是指难于理解的软件。
【注意】上述这些代码味道在Micah和Robert Martin的著名《Agile Principles,Patterns,and Practices in C#》中得到充分的描述。在此，强烈建议读者读一下这本书。
注意，上述这些代码味道都与所有的代码改变相关联。每一个这些代码味道都将妨碍代码的改变。
5、 软件设计原则
遵循良好的软件设计原则，将有助于编写软件易于适应未来更改的软件。软件设计原则有若干，也不尽相同。例如，Cunningham和Cunningham Wiki描述面向对象设计的11个原则：
http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign。
其中提到的面向对象设计的前五个原则与Robert Martin及他的儿子Micah Martin编著的《Agile Principles,Patterns,and Practices in C#》中所主张的软件设计原则是一致的。此外，Robert Martin还在Object Mentor开辟的博客上讨论了这些原则：
http://www.objectmentor.com/resources/publishedArticles.html。
此外，我还发现有另外两本书中也提供了有关软件设计原则的极其有用的信息。第一本是Eric Freeman,Elisabeth Freeman, Kathy Sierra, Bert Bates编著的《Head First Design Patterns》；第二本是Brett McLaughlin,Gary Pollice和David West编著的《Head First Object-Oriented Analysis and Design》。尽管这些书所讨论的原则与Robert Martin的提法并不十分相同，但是它们却十分相近。
不过真实的情况是，上述所有这些针对软件设计原则展开讨论的资源都源自Robert Martin的工作。Robert Martin并不是所有原则的发明者，但是他的确是第一个把这些原则收集到一起的人。下面列出这些软件设计原则：
? SRP—单一责任原则
? OCP—开关原则
? LSP—Liskov替换原则
? ISP—接口隔离原则
? DIP—依赖倒置原则
上述这个原则的集合正好对应于缩略词SOLID。
下面的软件设计原则列表来自于《Head First Design Patterns》一书：
? 封装变化
? 多用组合少用继承
? 基于接口而不是基于实现编程
? 在交互的对象间努力实现松耦合
? 类应该为了扩展而开放，但是为了修改而关闭
? 依赖于抽象，而不要依赖于具体类
? 仅仅对你的朋友交谈
? 不调用我，我们会调用你
? 一个类应该仅有一个改变的理由
当然，上述原则之间也存在许多的重叠之处。例如，“单一责任”原则与后面的“一个类应该仅有一个改变的理由”这一原则是相一致的。然而，它们所强调的重点还是有所不同。更多的细节在此不便赘述。
所有这些设计原则的真正动机在于，努力构建出能够适应变化的软件。上述原则分别对于不同的原则进行相应的阐述，最终目的也不过是为了创建出可以经得起时间测试的软件。
