博客园_倪大虾

高效管理ASP.NET的JavaScript库

2011-06-02T01:29:00Z

简介

对于ASP.NET开发人员来说,管理项目中的JavaScript都很随意：

我想这很大程度上可能是因为网上没有如何妥善处理ASP.NET中JavaScript的可靠信息。此文的目的就是提供一种最佳方案，用于管理ASP.NET中的JavaScript。该方案将能解决以下问题：

内联JS：把JS直接放在页面中将导致页面臃肿不堪。
发布JS：经常忘记发布JS文件。
错误引用：在其它Web程序中引用JS时经常失败。
依赖性：需要记住JS文件中错综复杂的依赖关系。
无效引用：页面上引用的JS从来没有被用到。
HTTP/HTTPS：跨HTTPS页面引用HTTP的JS。
重构：重构一个新版本将花费大量时间。
冗余：多次引用统一个JS文件。

预备知识
确保已安装Visual Studio 2010。Express版可能不支持此文涉及到的一些概念。

概述
大部分上述问题是由把JS或JS文件引用直接放到ASPX页面引起的。对几乎所有上述问题的解决方法是使用ASP.NET的内置功能来嵌入JS文件到一个DLL，然后动态引用这些文件。本文将演示这些功能，以及一些充分使用它们的技巧。接下来我们将逐步介绍该如何实现。

开始
第一步，启动Visual Studio 2010,并新建一个名为`ParchmentPurveyor的`空Web程序。
接下来添加一个窗体：Default.aspx，并添加一些简单的HTML代码。大致如下：
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="ParchmentPurveyor.Default" %>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Parchment Purveyor</title>
</head>
<body>
<form id="form1" runat="server">
<h1>Parchment Purveyor</h1>
<p>Paper for printers, painting, publication,
paper planes, and plenty of other plebeian projects!</p>
</form>
</body>
</html>

添加JS
不同于在站点中添加JS文件，我们新建一个项目，用于包含我们所有的JS文件。在解决方案中添加一个新的类库项目`JavaScriptLibrary：`
项目添加后删除Class1.cs文件，右键项目，选择添加文件夹，并命名为JavaScript，然后在该文件夹中添加两个JS文件，分别为ShowMessage.js和GreetUser.js，下一步，在项目中添加一个类`JavaScriptHelper（注意不要放到`JavaScript目录下`），现在解决方案目录结构如下：`
接下来编写JS，在ShowMessage.js中添加如下代码：
function ShowMessage(msg) {
alert("Message From Website: " + msg);
}
在GreetUser.js文件中添加如下代码：
function GreetUser() {
ShowMessage("Greetings and Salutations!");
}
注意，GreetUser()依赖于ShowMessage()。

嵌入JS文件
相比把JS文件发布到站点，我们更乐于把它们嵌入到DLL。这样子，如果DLL被发布到站点，那么所有JS文件也被自动发布。做到一点很简单，我们只需要右键JS文件，打开属性页，为“生成操作”选择“嵌入资源”即可，如下：
在确定JS文件嵌入DLL后，你需要使它们能够被Web用户访问。为此，需要为项目`JavaScriptLibrary添加System.Web的引用：`
然后编辑JavaScriptHelper.cs,添加如下代码：
using System.Web.UI;

[assembly: WebResource("JavaScriptLibrary.JavaScript.ShowMessage.js", "application/x-javascript")]
[assembly: WebResource("JavaScriptLibrary.JavaScript.GreetUser.js", "application/x-javascript")]
这样就能保证Web用户通过客户端访问嵌入式JS文件了。

引用嵌入式JS文件
现在你已嵌入了JS文件，并能通过客户端电脑访问它们。在使用的时候，你必须在页面上引用它们。为此，需要对`JavaScriptHelper类做如下修改：`
using System;
using System.Web.UI;

[assembly: WebResource("JavaScriptLibrary.JavaScript.ShowMessage.js", "application/x-javascript")]
[assembly: WebResource("JavaScriptLibrary.JavaScript.GreetUser.js", "application/x-javascript")]

namespace JavaScriptLibrary
{

/// <summary>
/// 帮助页面引用嵌入式JS文件
/// </summary>
public class JavaScriptHelper{

#region 静态字段
private const string NAME_SHOW_MESSAGE = "JavaScriptLibrary.JavaScript.ShowMessage.js";
private const string NAME_GREET_USER = "JavaScriptLibrary.JavaScript.GreetUser.js";
#endregion

#region 公共方法
/// <summary>
/// 在页面上引用ShowMessage.js文件
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
public static void Include_ShowMessage(ClientScriptManager manager){
IncludeJavaScript(manager, NAME_SHOW_MESSAGE);
}

/// <summary>
/// 在页面上引用GreetUser.js文件 (包括所有依赖文件)
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
public static void Include_GreetUser(ClientScriptManager manager){
//依赖(ShowMessage.js).
Include_ShowMessage(manager);
//引用 GreetUser.js.
IncludeJavaScript(manager, NAME_GREET_USER);
}
#endregion

#region 私有方法
/// <summary>
/// 在页面上引用指定的嵌入式js文件
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
/// <param name="resourceName">用于标示嵌入式JS文件的名字</param>
private static void IncludeJavaScript(ClientScriptManager manager, string resourceName){
var type = typeof(JavaScriptLibrary.JavaScriptHelper);
manager.RegisterClientScriptResource(type, resourceName);
}
#endregion
}
}
`IncludeJavaScript()是关键所在。它通过调用RegisterClientScriptResource()确保为嵌入式JS文件获取一个脚本标签。Include_GreetUser()调用了IncludeJavaScript()，同时也调用了Include_ShowMessage()（用于处理依赖关系）。因此，任何页面在引用GreetUser()时也将引用ShowMessage()。`
现在我们有了可用的类，接下在让我们在Default.aspx页面中试用它。首先在站点`ParchmentPurveyor中添加对JavaScriptLibrary的引用：`
接下来我们需要修改引用JS页面的后台代码。
using System;
using System.Web.UI;

namespace ParchmentPurveyor
{
public partial class Default : System.Web.UI.Page{
protected override void OnPreRender(EventArgs e){
base.OnPreRender(e);
JavaScriptLibrary.JavaScriptHelper.Include_GreetUser(Page.ClientScript);
}
}
}
最后，还有一件事要做——从页面调用GreetUser()。为此，我们需要在页面中添加如下JS（我选择把它添加到<head>标签中）：
<head runat="server">
<title>Parchment Purveyor</title>
<script type="text/javascript">
window.onload = function () { GreetUser(); };
</script>
</head>
好了，除了还有一些琐碎的事要处理外，我们已基本完成。在处理那些之前，让让我们看一下成果。编译整个解决方案—〉右键在浏览器中查看Default.aspx页面：
右键查看页面源码，你可能看到如下内容（src="/WebResource.axd.."部分有删减）：
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>
Parchment Purveyor
</title>
<script type="text/javascript">
window.onload = function () { GreetUser(); };
</script>
</head>
<body>
<form method="post" action="Default.aspx" id="form1">
<div class="aspNetHidden">
<input type="hidden" name="VIEWSTATE" id="VIEWSTATE" value="..." />
</div>

<script src="/WebResource.axd?d=fslk3GLsk3Slek&t=1234" type="text/javascript"></script>
<script src="/WebResource.axd?d=fglk3kSl3LS5&t=5678" type="text/javascript"></script>
<h1>Parchment Purveyor</h1>
<p>Paper for printers, painting, publication,
paper planes, and plenty of other plebeian projects!</p>
</form>
</body>
</html>
请注意引用“WebResource.axd”的两个<script>标签。它提供了让客户端访问嵌入式信息的基本功能。注意，第一个<script>标签注册了`ShowMessage(),第二个`<script>标签注册了`GreetUser()。在你的JS库中调用Include_GreetUser()时，上面所有标签都会被引入到页面中。`

后期引用
有时上面技术可能会引用JS文件失败。例如当我使用第三方工具工作时，就可能在渲染阶段阻止调用.NET代码。当你在渲染阶段引用那些函数时，脚本标签不会被插入页面。这是因为页面一开始就已经呈现为HTML。对这个问题的解决方法是构造一个替换函数,并在HTML底部附近插入脚本标签。我称之为“后期引用”，为此，需要对JavaScriptHelper做一些修改：
using System;
using System.Web;
using System.Web.UI;

[assembly: WebResource("JavaScriptLibrary.JavaScript.ShowMessage.js", "application/x-javascript")]
[assembly: WebResource("JavaScriptLibrary.JavaScript.GreetUser.js", "application/x-javascript")]

namespace JavaScriptLibrary {

/// <summary>
/// 帮助页面引用嵌入式JS文件
/// </summary>
public class JavaScriptHelper {
#region Constants
private const string TEMPLATE_SCRIPT = "<script type=\"text/javascript\" src=\"{0}\"></script>\r\n";
private const string NAME_SHOW_MESSAGE = "JavaScriptLibrary.JavaScript.ShowMessage.js";
private const string NAME_GREET_USER = "JavaScriptLibrary.JavaScript.GreetUser.js";
#endregion

#region 公共方法
/// <summary>
/// 页面引用ShowMessage.js文件
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
/// <param name="late">是否在HTML底部引用JS</param>
public static void Include_ShowMessage(ClientScriptManager manager, bool late = false) {
IncludeJavaScript(manager, NAME_SHOW_MESSAGE, late);
}
/// <summary>
/// 页面引用GreetUser.js文件(包括所有依赖文件)
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
/// <param name="late">是否在HTML底部引用JS</param>
public static void Include_GreetUser(ClientScriptManager manager, bool late = false) {
// 依赖 (ShowMessage.js).
Include_ShowMessage(manager, late);
// 引用 GreetUser.js.
IncludeJavaScript(manager, NAME_GREET_USER, late);
}
#endregion

#region 私有方法
/// <summary>
/// 页面引用指定的嵌入式JS文件
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
/// <param name="resourceName">标示嵌入式JS文件的名字</param>
/// <param name="late">是否在HTML底部引用JS</param>
private static void IncludeJavaScript(ClientScriptManager manager, string resourceName, bool late) {
var type = typeof(JavaScriptLibrary.JavaScriptHelper);
if (!manager.IsStartupScriptRegistered(type, resourceName)) {
if (late) {
var url = manager.GetWebResourceUrl(type, resourceName);
var scriptBlock = string.Format(TEMPLATE_SCRIPT, HttpUtility.HtmlEncode(url));
manager.RegisterStartupScript(type, resourceName, scriptBlock);
}
else {
manager.RegisterClientScriptResource(type, resourceName);
manager.RegisterStartupScript(type, resourceName, string.Empty);
}
}
}
#endregion
}
}
为每个方法添加一个参数late。该参数默认值为false,因此这些方法依旧可以按照原有方式调用。该参数为false表示原有行为不变，为true时将导致在HTML结尾部分引用脚本段。可能注意到，在late=false时，我仍然调用了RegisterStartupScript()，但传入了一个空字符串(所以不会在HTML插入任何内容)。完成后IsStartupScriptRegistered()将会返回正确值。这样，即使在late被置false后调用了其中的一个函数，又把late置为true,JS也不会被多次引用。如果要看效果，注释掉后台代码OnPreRender()，并在页面中做如下修改：
<body>
<form id="form1" runat="server">
<h1>Parchment Purveyor</h1>
<p>Paper for printers, painting, publication,
paper planes, and plenty of other plebeian projects!</p>
<% // This gets called during the render stage.
JavaScriptLibrary.JavaScriptHelper.Include_GreetUser(Page.ClientScript, true); %>
</form>
</body>
在运行程序时，如果观察页面源码，你会发现这将调用HTML底部<script>标签引用的函数。

外部JS
到目前为止，我只是演示了如何引用嵌入式JS。然而，有时候会需要联接到外部JS文件。为此，需要在JavaScriptHelper添加一个新函数：
/// <summary>
/// 在页面里引用指定的外部JavaScript文件
/// </summary>
/// <param name="page">当前页面</param>
/// <param name="key">唯一标示外部JavaScript文件的名字</param>
/// <param name="httpUrl">外部JavaScript文件的URL地址</param>
/// <param name="httpsUrl">启用SSL时外部JavaScript文件的URL地址</param>
/// <param name="late">是否需要在HTML下面引用JavaScript</param>
private static void IncludeExternalJavaScript(Page page, string key, string httpUrl, string httpsUrl, bool late) {
var manager = page.ClientScript;
var type = typeof(JavaScriptLibrary.JavaScriptHelper);
bool isStartupRegistered = manager.IsStartupScriptRegistered(type, key);
bool isScriptRegistered = manager.IsClientScriptIncludeRegistered(type, key);
if (!(isStartupRegistered || isScriptRegistered)) {
string url;
if (page.Request.Url.Scheme.ToLower() == "http") {
url = httpUrl;
}
else {
url = httpsUrl;
}
if (late) {
manager.RegisterStartupScript(type, key, string.Format(TEMPLATE_SCRIPT, HttpUtility.HtmlEncode(url)));
}
else {
manager.RegisterClientScriptInclude(type, key, url);
}
}
}
做为常用外部JS文件示例，我将使用微软CDN上的JS文件。如其它JS文件一样，首先在JavaScriptHelper 类中添加一个函数，供页面调用jQuery:
private const string NAME_JQUERY = "jQuery";
private const string URL_JQUERY = "http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js";
private const string URL_JQUERY_HTTPS = "https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js";
/// <summary>
/// 页面引用jQuery.js
/// </summary>
/// <param name="page">当前页面.如果传入为null,则使用HTTP上下文的当前</param>
/// <param name="late">是否需要在HTML下面引用JavaScript</param>
public static void Include_jQuery(Page page,bool late=false) {
if (page == null)
page = (Page)HttpContext.Current.Handler;
IncludeExternalJavaScript(page,NAME_JQUERY,URL_JQUERY,URL_JQUERY_HTTPS,late);
}
最后你能后在页面里通过在OnPreRender()里调用添加的方法实现对jQuery的引用。
protected override void OnPreRender(EventArgs e) {
base.OnPreRender(e);
JavaScriptLibrary.JavaScriptHelper.Include_jQuery(Page);
JavaScriptLibrary.JavaScriptHelper.Include_GreetUser(Page.ClientScript);
}
运行程序，察看页面源码，你会看到如下jQuery引用：
<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js" type="text/javascript"></script>

添加新的JS文件
一旦所有内容完成部署，在需要添加新的JS文件时，只需要几步即可完成，如下：
在JavaScript目录中添加js文件。引用外部js文件跳过该步骤；
设置“生成操作”为“嵌入资源”。引用外部js文件跳过该步骤；
添加assembly属性表示js文件为Web资源。引用外部js文件跳过该步骤；
在`JavaScriptHelper类中添件一个引用JS文件的函数；`
从页面，控件或母版页上调用你创建的函数；

不引用JS文件
以上所做都是为了引用JS文件，但也有时候你可能不需要引用JS文件。例如，在使用第三方控件库时，它们可能通过其他方式引用了JS，这时唯一阻止某一JS文件被两次引用的方法是通过你的代码消除重复引用（由第三方库帮你引用，不需要重复引用）。这可以通过在`JavaScriptHelper增加额外的函数`实现。在实现之前，先让我们演示一下这些技术应用的场景。假设你的第三方控件InlineGreeting.ascx引用了jQuery，其内容大致如下：
<%@ Control Language="C#" %>

<%-- This is a bad way to do things, but we can luckily overcome this obstacle. --%>
<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#lblGreeting").text("Hello");
});
</script>
<p>
<label id="lblGreeting"></label>
</p>
现在假设我们有另一个自己的控件Hello.ascx，使用了同样的jQuery文件：
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="Hello.ascx.cs" Inherits="ParchmentPurveyor.Hello" %>

<script type="text/javascript">
$(document).ready(GreetUser);
</script>
Hello.ascx的后台代码引用了jQuery，如下：
protected override void OnPreRender(EventArgs e) {
base.OnPreRender(e);
JavaScriptLibrary.JavaScriptHelper.Include_GreetUser(Page.ClientScript);
JavaScriptLibrary.JavaScriptHelper.Include_jQuery(Page);
}

现在，如果在Default.aspx中引用上述用户控件，jQuery将会被引用两次（第三方一次，我们一次）。为避免此类情况发生，我们将在JavaScriptHelper类中添加两个方法，ExcludeJavaScript()和Exclude_jQuery()：
private const string NAME_DUMMY_FILE = "JavaScriptLibrary.JavaScript.DummyFile.js";
/// <summary>
/// 该页面排除jQuery.js
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
public static void Exclude_jQuery(ClientScriptManager manager) {
ExcludeJavaScript(manager, NAME_JQUERY);
}
/// <summary>
/// 注册一个虚假的脚本来阻止包含真实的JavaScript
/// </summary>
/// <param name="manager">通过Page.ClientScript访问</param>
/// <param name="key">唯一标示JavaScript文件的名字</param>
private static void ExcludeJavaScript(ClientScriptManager manager, string key) {
var type = typeof(JavaScriptLibrary.JavaScriptHelper);
var url = manager.GetWebResourceUrl(type, NAME_DUMMY_FILE);
manager.RegisterStartupScript(type, key, string.Empty);
manager.RegisterClientScriptInclude(type, key, url);
}
注意,我们定义了一个新的常量NAME_DUMMY_FILE。上面函数假定我们按照上述步骤在JavaScript文件夹里添加了一个空JS文件，并嵌入了它。这个空虚拟JS文件可以引用在任何我们想不引用JS文件的地方。为阻止我们的库引用jQuery只需要调用在Default.aspx页面的Page_Load()中调用Exclude_jQuery()：
protected void Page_Load(object sender, EventArgs e) {
//我们通过第三方控件引用了jQuery,那么将避免再一次引用
JavaScriptLibrary.JavaScriptHelper.Exclude_jQuery(Page.ClientScript);
}
现在我们要做的是修改Default.aspx引用InlineHello.ascx和Hello.ascx，结果如下：
...
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Parchment Purveyor</title>
<script type="text/javascript">
// window.onload = function () { GreetUser(); };
</script>
</head>
<body>
<form id="form1" runat="server">
<div>
<h1>Parchment Purveyor</h1>
<p>Paper for printers, painting, publication,
paper planes, and plenty of other plebeian projects!</p>
<% // 这在渲染阶段调用
JavaScriptLibrary.JavaScriptHelper.Include_GreetUser(Page.ClientScript, true); %>
</div>
<%-- An inline greeting (pretend this comes from a third-party control library. --%>
<greet:InlineHello ID="InlineHello1" runat="server" />
<%-- Our jQuery greeting. --%>
<greet:Hello runat="server" />
</form>
</body>
</html>
现在我们已清楚在调用Include_jQuery()之前先调用Exclude_jQuery()，就能够阻止我们的JS库引用jQuery.js文件。这就是说jQuery只会被我们的第三方控件引用。大多数时候这种情况可以避免。然而，有时候不可避免，这时该技术也可以让我们的HTML更加干净整洁。

你都有哪些收获?
经过这些工作，依旧有同样的HTML输出，你可能会问“通过添加这些额外的代码，我获得了什么？”。那么这里就列出几点：
内联JS：通过避免把JS直接内联到页面,减小了页面尺寸。
发布JS：当你发布Web站点时，你不需要发布引用的JS文件，只发布DLL就足够了。
错误引用：即使改变了程序路径，你也不用为修改JS路径担忧。
依赖性：文件依赖自动管理。如果你引用了GreetUser.js文件，那么ShowMessage.js文件会自动被引用。
无效引用：除非你调用的函数引用了它，否则不会有JS加载到页面。这将避免页面上出现无用的JS（潜在的加快了页面载入时间）。
HTTP/HTTPS：脚本标记的代码输出与协议无关，因此协议对所有页面一样。
重构：如果你想使用一个不同版本的脚本，你只需要在一个地方修改它。例如，如果你决定切换到CDN版本的jQuery，而不是你自己承载，这可能非常有用。更新一个新版本的jQuery时也非常有用。
冗余：不管你在方法中引用多少次，该脚本标签仅会在页面上本引用一次。
本文链接

如何向妻子解释设计模式

2011-05-30T01:55:00Z

简介

自上篇翻译<如何向妻子解释OOD>后收到了很好的反应。故特继续翻译作者的<How I explained Design Patterns to my wife: Part 1>一文，以飨读者。在此文中，作者依旧通过与妻子浅显易懂的对话，向读者解释了什么是设计模式。

设计模式是什么?

Shubho:通过我们关于面向对象设计原则（OODP，即SOLID原则）的对话，我想你已经对面向对象设计原则（OODP）有了基本的认识。希望你不要介意我把对话分享到博客上。你可以在这找到它：<如何向妻子解释OOD>.

设计模式是这些原则在某些特定公共场景下标准化的应用，接下来让我们通过一些例子学习什么是设计模式。

Farhana: 当然，我喜欢例子。

Shubho: 让我们以汽车为例讨论一下。汽车是一个很复杂的对象，由成千上万的其它对象组成，如发动机，车轮，方向盘，车座，车体等等其他不同的部分或部件。

汽车部件

当装配汽车时，制造商需要集中并装配这些更小的自成汽车子系统的不同部件。而这些不同的小部件同样也是复杂的对象，其它制造商同样要生产并组装它们。在生产汽车时，汽车公司并不会为怎么生产组装这些部件操心（前提是他们要确保这些对象/设备的质量）。当然，汽车制造商更加关心怎么装配这些不同部件以便能生产不同型号的汽车。

通过遵循不同的设计，组装不同的部件，生产不同型号的汽车

Farhana: 汽车制造公司必须有如何生产不同型号汽车的设计图或蓝图，对吗？

Shubho: 当然，并且这些设计都是良好的，他们花费大量的时间和精力来做这些设计。一旦设计完成，生产汽车就仅仅是照葫芦画瓢了。

Farhana: 嗯。如果事先有一些好的设计，就能在短时间内遵照这些设计生产不同产品，并且制造商在每次生产某一个型号产品时就不需要重新设计或重新发明车轮，他们只需要按照已有的设计办事就行了。

生产不同型号产品（汽车）的不同设计图

Shubho: 你抓到重点了。现在假设我们是软件生产商，我们使用基于需求而来的不同组件或功能构建各种不同的软件程序。当生产这些不同软件系统时，我们常常需要为一些不同软件系统中存在的相同情况开发代码，对吗？

Farhana: 是的，在开发不同软件程序时经常遇到相同的设计问题。

Shubho: 我们尝试使用面向对象的方式开发软件，并尝试应用OOPD来让代码能易于维护，可复用，可扩展。无论什么时候，当我们遇到这些设计问题时，如果我们有一组经过谨慎开发，良好测试的对象以供使用会不会更好呢？

Farhana: 是的，这样能够节省时间，生产出更好的软件，且利于以后维护。

Shubho: 很好！从设计上来说，它的好处是你不需要开发那些对象。经过多年发展，人们已经遇到过一些类似的设计问题，并已经形成有一些公认的，良好的已标准化的设计方案。我们称之为设计模式。

我们一定好感谢四人组，他们在《设计模式：可复用面向对象软件设计》中总结出了23种基本的设计模式。四人组由Erich Gamma, Richard Helm, Ralph Johnson, 和John Vlissides组成。实际中有很多面向对象设计模式，但这23种模式被公认为是所有其他设计模式的基础。

Farhana: 我能发明一个新的模式吗？这可能吗？

Shubho: 当然，亲爱的，为什么不能呢？！设计模式不是由科学家发明创造的。它们是被发现找到的。这意味着任何通用问题场景中都有一些好的设计方案在那。如果我们能够指出一个能够解决一个新的设计相关问题的面向对象设计，那么这将会是一个由我们定义的新的设计模式。谁知道呢？！如果我们发现找到一些设计模式，或许将来有一天人们会称我们为二人组，哈哈。

Fahana: :)

我们将如何学习设计模式？

Shubho: 我一直认为例子是学习的最好途径。在我们的学习方法中，我们不会先讨论理论后讨论实现。我认为这是很糟糕的方式。设计模式不是基于理论的发明。事实上，问题场景首先出现，其次是基于这些问题的来龙去脉和需求，然后是一些设计方案的演化，最后其中的一些被标准化为模式。所以对每一个我们讨论的设计模式，我们将尝试理解并分析一些现实生活中的例子，然后一步步尝试归纳一个设计，并最后总结一些与某些模式匹配设计。设计模式就是在这些相似过程中发现的。你认为呢？

Farhana:我想这种方式对我更有用。如果我能通过分析问题和归纳方案得出设计模式，我就不用死记那些设计模式和定义了。请按照你的方式继续。

一个常见的设计问题和它的解决方案

Shubho: 让我们考虑下面的场景：

我们房间里有些电器（电灯，风扇等）。这些设备按照某些方式布局，并由开关控制。任何时候你都能替换或排查一个电器而不用碰到其他东西。例如，你可以换一个电灯而不需要换开关。同样，你可以换一个开关或排查它而不需要碰到或替换相应的电灯或风扇；甚至你可以用把电灯连接到风扇的开关上，把风扇连到电灯的开关上，而不需要碰到开关。

电器：风扇和电灯

风扇和电灯的两种不同开关，一个普通点，另一个别致点

Farhana: 是的，但就是这样子，对吗？

Shubho: 是的，确实如此，就该如此布局。当不同东西联系在一起时，它们应该按照一定方式联系：修改或替换一个系统时不会影响到另一个，或者说即便有，也应该最小化。这能够让你的系统易于管理，且成本低。想想一下，如果改一下房间里的灯同时需要改开关，你会乐意在你房子上花钱并安装这个系统吗？

Farhana: 当然不会。

Shubho: 现在，让我们思考一下电灯或风扇如何连接到开关上才能达到改变一个不会影响到另一个。你认为该如何？

Farhana: 用电线!

Shubho: 很好。把电灯/风扇和开关联系到一起的是电线和电器布局。我们可以它们看做不同系统间相互联系的桥梁。其基本的思想是，一个事物不能和另一外一个事物直接联系。当然啦，它们应当通过某些桥梁或接口联系在一起。用软件术语来说，这叫“松耦合”。

Farhana: 我知道了。

Shubho: 现在，让我们尝试推断在电灯/风扇和开关例子中的几个关键问题，并尝试推断它们是如何设计并联系起来的。

Farhana: 好，我们试一下。

例子中我们有开关，可能有几种开关，如普通的开关，漂亮的开关，但通常来说它们还是开关，并且每种开关都能够打开和关闭。

所以下面我们会有一个开关基类Switch：

public class Switch {
public void On() {
//打开开关
}
public void Off() {
//关闭开关
}
}

接下来我们可以有一些具体的开关，例如一个漂亮开关，一个普通开关等等，当然，我们会让类FancySwitch和NormalSwitchnd继承类Switch：

public class NormalSwitch : Switch {
}
public class FancySwitch : Switch {
}

这里的两个具体类有自己的特征和行为，只是此时此刻，我们简单化以下。

Shubho: 非常棒，接下来电灯和风扇怎么办？

Farhana: 我试试. 根据OODP的开放闭合原则，我们知道只要可能，就应该尝试抽象，对吗？

Shubho: 对

Farhana: 跟开关不一样，风扇和电灯等是两种不同的事物。对于开关，我们能够使用一个开关基类Switch，但风扇和电灯是两个不同的事物，相比定义一个基类，接口可能更合适。一般来说，他们都是电器。所以我们可以定义一个接口，如IElectricalEquipment，作为对电灯和风扇的抽象，可以吗？

Shubho: 可以

Farhana: 好，每种电器都有些相同的功能。他们能够打开和关闭。所以接口可能如下：

public interface IElectricalEquipment {
void PowerOn(); //每种电器都能打开
void PowerOff(); //每种电器都能关闭
}

Shubho: 太好了，你很善于抽象东西。现在我们需要一座桥梁。在现实中，电线是桥梁。在我们对象设计中，开关知道如何打开和关闭电器，电器以某种方式联系到开关。这里我们没有电线，让电器连接到开关的唯一方式是封装。

Farhana: 是的，但开关不能直接知道风扇或电灯。开关应当知道一个电器IElectricalEquipment能够打开或关闭。这意味着，ISwitch应该有一个IElectricalEquipment实例，对吗？

Shubho: 对，对风扇或电灯的封装的实例是一个桥梁。所以让我们修改Switch类以便封装一个电器：

public class Switch {
public IElectricalEquipment equipment {
get;
set;
}
public void On() {
//开关打开
}
public void Off() {
//开关关闭
}
}

Farhana: 明白。让我们定义真实的电器：风扇和电灯。如我所见，一般来说它们都是电器，所以它们都简单实现了IElectricalEquipment接口。

下面是风扇类:

public class Fan : IElectricalEquipment {
public void PowerOn() {
Console.WriteLine("风扇打开");
}
public void PowerOff() {
Console.WriteLine("风扇关闭");
}
}

下面是电灯类:

public class Light : IElectricalEquipment {
public void PowerOn() {
Console.WriteLine("电灯打开");
}
public void PowerOff() {
Console.WriteLine("电灯关闭");
}
}

Shubho:太好了。现在让开关工作。当开关打开关闭的时候它应当能够打开关闭电器（它连接到的）。

这里的关键点是：

当开关按下开时，连接的电器也应该打开。
当开关按下关时，连接的电器也应该关闭。

大致的代码如下:

static void Main(string[] args) {
//构造电器设备:风扇,开关
IElectricalEquipment fan = new Fan();
IElectricalEquipment light = new Light();

//构造开关
Switch fancySwitch = new FancySwitch();
Switch normalSwitch = new NormalSwitch();

//把风扇连接到开关
fancySwitch.equipment = fan;

//开关连接到电器,那么当开关打开或关闭时电器应该打开/关闭
fancySwitch.On();
fancySwitch.Off();

//把电灯连接到开关
fancySwitch.equipment = light;
fancySwitch.On(); //打开电灯
fancySwitch.Off(); //关闭电灯
}

Farhana: 明白。开关的On()方法应当内部调用电器的TurnOn()方法，Off()方法应当内部调用TurnOff()方法，所以开关类Switch应如下：

public class Switch {
public IElectricalEquipment equipment {
get;
set;
}
public void On() {
Console.WriteLine("开关打开");
equipment.PowerOn();
}
public void Off() {
Console.WriteLine("开关关闭");
equipment.PowerOff();
}
}

Shubho: 很好。这自然允许你把风扇从一个开关接到另一个上。不过你看，反过来也可以。这意味着你可以改变风扇或电灯的开关而不需要碰到风扇或电灯。例如，你可以很轻松的把点灯的开关从FancySwitch换到NormalSwitch上，如下：

normalSwitch.equipment = light;
normalSwitch.On(); //打开电灯
normalSwitch.Off(); //关闭电灯

你看，连接一个抽象电器到一个开关（通过封装）能够让你改变开关和电器而不会对对方产生影响。这个设计是优雅的，良好的。四人组为该模式取名为：桥接模式。

Farhana: 太棒了。我想我明白这个了。从根本上说，两个系统不应当直接联系或依赖与对方。当然，他们应该联系或依赖于抽象（如依赖倒置原则和开放闭合原则所讲），所以他们是松耦合的，因此我们可以在需要时改变我们的实现而不会对系统其他部分产生过多影响。

Shubho: 你理解了，亲爱的.我们看下桥接模式的定义：

"将抽象部分与实现部分分离，使它们都可以独立的变化"

你看我们的实现完美遵循该定义。如果你有一个类设计器（如Visual Studio或其他支持该功能的IDE环境），你会看到类似的如下类图：

桥接模式类图

在这里， Abstraction 是开关基类Switch。 RefinedAbstraction 是具体开关类 (FancySwitch, NormalSwitch 等等。)。 Implementor 是电器接口IElectricalEquipment。ConcreteImplementorA 和ConcreteImplementorB 是电灯类Light和风扇类Fan。

Farhana: 问你个问题，只是好奇啊。如你所说有很多其他的设计模式，为什么你以桥接模式开始呢？有重要原因吗？

Shubho: 这个问题很好。是的，我以桥接模式而不以其他开始是因为一个理由。我认为桥接模式是所有面向对象模式的基础。理由如下：

它教导如何思考抽象，这是面向对象设计模式的关键概念。
它实现了基本的OOD原则。
它容易理解。
如果正确理解该模式，学习其他模式会很容易。

Farhana: 你认为我理解的对吗？

Shubho: 我认为你理解的非常正确。

Farhana: 那么接下来是什么？

Shubho: 通过理解桥接模式，我们仅仅是开始理解设计模式的思想。在我们接下的对话中，我们将会学习其他的设计模式，我希望你不会觉得它们无聊。

Farhana:不会的，相信我。

本文链接

如何向妻子解释OOD

2011-01-25T13:47:00Z

前言

此文译自CodeProject上<How I explained OOD to my wife>一文，该文章在Top Articles上排名第3，读了之后觉得非常好，就翻译出来，供不想读英文的同学参考学习。

作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她本来是，后来因为他们孩子出生放弃了)，于是作者就试图根据自己在软件开发设计方面的经验帮助她学习面向对象设计(OOD)。

自作者从事软件开发开始，作者常常注意到不管技术问题看起来多复杂，如果从现实生活的角度解释并以对答的方式讨论，那么它将变得更简单。现在他们把在OOD方面有些富有成效的对话分享出来，你可能会发现那是一种学习OOD很有意思的方式。

下面就是他们的对话：

OOD简介

Shubho:亲爱的，让我们开始学习OOD吧。你了解面向对象原则吗？

Farhana:你是说封装，继承，多态对吗？我知道的。

Shubho:好，我希望你已了解如何使用类和对象。今天我们学习OOD。

Farhana:等一下。面向对象原则对面向对象编程(OOP)来说不够吗？我的意思是我会定义类，并封装属性和方法。我也能根据类的关系定义它们之间的层次。如果是，那么还有什么？

Shubho:问得好。面向对象原则和OOD实际上是两个不同的方面。让我给你举个实际生活中的例子帮你弄明白。

再你小时候你首先学会字母表，对吗？

Farhana:嗯

Shubho:好。你也学了单词，并学会如何根据字母表造词。后来你学会了一些造句的语法。例如时态，介词，连词和其他一些让你能造出语法正确的句子。例如：

"I" (代词) "want" (动词) "to" (介词) "learn" (动词) "OOD"(名词)。

看，你按照某些规则组合了单词，并且你选择了有某些意义的正确的单词结束了句子。

Farhana:OK，这意味着什么呢？

Shubho:面向对象原则与这类似。OOP指的是面向对象编程的基本原则和核心思路。在这里，OOP可以比作英语基础语法，这些语法教你如何用单词构造有意义且正确的句子，OOP教你在代码中构造类，并在类里封装属性和方法，同时构造他们之间的层次关系。

Farhana:嗯..我有点感觉了，这里有OOD吗？

Shubho:马上就有答案。现在假定你需要就某些主题写几篇文章或随笔。你也希望就几个你擅长主体写几本书。对写好文章/随笔或书来说，知道如何造句是不够的，对吗？为了使读者能更轻松的明白你讲的内容，你需要写更多的内容，学习以更好的方式解释它。

Farhana:看起来有点意思...继续。

Shubho:现在，如果你想就某个主题写一本书，如学习OOD，你知道如何把一个主题分为几个子主题。你需要为这些题目写几章内容，也需要在这些章节中写前言，简介，例子和其他段落。你需要为写个整体框架，并学习一些很好的写作技巧以便读者能更容易明白你要说的内容。这就是整体规划。

在软件开发中，OOD是整体思路。在某种程度上，设计软件时，你的类和代码需能达到模块化，可复用，且灵活，这些很不错的指导原则不用你重新发明创造。确实有些原则你已经在你的类和对象中已经用到了，对吗？

Farhana:嗯...有个大概的印象了，但需要继续深入。

Shubho:别担心，你马上就会学到。我们继续讨论下去。

为什么要OOD？
Shubho:这是一个非常重要的问题。当我们能很快地设计一些类，完成开发并发布时，为什么我们需要关心OOD？那样子还不够吗？
Farhana:嗯，我早先并不知道OOD，我一直就是开发并发布项目。那么关键是什么？
Shubho:好的，我先给你一句名言：
走在结冰的河边不会湿鞋，开发需求不变的项目畅通无阻(Walking on water and developing software from a specification are easy if both are frozen)
-Edward V. Berard
Farhana:你的意思是软件开发说明书会不断变化？
Shubho:非常正确！软件开发唯一的真理是“软件一定会变化”。为什么?
因为你的软件解决的是现实生活中的业务问题，而现实生活中得业务流程总是在不停的变化。
假设你的软件在今天工作的很好。但它能灵活的支持“变化”吗？如果不能，那么你就没有一个设计敏捷的软件。
Farhana:好，那么请解释一下“设计敏捷的软件”。
Shubho:"一个设计敏捷的软件能轻松应对变化，能被扩展，并且能被复用。"
并且应用好"面向对象设计"是做到敏捷设计的关键。那么，你什么时候能说你在代码中很好的应用了OOD？
Farhana:这正是我的问题。
Shubho:如果你代码能做到以下几点，那么你就正在OOD：
面向对象
复用
能以最小的代价满足变化
不用改变现有代码满足扩展
Farhana：还有？
Shubho:我们并不是孤立的。很多人在这个问题上思考了很多，也花费了很大努力，他们试图做好OOD，并为OOD指出几条基本的原则(那些灵感你能用之于你的OOD)。他们最终也确实总结出了一些通用的设计模式(基于基本的原则)。
Farhana:你能说几个吗？
Shubho:当然。这里有很多涉及原则，但最基本的是叫做SOLID的5原则(感谢Uncle Bob,伟大OOD导师)。

S = 单一职责原则 Single Responsibility Principle
O = 开放闭合原则 Opened Closed Principle
L = Liscov替换原则 Liscov Substitution Principle
I = 接口隔离原则 Interface Segregation Principle
D = 依赖倒置原则 Dependency Inversion Principle

接下去，我们会仔细探讨每一个原则。
单一职责原则
Shubho:我先给你展示一张海报。我们应当谢谢做这张海报的人，它非常有意思。
单一职责原则海报
它说："并不是因为你能，你就应该做"。为什么？因为长远来看它会带来很多管理问题。
从面向对象角度解释为："引起类变化的因素永远不要多于一个。"
或者说"一个类有且只有一个职责"。
Farhana：能解释一下吗？
Shubho:当然，这个原则是说，如果你的类有多于一个原因会导致它变化(或者多于一个职责)，你需要一句它们的职责把这个类拆分为多个类。
Farhana:嗯...这是不是意味着在一个类里不能有多个方法？
Shubho:不。你当然可以在一个类中包含多个方法。问题是，他们都是为了一个目的。如今为什么拆分是重要的？
那是因为：
每个职责是轴向变化的；
如果类包含多个职责，代码会变得耦合；
Farhana:能给我一个例子吗？
Shubho:当然，看一下下面的类层次。当然这个例子是从Uncle Bob那里得来，再谢谢他。
违反单一职责原则的类结构图
这里，Rectangle类做了下面两件事：
计算矩形面积；
在界面上绘制矩形；
并且，有两个应用使用了Rectangle类：
计算几何应用程序用这个类计算面积；
图形程序用这个类在界面上绘制矩形；
这违反了SRP(单一职责原则);
Farhana:如何违反的？
Shubho:你看，Rectangle类做了两件事。在一个方法里它计算了面积，在另外一个方法了它返回一个表示矩形的GUI。这会带来一些有趣的问题：
在计算几何应用程序中我们必须包含GUI。也就是在开发几何应用时，我们必须引用GUI库；
图形应用中Rectangle类的变化可能导致计算几何应用变化，编译和测试，反之亦然；
Farhana:有点意思。那么我猜我们应该依据职责拆分这个类，对吗？
Shubho:非常对，你猜我们应该做些什么？
Farhana:当然，我试试。下面是我们可能要做的：
拆分职责到两个不同的类中，如：
Rectangle:这个类应该定义Area()方法；
RectangleUI:这个类应继承Rectangle类，并定义Draw()方法。
Shubho:非常好。在这里，Rectangle类被计算几何应用使用，而RectangleUI被图形应用使用。我们甚至可以分离这些类到两个独立的DLL中，那会允许我们在变化时不需要关心另一个就可以实现它。
Farhana:谢谢，我想我明白SRP了。SRP看起来是把事物分离成分子部分，以便于能被复用和集中管理。我们也不能把SRP用到方法级别吗？我的意思是，我们可以写一些方法，它们包含做很多事的代码。这些方法可能违反SRP，对吗？
Shubho:你理解了。你应当分解你的方法，让每个方法只做某一项工作。那样允许你复用方法，并且一旦出现变化，你能购以修改最少的代码满足变化。
开放闭合原则
Shubho:这里是开放闭合原则的海报
开放闭合原则海报
从面向对象设计角度看,它可以这么说:"软件实体(类,模块,函数等等)应当对扩展开放，对修改闭合。"
通俗来讲，它意味着你应当能在不修改类的前提下扩展一个类的行为。就好像我不需要改变我的身体而可以穿上衣服。
Farhana:有趣。你能够按照你意愿穿上不同的衣服来改变面貌，而从不用改造身体。你对扩展开放了，对不？
Shubho:是的。在OOD里，对扩展开发意味着类或模块的行为能够改变，在需求变化时我们能以新的，不同的方式让模块改变，或者在新的应用中满足需求。
Farhana:并且你的身体对修改是闭合的。我喜欢这个例子。当需要变化时，核心类或模块的源代码不应当改动。你能用些例子解释一下吗？
Shubho:当然，看下面这个例子。它不支持"开放闭合"原则。
违反开发闭合原则的类结构
你看，客户端和服务段都耦合在一起。那么，只要出现任何变化，服务端变化了，客户端一样需要改变。
Farhana:理解。如果一个浏览器以紧耦合的方式按照指定的服务器(比如IIS)实现，那么如果服务器因为某些原因被其他服务器(如Apache)替换了，那么浏览器也需要修改或替换。这确实很可怕！
Shubho:对的。下面是正确的设计。
遵循开放闭合原则的类结构
在这个例子中，添加了一个抽象的服务器类，客户端包含一个抽象类的引用，具体的服务类实现了抽象服务类。那么，因任何原因引起服务实现发生变化时，客户端都不需要任何改变。
这里抽象服务类对修改是闭合的，实体类的实现对扩展是开放的。
Farhana:我明白了，抽象是关键，对吗？
Shubho:是的，基本上，你抽象的东西是你系统的核心内容，如果你抽象的好，很可能在扩展功能时它不需要任何修改(就像服务是一个抽象概念)。如果在实现里定义了抽象的东西(比如IIS服务器实现的服务)，代码要尽可能以抽象(服务)为依据。这会允许你扩展抽象事物，定义一个新的实现(如Apache服务器)而不需要修改任何客户端代码。
Liskov's 替换原则
Shubho:"Liskov's替换原则(LSP)"听起来很难，却是很有用的基本概念。看下这幅有趣的海报：
Liskov替换原则海报
这个原则意思是："子类型必须能够替换它们基类型。"
或者换个说法："使用基类引用的函数必须能使用继承类的对象而不必知道它。"
Farhana:不好意思，听起来有点困惑。我认为这个OOP的基本原则之一。也就是多态，对吗？为什么一个面向对象原则需要这么说呢？
Shubho:问的好。这就是你的答案：
在基本的面向对象原则里，"继承"通常是"is a"的关系。如果"Developer" 是一个"SoftwareProfessional",那么"Developer"类应当继承"SoftwareProfessional"类。在类设计中"Is a"关系非常重要，但它容易冲昏头脑，结果使用错误的继承造成错误设计。
"Liskov替换原则"正是保证继承能够被正确使用的方法。
Farhana:我明白了。有意思。
Shubho:是的，亲爱的，确实。我们看个例子：
Liskov替换原则类结构图
这里，KingFisher类扩展了Bird基类，并继承了Fly()方法，这看起来没问题。
现在看下面的例子：
违反Liskov替换原则类结构图
Ostrich(鸵鸟)是一种鸟(显然是),并从Bird类继承。它能飞吗？不能，这个设计就违反了LSP。
所以，即使在现实中看起来没问题，在类设计中，Ostrich不应该从Bird类继承，这里应该从Bird中分离一个不会飞的类，Ostrich应该继承与它。
Farhana:好，明白了。那么让我来试着指出为什么LSP这么重要：
如果没有LSP，类继承就会混乱；如果子类作为一个参数传递给方法，将会出现未知行为；
如果没有LSP，适用与基类的单元测试将不能成功用于测试子类；
对吗？
Shubho:非常正确。你能设计对象，使用LSP做为一个检查工作来测试继承是否正确。
接口分离原则
Shubho:今天我们学习"接口分离原则",这是海报：
接口分离原则海报
Farhana:这是什么意思？
Shubho:它的意思是："客户端不应该被迫依赖于它们不用的接口。"
Farhana:请解释一下。
Shubho:当然，这是解释：
假设你想买个电视机，你有两个选择。一个有很多开关和按钮，它们看起来很混乱，且好像对你来说没必要。另一个只有几个开关和按钮，它们很友好，且适合你使用。假定两个电视机提供同样的功能，你会选哪一个？
Farhana:当然是只有几个开关和按钮的第二个。
Shubho:对，但为什么？
Farhana:因为我不需要那些看起来混乱又对我没用的开关和按钮。

Shubho:以便外部能够知道这些类有哪些可用的功能,客户端代码也能根据接口来设计.现在,如果接口太大,包含很多暴露的方法,在外界看来会很混乱.接口包含太多的方法也使其可用性降低,像这种包含了无用方法的"胖接口"会增加类之间的耦合.你通过接口暴露类的功能,对.同样地,假设你有一些类,
这也引起了其他问题.如果一个类想实现该接口,那么它需要实现所有的方法,尽管有些对它来说可能完全没用.所以说这么做会在系统中引入不必要的复杂度,降低可维护性或鲁棒性.
接口隔离原则确保实现的接口有他们共同的职责,它们是明确的,易理解的,可复用的.
Farhana:你的意思是接口应该仅包含必要的方法,而不该包含其它的.我明白了.
Shubho:非常正确.一起看个例子.
下面是违反接口隔离原则的一个胖接口

注意到IBird接口包含很多鸟类的行为,包括Fly()行为.现在如果一个Bird类(如Ostrich)实现了这个接口，那么它需要实现不必要的Fly()行为(Ostrich不会飞).
Farhana:确实如此。那么这个接口必须拆分了？
Shubho:是的。这个"胖接口"应该拆分未两个不同的接口，IBird和IFlyingBird,IFlyingBird继承自IBird.

这里如果一种鸟不会飞(如Ostrich)，那它实现IBird接口。如果一种鸟会飞(如KingFisher)，那么它实现IFlyingBird.
Farhana:所以回头看包含了很多开关和按钮的电视机的例子，电视机制造商应该有一个电视机的图纸，开关和按钮都在这个方案里。不论任何时候，当他们向制造一种新款电视机时，如果他们想复用这个图纸，他们将需要在这个方案里添加更多的开关和按钮。那么他们将没法复用这个方案，对吗？
Shubho:对的。
Farhana:如果他们确实需要复用方案，它们应当把电视机的图纸份为更小部分，以便在任何需要造新款电视机的时候复用这点小部分。
Shubho:你理解了。
依赖倒置原则
Shubho:这是SOLID原则里最后一个原则。这是海报

它的意思是：高层模块不应该依赖底层模块，两者都应该依赖其抽象
Shubho:考虑一个现实中的例子。你的汽车是由很多如引擎，车轮，空调和其它等部件组成，对吗？
Farhana:是的
Shubho:好，它们没有一个是严格的构建在一个单一单元里；换句话说，它们都是可插拔的，因此当引擎或车轮出问题时，你可以修理它(而不需要修理其它部件),甚至可以换一个。
在替换时，你仅需要确保引擎或车轮符合汽车的设计(如汽车能使用任何1500CC的引擎或任何18寸的车轮)。
当然，汽车也可能允许你在1500CC引擎的地方安装一个2000CC的引擎，事实上对某些制造商(如丰田汽车)是一样的。
现在，如果你的汽车的零部件不具备可插拔性会有什么不同？
Farhana:那会很可怕！因为如果汽车的引擎出故障了，你可能修理整部车或者需要买一个新的。
Shubho:是的，那么该如何做到"可插拔性"呢？
Farhana:这里抽象是关键，对吗？
Shubho:是的，在现实中，汽车是高级模块或实体，它依赖于低级模块或实体，如引擎或车轮。
相比直接依赖于引擎或车轮，汽车应依赖于某些抽象的有规格的引擎或车轮，以便于如果任何引擎或车轮符合抽象，那么它们都能组合到汽车中，汽车也能跑动。
一起看下面的类图

Shubho:注意到上面Car类有两个属性，它们都是抽象类型(接口)。引擎和车轮是可插拔的，因为汽车能接受任何实现了声明接口的对象，并且Car类不需要做任何改动。
Farhana:所以，如果代码中不用依赖倒置，我们将面临如下风险：
使用低级类会破环高级代码；
当低级类变化时需要很多时间和代价来修改高级代码；
产生低复用的代码；
Shubho:你完全掌握了，亲爱的！
总结
Shubho：除SOLID原则外还有很多其它的面向对象原则。如：
"组合替代继承":这是说相对于继承，要更倾向于使用组合；
"笛米特法则"：这是说"你的类对其它类知道的越少越好"；
"共同封闭原则"：这是说"相关类应该打包在一起"；
"稳定抽象原则"：这是说"类越稳定，越应该由抽象类组成";
Farhana:我应该学习那些原则吗？
Shubho:当然可以。你可以从整个网上学习。仅仅需要Google一下那些原则，然后尝试理解它。当然如果有需要，尽管问我。
Farhana:在那些设计原则之上我听说过很多设计模式。
Shubho:对的。设计模式只是对一些经常出现的场景的一些通用设计建议。这些灵感主要来自于面向对象原则。你可以把设计模式看作"框架",把OOD原则看作"规范".
Farhana:那么接下去我将学习设计模式吗？
Shubho:是的，亲爱的。
Farhana:那会很有意思，对吗？
Shubho:是，那确实令人兴奋。
-------------------------------------------------------------------------------------------------------------------
声明:
本文版权归作者共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文出处，连接，作者，否则保留追究法律责任的权利。

本文链接

我的工作习惯小结

2010-11-03T00:42:00Z

最近有人向我询问如何学习，工作的问题，思前想后，觉得习惯最重要，于是就想到整理一下自己的学习工作习惯。本人工作比较随便，谈不上章法，就随便列举一些。

5，强大小工具：计算器，画图，记事本...

6，帮助别人，向他人学习

7，贪多嚼不烂

8，总结

1，正常的作息时间

个人觉得这点最重要，所以就放在了第一项。也许是年龄增大的缘故，现在根本熬夜不得。现在每天光顾博客园，发现有些人很晚的时候还在发贴，回帖，仿佛不知疲倦。在此衷心劝告一句：莫要透支身体！养成良好的作息规律是人生一大事，毕竟身体健康最重要，其他诸如事业，名利都是浮云！不是说人生最大的悲剧不是没钱花，而是有钱没命花么？！

本人现在每天晚上10：00(以往12：00)左右休息，早上7：30(以往8：30)起床，加班之事少有。

2，工作便条

在公司总是事情很多，大事小事每天有十几件很正常，可惜记性不太好，如果不记下来，总会忘这忘那。所以除非遇到的是马上要处理的事，否则必然记下来，方式随便：碎纸片，记事本，札记等等，但要放在显眼的地方。

3，日志

学习的方法很多，其中最好的方法之一莫过于带着问题去学习，但问题解决了要记得把他记下来。初学者，或者比较笨拙的人(比如我自己)尤其应该这么做，目的是为了温故而知新。这样子可以在以后有时间的时候拿出来翻翻，由于是自己不会的东西，所以看起来很快；也正因为是自己不会的东西，看过之后就避免在犯同样的错误或问同样的问题。个人能力也正是在这点滴见积累起来的。个人在工作的时候，尤其是项目发布初期，总是会在一个地方记下该项目自发布运行时期遇到的所有问题，一则避免再犯，二则可以完善思路。

很多新人刚开始总是问很多问题，有时候没人搭理自己就会觉得很委屈，其实是自己懒，经常问同样的问题才让人烦，所以要谨记这点。好记性不如赖笔头正是如此。

4，使用好办公软件

上面说了几项，总结为一句话就是要记东西，这里就以此举例——使用好OutLook。个人觉得工作中有OutLook就足够了，完全用不着别的软件。OutLook提供了邮件，便条，任务，日历等多种功能，即实用又方便，何乐而不为呢？！本人目前OutLook里邮件自动分了N类，任务列表天天有亮有灰，每天早上上班，从来不用为今天干嘛而发愁，因为9：30有自动提醒。

当然，如果你用别的办公软件也行，总之公司有的要用起来，没有的就弄个D版的用起来。

5，强大的小工具：计算器，画图，记事本...

也许你看到上面的名字觉得有点逗，其实很实在。本人电脑任务栏上必然有这些工具，随点随用，不亦乐乎。相信工作几年的人应该有此体会，刚入行的以后慢慢就知道了。

以画图举例，说到截图，也许你会说Snagit，它是强大，但点来点去麻烦的很，还倒不如直接PrintScreen+Ctrl+V方便——平时又不需要去演示，谁需要截的那么细致啊。

还有个记事本，就强大了，有心情的时候完全可以用记事本写代码假装高人，Word是很强大，但能写代码么？嘿嘿。平时灵光一闪有个绝好的点子，用记事本记下就记下来，不会丢掉；换做其他，恐怕工具还没打开，点子没了，郁闷就来了。

6，帮助别人，向他人学习

向他人学习，很多人都能做的到，实际未必。事实上如果你面前有个牛人，好学的你自然会向他请教学习，这只能算是好学的一小部分。因为跟你差不多的和比你差的总是占大部分。

俗话说：“三个臭皮匠，顶个诸葛亮”，并不是说三个臭皮匠加起来就真的比诸葛亮厉害，而是说每个人都有可取之处，世上没有十全十美的人。就算你是公司的首席架构师又如何，总有你不会的东西。所以遇到跟你差不多的人，尤其是有些微妙的竞争关系的人，不要不服，一定虚心向人学习，这样子有可能你学到了他会的，而他没有学到你会的，结果你就真的超过了他。

通常帮助别人时你一定在某一方面比别人强，这时也许你感觉很舒服，那人也很感激你。这时你要注意多些赠品，比如帮他检视代码啊，指出不足啊，最后一定发掘他的优点，顺便看看自己有没有。这样子既帮了别人，又帮了自己，只有自己知道是双赢并窃喜，结束时还可以故作大方地说“不客气”或者“不用找零了”！

7，贪多嚼不烂

上次有个新人说他现在要学习HTML+CSS+JavaScript+Asp.NET+C#+SQLServer，感觉学不过来，问我该怎么办。我说丢掉几个，他说学了一些，丢掉觉得可惜，又说有人给他的工作就需要这些，我还说丢掉大部分，主学一个，辅学另一个做调节，其他当兴趣；如果有人催，就说自己不会。最后他又说他问了好几个工作过的人，答案都这样。我说这就对了，贪多嚼不烂，听我们的，没有错。

很多人经常会接触的很多东西，好奇心促使他什么都想学，他就同时什么都学，结果什么也学不会。人的精力毕竟有限，所以同时只能学习一门技术，能力好的可以学两门。其实，以我自己的经验来看，如果学精了一门，与之类似的技术，就算你根本都没接触过，你也可以声称自己精通它。这不是吹牛，所谓万变不离其踪。对于一门基础，只知万变顶多算入门；知其踪就可算精通了。然后遇到大同小异的东西，知其根难道还怕不知其表么？！

举个例子，C#与Java之争由来已久，每次都口水漫天，这只能说大多数人都很水。真正懂C#或Java的人不会互喷（因为他都懂了，虽然他可能没用过C#或Java）——你见过C#或Java之父相互口水的么？！

8，总结

好了，今天就到这里。如果你觉得有什么不妥的地方，请你多多指正。

本文链接

WPF之路——WPF布局系统

2010-10-31T14:04:00Z

前言

前段时间忙了一阵子Google Earth，这周又忙了一阵子架构师论文开题报告，现在终于有时间继续<WPF之路>了。先回忆一下上篇的内容，在《从HelloWorld到WPF World》中，我们对WPF有了个大概的了解，并了解了初学WPF时应该从哪些知识点入手。今天我们就从最基本的知识点之一布局系统来继续学习WPF，主要包括如下内容。

4，基本属性：Alignment,Margin和Pading

5，附加属性

6，布局与性能

7，总结

0，什么是布局

这是一个很简单的问题。简单来说，就是把一些控件有条理的摆放在界面上合适的位置，显然摆的乱七八糟不能算布局。在WPF中，这个条理与WinForm中略有不同，让我们看个很简单的界面：

这样子的界面大家在熟悉不过了。依图所示，WPF先用蓝线（假设的线）将界面划分为上下两部分，然后再有红线划分出多个方格，最后放入控件，其中每部分中的控件或划分的空格只能纵向排列，或横向排列，不能有其他选择。大多数情况下，WPF程序界面上的控件都要按照此种递归的方法逐个排列，最终形成所看到的界面。

1，基本元素——面板

在上节中我们了解了WPF布局原理，这可以简单理解为大控件中按排或列放入小控件，小控件在按照同样规则放入更小控件。这种能放入其他控件的控件是WPF布局系统中的基本元素——面板。面板是用来放东西的，既包括控件元素，也包括面板自己。面板不仅能承载其他子元素(控件)，还能控制子元素的大小，位置以及如何排列。例如上述例子中，蓝线划分的面板控制子元素只能上下排列，而红线划分的面板控制的子元素只能横向排列。

WPF默认提供了几种面板都是从基面板(Panel)继承而来，看一下它们的继承链。

     System.Windows.Threading.DispatcherObject
        System.Windows.DependencyObject
          System.Windows.Media.Visual
            System.Windows.UIElement
              System.Windows.FrameworkElement

                System.Windows.Controls.Control
                System.Windows.Controls.Panel
                  System.Windows.Controls.Canvas
                  System.Windows.Controls.DockPanel
                  System.Windows.Controls.Grid
                  System.Windows.Controls.StackPanel
                  System.Windows.Controls.VirtualizingPanel
                  System.Windows.Controls.WrapPanel

2，常用容器控件

WPF默认提供了数种布局控件，常用的包括如下几种：

名称	用法	说明
Canvas		此面板可承载任意元素，包括控件，图形，甚至文字。各种元素依据屏幕坐标确定位置。
DockPanel		此面板可指定元素的排列停靠方式，每个子元素的排列方式可以不同。
Grid		此面板使子元素按照纵横网格排列。
StackPanel		此面板使子元素按照水平或垂直方向排列，两个方向只能选其一。
VirtualizingStackPanel		与StackPanel相同，不同之处在于它可以使内容虚拟化。
WrapPanel		使子元素按照水平或垂直方向排列，在行或列处换行或列，依旧按照水平或垂直方向从左到右或从上到下排列。

3，测量与排列

当我们在面板上放入子元素，并设置相应的属性时，WPF的布局系统自动为我们完成2个过程：测量和排列，这是两个非常重要的过程。

由于WPF界面元素有很多与布局有关的属性，如坐标，大小，对齐方式，相对位置，间距等。首先这些属性使用的是与设备无关的分辨率单元，这导致同样大小的元素在不同界面上显示的效果可能不同；其次每个属性值有一定的优先级，例如Button的Height和Width属性优先于Stretch属性，如果设置 Height, Width 以及 Stretch，会导致 Stretch被忽略。

因此，尽管在设计时指定了属性值，布局系统依然需要重新计算每个子元素在界面上的实际大小，位置，边距等值，这些值被称为“FinalSize”。

4，基本属性：Alignment,Margin和Pading

在设计UI时，WPF为我们提供了一些属性用于精确定位元素，其中最常用的有三个：Alignment(包括水平，垂直)，Margin，Pading，具体用法如下：

名称	说明
Alignment	子元素在水平(垂直)方向的对齐方式，有左对齐，右对齐（顶端对齐，底部对齐），中间对齐，拉伸填充等四种方式。
Margin	用于指定元素与其子级或同级之间的距离，包括上下左右四个值。也可通过使用 Margin="20" 同时指定四个值。
Pading	Padding 在大多数方面类似于 Margin，只有少数元素有（公开），用于将子元素的有效大小增大指定的厚度。

5，附加属性

通过上面我们了解到子元素通过一些属性值的设置实现在面板上布局，比如Alignment对齐属性，Dock停靠排列属性。这些属性不属于子元素本身，而依赖与所在的父元素。比如同样是Button，在DockPanel中有Dock属性，而在Grid中就没有。这些属性的存在依赖与父元素，在WPF中称做“附加属性”。

附加属性的用途是允许不同的子元素为实际在父元素中定义的属性指定唯一值，目的是让子元素通知父元素它将如何在界面中呈现。如上面提到的DockPanel.Dock 属性，因为它将在 DockPanel 中包含的元素上设置，而不是在 DockPanel 本身设置。注意，相对于子元素，父元素提供的附加属性相当于全局属性。

6，布局与性能

通过上面我们了解到，当给界面元素的布局属性赋值时，布局系统需要重新计算和排列所有子元素的“FinalSize”(因为改变影响不可知)。这是一个递归的过程。如果不注意，可能会带来性能问题。因此在设计时应注意下面几点：

1，应注意哪些属性值更改会引起执行布局系统的递归更新；

2，如有可能，应使用 RenderTransform 而不要使用 LayoutTransform；

3，避免不必要地调用 UpdateLayout，因为UpdateLayout强制调用布局系统的递归更新；

4，当包含大量元素集合时，请使用 VirtualizingStackPanel虚拟化元素；

7，总结

通过本文，我们大概了解了WPF的布局系统，常用的布局面板，与布局有关的几个属性，以及设计开发UI时的注意事项。这些内容很多与WinForm中的相关概念相通，可以说是旧瓶装新酒，稍加思考，并不难理解；如果深入了解，会发现与WinForm截然不同。但作为初学者，如果能灵活使用文中所讲的知识点，深入理解注意点，对自身的提高还是很有帮助的。

本文链接

由感而发：离职的第四个理由

2010-10-18T14:06:00Z

今天看到园子里周金根的《个人管理：程序员应不应该离职，我该何去何从呢？》一文，读完之后就想写出自己的观点——个人离职的第四个理由——挑战与经历！

周兄能在一家公司工作十年，这种经历想来不多，我自问自己做不到。而周兄给出了三个离职理由(职业方向，环境氛围，工资奖金)也很恰当，在赋以充分的说明，更引起了大家的共鸣。然而人生就是如此吗？！

我相信人与人的不同，也喜欢脚踏实地的做事，但让我数十年做同一种工作，我肯定做不到，不是没有那份耐心，而是希望有更多的挑战，有更多的经历，有更广阔的视野。所以适当的时候，我会离职。

自毕业到现在的第三份工作，没份工作都在一个全新的行业，做着完全不同的事，而在每次离职前，自问不会留下任何遗憾。

也许工作N年的人更容易与周兄产生共鸣，也许刚毕业或还没有工作的人更容易与我一拍而合。原因想来很简单，数年社会的洗礼早以洗静了大家原有的多姿多彩；成家后的生活琐事不知不觉间磨平了原有的棱角；日常的柴米油盐让你需要为锱铢忙碌；而这些离刚毕业或没毕业的人尚有一段距离，所以他们还有那份火热的朝气。

但你有这样想过吗？当数十年过后，也许你成为了行业内的专家，也许你成为了劳模，可除了这些你还会什么呢？！这是你的一技之长，能满足你的生活物质需要，精神上的呢？作为程序员，只懂得代码，并且很精通，这听起来很正常，可有没有想过在自己的01010011世界中加入“明月几时有，把酒问青天”或者“噫吁嚱，危乎高哉！蜀道之难，难于上青天！”！

也许你我注定是凡人，成就不了轰轰烈烈的事业，但至少不能困顿于柴米油盐。外面的世界很精彩，何必做那一方井底之蛙。

况且，人生的哲学是通过不断地磨练才能练成的。终有一天你会无力工作，然而人生经历淬炼出的智慧则越久越显得光芒四射。中国有句古话：“家有一老，如有一宝”，但生活中更多的是倚老卖老的“遭老头”或者“老不死的”，你想成为那者呢？至少我会努力成为“一宝”。而想成为“一宝”，需要有大智慧，这些智慧及来自于先天，更来自于不断跳战的人生。相信长久蜗居一方的人很难知道什么是海阔天空。纵然你数十年成就一方专家，最终也难免是“河伯之于海若”。

然人与人之不同在于天性，不可一概而论，只要不被岁月磨平原有的天性，都是值得庆贺的。

脑中响起那首《海阔天空》，始终坚持梦想，永远敢于跳战新的目标!!

注：1，“噫吁嚱，危乎高哉！蜀道之难，难于上青天！”见《李白。蜀道难》；

2，“河伯，海若”见《庄子。秋水》；

---------------------------------------------------------------------------------------------------------------------------------------

后补1——“对我来说，离职的最大的理由是可以和家人在一起.”

人生最重要最切实的莫过于家人，我也会为此做出选择！

后补2——"钱钱钱，钱钱钱"

挑战与经历 Vs 钱

首先二者矛盾吗？不！偏安一隅，顶多是一方霸主；开阔天空则有整个天下！多年稳守一职与挑战更多领域与此雷同；

其次钱虽重要，切莫本末倒置，被它驱使，不然一样得不到钱；

本文链接

WPF之路——从HelloWorld到WPF World

2010-10-17T13:54:00Z

前言

有人说到，学习任何一种编程最困难的部分是“Hello World”。这一看似乎很可笑，仔细想来却未必。平时很多我们自认为很简单的东西也许恰恰是最困难的东西，比如C#中的一些基本概念，我们天天都在用，可你真的都理解他们吗？！对很多人来说恐怕要打个问号了。

最近开始学习使用WPF，WPF是什么？网上有很多文章，在此就不赘述了。

一切还是从“Hello World”开始，然而因为有了上面的经历，一切真的都变得不同了。

Hello World

如题，在优秀的IDE环境中，做一个简单的Hello World应用程序是如此的简单，仅仅用鼠标拖一个控件，在属性栏中输入“Hello World”，然后F5，OK，一切都完成了。

这一切真的太简单了，就跟当年学习VB或C#一样，看起来没有任何不同，然而现在你还会说VB的Hello World与C#的Hello World是一回事么？！答案很显然。

什么是Hello World

有个笑话讲到，一个退休的程序员，退休后练习书法，提笔一挥，纸上赫然出现一行字——Hello World。第一个写“Hello World”的人也许是个天才。一粒沙中看世界，这个简单到一行代码甚至没有代码就能实现的程序向初学编程的人打开了一道便捷之门，给初学者足够的空间去思考有限的问题，一窥其后万千变化的世界。

Hello World有什么

Shift+F5，停止程序运行，让我们一起看看这个程序中有什么。先看文件结构：

在解决方案资源管理器中，我们不难发现与WinForm相比，WPF程序多出了一种文件Xaml。先打开我们熟知的.cs代码文件，发现里面空无一物，甚至看不到承载Hello World的控件，结合Asp.Net的经验，我们在Xaml中发现了

    <Grid>
        <TextBlock Text="Hello World" />
    </Grid>

由此我们可以认为微软通过结合Asp.Net与WinForm的优点打造了全新的，而相比二者，WPF最核心的部分便是Xaml。

发现Xaml

那么什么是Xaml呢？MSDN中解释到：可扩展应用程序标记语言 (XAML) 是声明性应用程序编程标记语言，WPF提供对可扩展应用程序标记语言 (XAML) 语言支持，使WPF得以实现，这个解释有点抽象。事实上，如果有Asp.Net基础，我们则可以简单的认为WPF是以Asp.Net方式开发WinForm；如果有标记语言的基础，则可以简单认为Xmal以标记语言的方式实现WPF中的UI，然后由微软把UI和代码联系起来；如果什么都没有，那就把看到的网页关了，好好学习吧^_^。

开启WPF World

元素树

我们知道，WPF的核心是Xaml。Xaml想做网页一样，将UI分割为不同大小的块，以一定方式组合，便成了我们看到UI基本框架，然后在通过美工的合作，成为最终呈现在我们面前的用户交互界面。Xaml中的每种元素代表UI上的一个基本元素，那么Xaml是以何种方式组织这些元素，并最终构成向用户交付的UI呢？看下图。

如图所示，WPF以有序的方式按树形结构组合每个界面元素。界面中每个元素都有唯一的父节点，并可能有多个子节点。图中第3部分就是Hello World示例的树结构示意图。当然，WPF文档结构远比例子中复杂的多，不过作为入门，这些不在今天的讨论范围呢。

基元素

现在改动一下程序，我们添加一个按钮，点击该按钮，显示一个消息框。

在上面我们了解到WPF中Xaml负责UI，cs负责实现逻辑(显示消息框)。那么它们是如何关联起来的呢(请注意图中蓝线)？原来在WPF中，凡是与UI元素类均从一个基元素继承—— DependencyObject而来，这些类分别在cs和xaml中有相同签名的实现。我们在开发过程中只需要取相同的名字，WPF会自动替我们完成关联工作。

注意：如果在C#代码中将button1_Click改为OnBtnClick，Xaml中不会自动改

属性

现在仔细观察一下IDE自动生成的代码，如果Asp或HtmlXml一样，我们会发现每个元素标签，除了标签名外都包含一些属性。除了在C#中我们熟知的Text="Hello World"，Name="button1"外还包含Asp.NET中常见的Margin属性(用于说明Button在父容器中与其他元素的间隔距离)。前者与C#中的属相相同，后者则不属于对象本身，依赖于父元素，在WPF中成为附加属性(比如，如果Button不在一个父元素(Grid)中，那么它与其他元素就无所谓相对距离了)。

在上小节中，我们知道WPF负责将Xaml元素与C#中的类一一对应起来，在Xmal中改变Button.Height的值时，cs中同样会做相应的改动，那么它们是如何实现的呢？原来WPF提供了一套属性系统，该系统提供一种方法来基于其他输入的值计算属性值。有了这套系统，我们在Xmal与cs之间访问属性时WPF会自动通知彼此，支持这些服务的属性通常称为依赖属性。

样式和模板

想象一下我们继续修改Hello World程序，如果需要添加10个或100个相同Button，这些Button针对不同的用户有不同的样式。那么我们该如何支持这些样式呢？是在xmal中一个一个的写吗？当然不可能。既然Xaml类似于Asp.Net，那么我们不难想到网页中常用的CSS，在WPF中同样有属于Xaml的Css，并且更强大，那就是样式和模板。

WPF样式设置和模板提供了一套功能（样式、模板、触发器和演示图板），让我们能够使用这些功能创建更好的视觉效果，也可以为创建统一外观，并且能够在应用程序内部和应用程序之间共享这些样式和模板，从而提供工作效率。

资源

在上小节中，我们提到了样式和模板，这些在WPF中属于资源。除此之外，WPF中的资源也包括C#中我们通常理解的文件，多媒体，数据等。只是在WPF中资源可分为静态资源和动态资源。从名字上很好理解它们的区别，一个性能好点，一个更灵活。做为入门，在使用时，是否需要实时更新资源可作为我们选择静态资源和动态资源的依据。

总结

学到了什么

通过上面一系列描述，我们发现了WPF中的一些基本概念：Xaml，元素树，基元素，属性，样式和模板，资源。这些都是初学WPF时最早接触到的内容。因篇幅所限，只能对这些内容做一个大概的介绍，使得我们能够从中一窥WPF的样貌。但做为初学者，充分理解把握这些内容是进一步学好WPF的关键。

如何学习

在上面的学习过程中，我们不难发现，学习任何一门技术都要从最简单的地方开始，然后通过仔细观察，发现问题，思考问题，并最终解决问题。其中最重要的是要勤于思考，而不是浮于表面。

下一步该做什么

今天我们从整体上对WPF有个粗略的了解，并发现了一些基本概念。虽然还有很多重要的内容如数据绑定，事件路由，线程模型等没有涉及到，但是本着贪多嚼不烂的原则，下一步我们应该对今天所涉及到的每个概念做深入的学习，然后经过反复的联系，最终能真正了解它们。

本文链接

.NET中的设计模式——一步步发现装饰模式

2010-10-10T14:24:00Z

前言

过去我的一个朋友常说，学习任何编程语言最困难的部分是运行“Hello World”，之后一切都很容易。多年以后，我才意识到他说的很对。学习设计模式的基本目标是要用它，尤其是帮助那些有扎实的OOP基础，而对设计模式很困惑的人在设计中应用它。我不会为不同设计模式写很全面的参考，但我希望这些文章能让你入门。设计模式与特定的语言无关。虽然我用C#写了很多示例，但我尽量避免一些C#特有的结构，因此它面向大部分人，尤其是使用C++的人。

装饰器模式允许我们动态为对象添加行为。下面我们先介绍一个场景，然后寻找替代方法。这会帮助我们认清该模式的真实用途，尤其在灵活性这方面。

思考过程

今天我们参考的不是一个实际的场景，有时可能会很奇怪，但它会帮助我们弄清这个模式及相关概念。我们的目标是添加将不同来源的信息存储到磁盘文件上的功能。所以，第一步我们定义一个接口，并实现它。IMessageWriter和IMessageReader接口分别用于写入和读取信息，他们的实现如下：

interface IMessageWriter {
string Message { set; }
void WriteMessage(string filePath);
}
class MessageWriter : IMessageWriter {
private string message;
public string Message { set{message =value;} }
public virtual void WriteMessage(string filePath) {
File.WriteAllText(filePath, message);
}
}
interface IMessageReader {
string ReadMessage(string filePath);
}
class MessageReader : IMessageReader {
public virtual string ReadMessage(string filePath) {
if (File.Exists(filePath))
return File.ReadAllText(filePath);
return null;
}
}

信息作为Message属性存储，MessageWriter的方法WriteMessage把它写到指定的文件。同样，MessageReader的方法ReadMessage从指定的文件读取，并以字符串的形式返回。现在假设客户提出了新需求。

对某些信息在读和写文件之前，我们需要验证用户；
对某些信息我们希望加密后保存，来防止别人读取，并且我们需要以64位编码保存加密信息；
对某些信息，我们都需要这些功能；

很奇怪吧，呵呵，首先我们不用装饰器分析不同的解决方案，这会使我们对这个简单的设计模式认识更加清晰。

传统解决方案

你决定在原来行为上使用继承。你从MessageWriter继承EncryptedMessageWriter来实现加密行为。

class EncryptedMessageWriter : MessageWriter {
public override void WriteMessage(string filePath) {
//加密消息
//转换到64位编码
Message = "base64StringYouGotFromAboveCode";//存储信息
base.WriteMessage(filePath);
}
}

同样，你从EncrytedMessageWriter继承SecureMessageWriter来实现用户验证。

class SecureMessageWriter : EncryptedMessageWriter {
public override void WriteMessage(string filePath) {
if (ValidateUser())
base.WriteMessage(filePath);
else
Console.WriteLine("No message saved,user validation failed.");
}
private bool ValidateUser() {
//验证用户,失败返回false
return true;
}
}

现在我们能写入加密的信息，或经过用户验证后的加密信息。那么如果需要写入一些只需要用户验证而不需要加密的简单文本信息时，我们该怎么办？你可以在EncryptedMessageWriter中写入一些丑陋的判断，在不需要加密的时候跳过加密。假设遇到此类情况你还这么做，那么那些操作换个顺序呢，例如我们想先加密后验证，如果验证失败，则除64位编码加密消息外在做点别的。很显然，上面的组织结构无法处理这种情况。谁能阻止用户提出更多的需求，像消息需要数据签名，大消息需要压缩或不需要加密，对于某些信息，写到磁盘后，你必须在消息队列中输入文件路径和时间戳以便其他程序读取，甚至写到数据库中，等等等等？！显然不能。

让我们只关注验证，忽略其他细节，评估一下你面对情况的复杂性和严重性。目前，我们在加密消息时实现了用户验证。现在我们需要满足其他相同的功能，如：CompressedMessageWriter,DigitallySignedMessageWriter等。你唯一能做的是实现SecureCompressedMessageWriter,SecureDigitallySignedMessageWriter等。同样对其他大量的组合，像压缩加密信息，简单信息压缩等等。天哪，你真的坠入“子类地狱”了。

第二个解决方案是写一个非常大的MessageReader，处理所有提到的需求功能。随着时间流逝，它变得越来越复杂，越来越难以维护——非常不推荐这样。

第三个解决方案可能是上面两种方案的合并，这可能是治标不治本。

引入装饰器模式

这恰恰是装饰器模式解决的问题。如果你仔细观察上面采用继承的解决方案，你会认识到问题的根源是继承带来的静态关联。这些关联被嵌入到类之间，并且不能在运行时改变。装饰器用包含替换关联，而包含是一种非常灵活且在运行时能被更新的对象关联。

首先让我们看看装饰器模式究竟是什么。下面是装饰器模式的类图。

四个参与者:

Component:定义一个对象接口，可以动态的给对象添加职责. 在我们的例子中是IMessageWriter和IMessageReader；
ConcreteComponent: 定一个实现Component接口的对象。这个对象会被装饰，但它不会包含任何装饰者的信息，而装饰者不会访问它的实现。在我们例子中是MessageWriter和MessageReader。
Decorator: 包含一个Component对象的引用，定义一个与Component一致的接口。所以它包含一个指向基本行为的引用，并且实现了相同的接口，因此能被Component自己访问。客户端代码期望Component能不需要关心装饰者之间的差别处理它们。
ConcreteDecorator: 它向Component添加职责。从Decorator继承来的类可以统一添加新方法的形式添加一些额外的功能。

到目前为止，我们已有两部分，分别是Component：基本行为，即在我们例子中是IMessageWriter和用于读的IMessageReader；和ConcreteComponent，即我们实现的读写行为：MessageWriter和MessageReader。

下面是我们实现的SecureMessageWriter和EncryptedMessageWriter。

class SecureMessageWriter : IMessageWriter {
private string message;
//被装饰者
private IMessageWriter messageWriter;
public SecureMessageWriter(IMessageWriter msgWriter) {
this.messageWriter = msgWriter;
}
public string Message {
set { message = value; }
}
public void WriteMessage(string filePath) {
if (this.ValidateUser()) {//添加新的行为
//正如你所见,在调用被装饰者的标准方法前我们添加了验证行为
messageWriter.Message = this.message;
messageWriter.WriteMessage(filePath);
}
else
Console.WriteLine("");
}
private bool ValidateUser() {
//验证用户代码
return true;
}
}
class EncryptedMessageWriter : IMessageWriter {
private string message;
//被装饰者
private IMessageWriter msgWriter;
public EncryptedMessageWriter(IMessageWriter msgWriter) {
this.msgWriter = msgWriter;
}
public string Message {
set { message = value; }
}
public void WriteMessage(string filePath) {
this.msgWriter.Message = "encrytedMsgInBase64";//加密信息
//被装饰得行为
this.msgWriter.WriteMessage(filePath);
}
private string GetPassword() {
Console.WriteLine("Please provide security password");
return Console.ReadLine();
}
}

这里有问题吗?????

我刚刚说这个模式有四个参与者，我已向你展示了Component(IMessageReader，IMessageWriter)，ConcreteComponent(MessageReader,MessageWriter)和ConcreteDecorator(SecureMessageWriter，EncryptedMessageWriter)。但Decorator那里去了？在我们的例子中，我们仅仅添加了已存在的行为，没有引进新的行为。我们没有改变其他结构。在这种情况下，我们忽略了实现Decorator，并沿用主要层次结构。这里我不在展示读有关的类，它们仅仅是反向处理。

我们学到了什么

现在如果我需要一个经过用户验证的简单信息写操作，我会这么做：

IMessageWriter msgWriter = new SecureMessageWriter(new MessageWriter());

我用SecureMessageWriter装饰了MessageWriter，它现在在写信息到磁盘前会先验证用户。如果同时需要验证用户和加密信息，我会这么做：

IMessageWriter msgWriter = new SecureMessageWriter(new EncryptionMessageWriter(new MessageWriter()));

装饰器使我们在大多数情况下避免构造复杂基类，撰写大量的代码。
装饰器允许我们以不同的顺序进行不同的组合，这在别的方法来说不太容易。
相比为不同的行为与合并实现不同的基类，我们可以按需实现单独的需求行为。

回到现实

这一部分我们会看到装饰器模式在实际中应用的例子。

同步包

善于使用.ET中旧集合类，如Queue，ArrayList等的人可能还记得许多类提供的(集合)同步函数。它把集合实例自己作为参数传入，并返回一个同步集合。尽管集合类自己并不同步，但这个方法返回的实际上是从集合类自己继承过来的一个装饰器。例如，在下面代码中当我们调用Syncrhonized(a1)时，我们会收到一个从ArrayList继承来的SyncArrayList的实例。

ArrayList al = new ArrayList();
al = ArrayList.Synchronized(al);

SyncArrayList存储通过属性_list传递的ArrayList，并且按照同样的方法重载不同的实例方法。

public override int Add(object value) {
lock (this._root){
return this._list.Add(value);
}
}

注意事项

按照此法创建同步包时，要注意叫做“自死锁”现象，这意味着一个占有锁的线程进入另一格方法(或者递归)，然后又试图获取同一个对象的锁。在Windows中，如果你使用.NET实施监控，或者内核级命名，或者无名互斥，全部都有重入机制(即递归)。所以你不会遇到此类问题，但是在其他环境(如Linux)中编程时,默认互斥类型是快速互斥（一种非递归互斥），你的代码就可能成为“自死锁”的受害者。假如使用消息，即使在Windows上，它一样没有自我意识，如果你不注意，就会给你带来这个问题。当然，对于一个简单信号，比如n=1，在第二次访问时，你一样会遇到“自死锁”。

同理，你可以为你的集合类实现一个只读包。不像我们到现在所看到的，与其说他们是向类上添加功能，倒不如说去掉一些。例如在重载方法Add()中可能抛出操作不支持的异常。.NET提供了ReadOnlyCollection<T>，它用于包装泛型列表。Java则提供了只读包，如UnmodifiableCollection,UnmodifiableSet等等。
Java中，你可以按照下面方式为很多集合类型获取同步包。

List list = Collections.synchronizedList(new ArrayList());

Java和.NET中的IO

Java的java.io包和.NET的Stream类都使用了该模式。我不会就它们的实现谈论很多细节。.NET中，Stream是一个抽象类，提供了基本的行为(如Component)，从抽象类Stream继承来的类FileStream,MemoryStream是ConcreteCompents，类BufferedStream,CrytoStream等是ConcreteDecorators。你能清楚地认识到它们同样忽略了Decorator。

同样，在Java中，BufferedReader和FilterReader是Reader的装饰者。而BufferedReader进一步被LineNumberReader装饰。FilterReader被PushbackReader装饰。

收获了什么

装饰器模式允许我们在实现中提供扩展点。你可能注意到，在实现装饰者时，我从来没有涉及到Component类。因此，即使它并不拥有类，一样能通过动态添加行为类装饰它，甚至是递归的方式。这些额外的行为可能在几处行为之前或之后添加，或者这种行为可能被阻止。装饰者能在类中提供新方法，甚至新属性。但装饰器同样有一些问题。

使用装饰器的程序员必须明白它们的意图，否则他最终可能会使用一些毫无意义的组合或序列。比如在我们的场景中，如果程序员按照这种方式定义序列：信息先被压缩，然后加密，最后验证，它将毫无意义。在现实场景中，有些组合或次序可能是灾难性的。
测试一个装饰类需要提供一个模拟的被装饰类。因为我们还没有涉及到测试，所以这里就不说了。
该模式在基本行为上添加一些职责。虽然给装饰者添加新的属性或方法完全合法，但这种方法导致基础类处理问题的灵活性，因为你需要用到具体的实例。

写在最后

此文为CodeProject上同名文章<Decorator Pattern(A Layman to Laymen)>的意译和修改，文中部分内容与原文有出入。文章通过循序渐进的方式逐步暴露问题(各种继承，子类，代码像麻花一样挤在一起)，然后用装饰模式解决(把每种需求单独构建成组件，然后像搭积木一样完成工作)，最后联系实际说明装饰模式的真正含义，使得整篇文章有理有据，内容清晰易懂，相信对学习什么模式的人有很大帮助。限于个人能力，文中难免有错误的地方，还请大家多多指教（特别是斜体部分:(）。

本文参考：《设计模式可复用面向对象软件的基础》

　《Decorator Pattern(A Layman to Laymen)》

　《.NET与设计模式》

《MSDN》

本文链接

C#中的委托,匿名方法和Lambda表达式

2010-10-07T14:06:00Z

简介

在.NET中，委托，匿名方法和Lambda表达式很容易发生混淆。我想下面的代码能证实这点。下面哪一个First会被编译？哪一个会返回我们需要的结果？即Customer.ID=5.答案是6个First不仅被编译，并都获得正确答案，且他们的结果一样。如果你对此感到困惑，那么请继续看这篇文章。

class Customer
{
public int ID { get; set; }
public static bool Test(Customer x)
{
return x.ID == 5;
}
}
...
List<Customer> custs = new List<Customer>();
custs.Add(new Customer() { ID = 1 });
custs.Add(new Customer() { ID = 5 });

custs.First(new Func<Customer, bool>(delegate(Customer x) { return x.ID == 5; }));
custs.First(new Func<Customer, bool>((Customer x) => x.ID == 5));
custs.First(delegate(Customer x) { return x.ID == 5; });
custs.First((Customer x) => x.ID == 5);
custs.First(x => x.ID == 5);
custs.First(Customer.Test);

什么是委托？

现在你定义一个处理用户订单的购物车ShoppingCart类。管理层决定根据数量，价格等给客人折扣。做为其中的一部分，他们已经实现了处理订单时你要考虑一方面。不用考虑过多，你简单声明一个变量来保存有“吸引力的折扣”(magicDisCount)，然后实现逻辑。

class Program {
static void Main(string[] args) {
new ShoppingCart().Process();
}
}
class ShoppingCart {
public void Process() {
int magicDiscount = 5;
// ...
}
}

第二天，异想天开的管理层决定根据购买时间调整折扣。这个很简单，但需要你改动一点代码。

class ShoppingCart {
public void Process() {
int magicDiscount = 5;
if (DateTime.Now.Hour < 12) {
magicDiscount = 10;
}
}
}

接下来一段时间里，管理层又反复添加更多的折扣逻辑。这时你就会在心理抱怨“受够了”。那么我该怎么做才能把这些无聊的逻辑从我的代码中剥离出去，让该处理的人去处理呢？这时你要做的是移交或者委派给相应职能的别人。幸运的是，.NET为此提供了一种叫做“委托”的机制。

委托

如果你有C/C++编程背景，描述委托最好的方法是“函数指针”。对所有人来说，可以认为把委托传递给方法与把值或对象传递给方法一样。比如下面三行代码就表现出一样的基本原则：你在传递数据给Process处理而不是你自己使用。

// 给方法Process传递一个整形值
Process( 5 );
// 给方法Process传递一个ArrayList的引用
Process( new ArrayList() );
// 给方法Process传递一个方法的引用
Process( discountDelegate );

DiscountDelegate是什么？我如何创建？Process方法如何使用？首先如同声明一个类一样，声明一个委托类型。

delegate int DiscountDelegate();

这句话的意思是我们有一个叫DiscountDelegate的委托类型，我们可以像使用类，结构体等一样使用它。它不需要数据参数，但返回一个整数值。像类一样，我们必须创建一个它的实例它才有意义。记住，创建一个委托实例实质上是创建一个方法的引用。创建实例时关键是要明白DiscountDelegate没有任何构造器，它有一个隐式的构造函数来构造一个与它相同签名的方法(没有传入参数，返回一个整数)。那你怎么给这个构造函数一个方法呢？.NET向你提供了一个向它名字一样简单的方法，你所做的只是忽略圆括号。

DiscountDelegate discount = new DiscountDelegate(class.method);

在深入之前，先回到开始的例子，整理一个代码。我们会添加一个Calculator类来帮助我们处理折扣逻辑，并给我们的委托提供一些方法。

delegate int DiscountDelegate(); 
 
class Program { 
    static void Main(string[] args) { 
        Calculator calc = new Calculator(); 
        DiscountDelegate discount = null; 
        if (DateTime.Now.Hour < 12) { 
            discount = new DiscountDelegate(calc.Morning); 
        } 
        else if (DateTime.Now.Hour < 20) { 
            discount = new DiscountDelegate(calc.Afternoon); 
        } 
        else { 
            discount = new DiscountDelegate(calc.Night); 
        } 
        new ShoppingCart().Process(discount); 
    } 
}  
class Calculator { 
    public int Morning() { 
        return 5; 
    } 
    public int Afternoon() { 
        return 10; 
    } 
    public int Night() { 
        return 15; 
    } 
}  
class ShoppingCart { 
    public void Process(DiscountDelegate discount) { 
        int magicDiscount = discount(); 
        // ... 
    } 
}

正如你所见，在Calculator类中，我们为每个逻辑分支创建了一个方法。在Main方法中，我们创建一个Calculator实例和一个DiscountDelegate实例，并按照我们所期望的把它们整合在一起。

太棒了，我们不用担心Process方法中的逻辑了，我们只需要简单得回调我们定义的委托。记住！我们不关心委托是如何创建的(或什么时间)，我们就像调用其他方法一样调用它。如你所见，另一种理解委托的方法是，它延迟执行一个方法。Calculator方法在过去某个时间本选择，但不会执行，直到我们调用discount()的时候。现在看看我们的解决方案，这里仍然存在一些丑陋的代码。在Calculator类中，我们可以用一个不同的方法来返回替代每个有返回值得方法吗？答案是肯定的，让我们把这些乱糟糟的代码合并起来。

delegate int DiscountDelegate(); 
 
class Program { 
    static void Main(string[] args) { 
        new ShoppingCart().Process(new DiscountDelegate(Calculator.Calculate)); 
    } 
}  
class Calculator { 
    public static int Calculate() { 
        int discount = 0; 
        if (DateTime.Now.Hour < 12) { 
            discount = 5; 
        } 
        else if (DateTime.Now.Hour < 20) { 
            discount = 10; 
        } 
        else { 
            discount = 15; 
        } 
        return discount; 
    } 
}  
class ShoppingCart { 
    public void Process(DiscountDelegate discount) { 
        int magicDiscount = discount(); 
         // ... 
    } 
}

这样子看起来更好点。你会注意到我们用一个静态的Calculate方法替换了所有原来的方法，在Main方法中也不用费心维护一个指向DiscountDelegate的引用。现在你明白了所有关于委托的东西了吗？在2004年.NET1.1中可以这么说，但是很不幸的是，这种框架自那以后更加成熟了。

灯光，镜头，开始或者我们需要Func!

微软在.NET 2.0中引入了泛型，并提供了一个泛型委托:Action<T>。老实说，我认为它远不够用。后来在.NET 3.5中，它为我们提供了一些我们不想定义的通用委托。他们扩展了Action，并添加了Func，二者唯一区别在于Func型方法有一个返回值而Action型方法没有。

这意味着我们不需要声明自己的DiscountDelegate，可以用Func<int>替代。为说明这些观点是如何工作的，我们来假设管理层又一次改变了我们的逻辑，我们需要提供一些特殊的折扣。很简单，我们将给Calculate方法传入一个bool型值。

现在我们的委托签名变成Func<bool,int>。注意Calculate方法现在包含一个bool型参数，我们用一个bool值调用discount()。

class Program {
static void Main(string[] args) {
new ShoppingCart().Process(new Func<bool, int>(Calculator.Calculate));
}
}

class Calculator {
public static int Calculate(bool special) {
int discount = 0;
if (DateTime.Now.Hour < 12) {
discount = 5;
}
else if (DateTime.Now.Hour < 20) {
discount = 10;
}
else if (special) {
discount = 20;
}
else {
discount = 15;
}
return discount;
}
}

class ShoppingCart {
public void Process(Func<bool,int> discount) {
int magicDiscount = discount(false);
int magicDiscount2 = discount(true);
}
}

好像还算不错，我们又省了一行代码，这样算结束了吗？当然没有，我们甚至能省掉类型判断。只要我们传递的方法有严格签名的委托，.NET允许我们完全忽略掉显式创建Func<bool,int>。

//因为Process期望的方法有一个bool型输入参数和返回一个int值，所以下面这句话是正确的
new ShoppingCart().Process(Calculator.Calculate);

至此，首先通过忽略自定义委托，我们省略了代码；然后排出了明确的创建Func委托。我们能继续压缩代码行吗？到此我们才完成此文的一半，答案显然是“能”。

匿名方法

匿名方法能够让你声明一个方法体而不需要给它指定一个名字。在接下来的场景里，它们以一个“普通的”方法存在；但是在你的代码中没有任何方法显式调用它。匿名方法只能在使用委托的时候创建，事实上，它们通过delegate关键字创建。

class Program { 
    static void Main(string[] args)     { 
        new ShoppingCart().Process( 
            new Func<bool, int>(delegate(bool x) { return x ? 10 : 5; } 
        )); 
    } 
}

正如你所见，我们完全删除了Calculator类的需求。你可以在打括号中添加任何其他方法中的逻辑。如果你在看它如何执行时有困难，那就把delegate(bool x)做为一个方法签名，而不是一个关键字。设想这段代码在一个类里，delegate(bool x){return 5;}是一个完整的合法方法声明(我们确实有一个返回值)，恰好delegate是一个保留字，在这里，它让这个方法匿名。

至此，我确信现在你知道这里我们甚至能压缩更多的代码。顺利成章的，我们能忽略显式声明Func委托的需要；.NET让我们使用delegate关键字更方便。

class Program {
static void Main(string[] args) {
new ShoppingCart().Process(
delegate(bool x) { return x ? 10 : 5; }
);
}
}

当把.NET方法做为委托参数时或处理时间时，就能看到匿名方法的真正用处。之前，你会为你所关注的所有可能行为创建了一个方法，现在你仅需以内联的方式创建它们，并可以避免污染你的命名空间。

// 创建一个匿名比对方法
custs.Sort(delegate(Customer c1, Customer c2) {
return Comparer<int>.Default.Compare(c1.ID, c2.ID);
});

// 创建一个匿名事件
button1.Click += delegate(object o, EventArgs e) { MessageBox.Show("Click!"); };

Lambda 表达式

MSDN中写道：“Lambda 表达式”是一个匿名函数，它可以包含表达式和语句，并且可用于创建委托或表达式树类型。你应当明白“用户创建委托”部分，但什么是“表达式”呢？老实说，表达式和表达式树不在此为讨论范围内。现在我们唯一需要明白的是，表达式是.NET程序运行时表示数据或对象的代码(C#代码)。引用Jon Skeet的话：“表达式树是一种表达逻辑，这样其他的代码可以查询的方法。当一个lambda表达式转换成一个表达式树，编译器不会发出了lambda表达式的白细胞介素，它会发出白细胞介素这将会建立一个表达式树表示相同的逻辑。”

我们需要关注的是Lambda表达式替换匿名方法，和其他的特性。回顾我们最后例子，我们已经在一行代码里压缩了处理整个折扣算法的逻辑。

class Program {
static void Main(string[] args) {
new ShoppingCart().Process(
delegate(bool x) { return x ? 10 : 5; }
);
}
}

你相信我们能让这个更短吗？Lambda表达式用'=>'运算符表明什么参数传递给表达式。编译器进一步处理，允许我们忽略类型并自动替我们推断这些类型。如果你有2个或更多个参数，你需要用圆括号:(x,y)=>。如果只有一个，你设置不需要这样：x=>。

static void Main(string[] args) {
Func<bool, int> del = x => x ? 10 : 5;
new ShoppingCart().Process(del);
}
// 更短啦...
static void Main(string[] args) {
new ShoppingCart().Process(x => x ? 10 : 5);
}

就是这样子。x被推断为bool型，并且有返回值，因为Process接收一个Func<bool,int>。如果我们想实现像之前那样的完整代码块，我们只需要加上大括号。

static void Main(string[] args) {
new ShoppingCart().Process( x => {
int discount = 0;
if (DateTime.Now.Hour < 12) {
discount = 5;
}
else if (DateTime.Now.Hour < 20) {
discount = 10;
}
else if(x) {
discount = 20;
}
else {
discount = 15;
}
return discount;
});
}

写在最后

使用与不使用大括号有一个重要的不同。当你用时，你创建一个“语句Lambda”，反之，它是"表达Lambda"。语句Lambda能执行多条语句(因此需要大括号)，但不能创建表达树。你可能只在使用IQueryable接口是遇到这个问题。下面的例子说明这个问题。

List<string> list = new List<string>();
IQueryable<string> query = list.AsQueryable();
list.Add("one");
list.Add("two");
list.Add("three");

string foo = list.First(x => x.EndsWith("o"));
string bar = query.First(x => x.EndsWith("o"));
// foo and bar are now both 'two' as expected
foo = list.First(x => { return x.EndsWith("e"); }); //no error
bar = query.First(x => { return x.EndsWith("e"); }); //error
bar = query.First((Func<string,bool>)(x => { return x.EndsWith("e"); })); //no error

倒数第二行在编译时失败。这是因为IQueryable.First期望得到一个表达式作为参数，然而List<T>.First期望得到一个委托。你可以按照最后一行强制转换Lambda到一个委托(使用First的方法重载)。

这里很难结束讨论，但是我觉得必须停止。Lambda大体上分为两类：一类创建匿名方法和委托；另一类创建表达式。表达式自成一体，并不是.NET开发者的必备知识(无疑在LINQ中已有实现)。

备注：

此文为CodeProject上的同名文章<C# Delegates,Anonymous Methods, and Lambda Expressions>，个人觉得非常好，所以就翻一下给不想看英文的同学。由于能力有限，翻译的不好，望大家多多包涵。

本文链接

[讨论]未来有哪些编程概念会消失?

2010-09-25T13:21:00Z

今天重新看C#中委托，匿名方法等概念，脑子里突然冒出这么一个想法：未来高级语言编程会是什么样子，有哪些东西我们不用关心，现在拿出来给大家讨论一下。

我这里所说的高级语言是指最早的面向对象语言C++,Pascal等，后来的Smalltalk等，以及现代语言C#和Java，直到今天最新C# 4.0。注意：这里有2个C#，我没有写错，理由稍后再说。

大家知道，C++是从C扩展而来，所以它既支持面向过程，也支持面向对象。作为最早出现的面向对象高级语言，在今天还有很重要的地位。但任何编程的人都会为C++及以往语言中指针头痛不已。

随后出现了Smalltalk等纯面向对象语言，这个不了解，一笔带过。

20世纪90年代，出现了Java。Java的出现可谓竞艳四方，以至于以后N年稳坐排行榜首位。我想，之所以有这样的结果，最重要的就是Java中没有了指针，让程序员彻底从错综复杂的指针中解脱出来，大大提升了开发效率。这时候第一个与今天主题有关的概念出现了——指针消失。

Java之后不久就有了C#。最早的C#既有Delphi的优良血统，又到处包含Java的影子。不过初生的C#显得过于稚嫩，直到2.0才完成成熟。个人认为C#是非常优秀的现代编程语言，但它还在传统面向对象的范围内。

最近几年，相对于Java的老态龙钟，蹒跚不前，C#一直蓬勃发展，先后经历了3.0，3.5，直到最新的4.0版本。此时，我们惊奇的发现C#中多了诸如Lambda表达式，LinQ，动态编程，无类型等非传统面向对象，甚至是破坏面向对象的元素。而这些元素或多或少的都让我们的开发效率有所提升，也使得C# 4.0与2.0隐隐有巨大的不同。

再考虑到近年来不断涌现的各种编程技术和思想，比如SOA，AOP，CMS等等，渐渐的我们发现，我们正在离传统编程中关注的概念越来越远，甚至可以不用考虑。

现在看来，这些传统的概念包括指针，基本数据类型，操作符，多线程等。指针在Java，C#语言中已经消失，那么下一个消失的特性会是哪一个呢？我想可能会是基本数据类型，也可能是操作符，更有可能是多线程。

基本数据类型：基本数据类型之所以会消失，并不是想指针一样用不着，而是不会像现在一样用的那么频繁。比如也许有一天，我们不用声明一个Person的类，里面包含一个表示年龄的Int字段。

操作符：现代编程语言有很多的操作符，如一元运算符，二元运算符，三元运算符或者数值类，逻辑类等。这些操作符虽然提升了运算性能，但也带来的程序的复杂度，让程序员关注了更多不必要的内容。而未来这些可能消失，我们根本不用关心位运算，数值运算。这样子，程序员只用关系自己需要实现的业务逻辑就行了。

多线程：多线程从出现，到今天，其学习和使用的代价已经减少了很多，而我认为这些进步还不够，因为我们还纠结在同步，异步，锁等乱七八糟的概念中，甚至还有并行计算。而这些与我们要解决的业务逻辑根本没有直接的关系。如果没有这些，相信我们的开发效率可以提升N倍，软件性能可以提升N倍。这是一个广所熟知的问题，所以未来有一天，多线程可能真的会消失。

最后总结一下，文中所说的消失并不是真正意义上的消失，而是猜想未来有一天，基本数据类型，操作符，尤其是多线程/并行计算可能像今天的指针一样，有个如同GC一样的东西自动管理实现。以上纯属个人YY，也欢迎大家来拍转。

本文链接

博客园_倪大虾

高效管理ASP.NET的JavaScript库

预备知识确保已安装Visual Studio 2010。Express版可能不支持此文涉及到的一些概念。

如何向妻子解释设计模式

如何向妻子解释OOD

我的工作习惯小结

WPF之路——WPF布局系统

由感而发：离职的第四个理由

WPF之路——从HelloWorld到WPF World

.NET中的设计模式——一步步发现装饰模式

C#中的委托,匿名方法和Lambda表达式

[讨论]未来有哪些编程概念会消失?

预备知识
确保已安装Visual Studio 2010。Express版可能不支持此文涉及到的一些概念。