本季度公司要求阅读《框架设计（第2版）CLR Via C#》这本书，由于前两个月一直很忙，也没有时间阅读，偶尔阅读也是很晚回家以后临睡前拿起这经典之作读那么一个小节。最近利用周末可以说一鼓作气的看了大半本，感触很深。之前，这本书我阅读过第一版，那时好像叫《.NET框架设计》，当时就特别钦佩JR大叔的技术功底和写作技巧，正向书中有人评论的那样，JR确实适合于把枯涩难懂的概念用简短的语言描述清楚。还有下个季度需要阅读的《WINDOWS核心编程》更是经典中的经典（幸会这本书我阅读过），经典也是毫无疑问的，我这里只是感慨一下，相信阅读过这两本书的人都有这种感慨了。这两本书我觉得是一个WINDOWS程序员应该买来阅读并且摆在案头收藏的。

　　在阅读这本书时我发现很多值得思考和有趣的地方，例如：JR关于调用的参数和返回值的建议；位索引器示例；触发事件的事件安全；字符串格式化和字符串的驻留等。尤其是.NET的垃圾回收机制在这本书中讲的很详细。其中有两个知识点是让我感到收获很大的地方而且例子也很详细，我在这里就单独拿出来与大家分享，同时也作为知识点进行总结，这里讲没什么技术含量，大家别BS我。

　　第一部分：常量，只读字段，静态字段，静态只读字段区别与比较

　　常量：常量就是指永远不会改变的符号，在.Net通过编译以后常量的值会插入到程序集的元数据中，所以常量的类型必须是.Net的基元类型Boolean，Char，Byte，SByte，Int16，Int32，UInt32，Int64，UInt64，Singe，Double，Decimal和String。也就是说在一个程序集A的类中定义一个常量，在另一个程序集B中使用这个常量，当两个程序集编译以后，C#编译器会将这个常量插入到使用这个常量的程序集B的元数据中，而这时使用常量的程序集A对定义常量的程序集B没有运行时的依赖关系了，也就是说在运行时可以删除定义常量的程序集A，同时也说明如果修改这个常量的值再去编译定义常量的程序集A不会改变使用常量的程序集B在运行时获取到的这个常量的值，常量在带来这种好处的同时显然对于程序集的版本控制是很不利的。如果一个程序集需要从另一个程序集中总是获得最新的数据，则不能使用常量，这时可以使用只读字段。此外，常量具有static的含义，只能通过类型访问，不能通过对象访问。

　　只读字段：只读字段也是在初始化（这个初始化是在运行时初初始化的）以后在验证过程中不允许修改的字段，只读字段引用的可以是任何类型的对象。但要注意只读字段只有在对象初始化时可以给这个字段赋值，也就是字段在初始化时还具有可写属性，以后这个字段就只读了，字段的只读含义是这个变量的引用不可以改变了，但是具体引用的对象的状态时可以改变的。编译器和验证机制确保只读字段不会被任何其他方法写入，但是我们依然可以使用反射修改只读字段。只读字段属于对象实例的，需要通过对象访问，属于对象状态的一部分。

　　静态字段：静态字段是与类型关联的成员（只能通过类型访问，不像Java还可以通过类的实例访问，如果没记错的话），静态字段的初始化是在类型被加载到CLR中时执行的。静态字段可以应用任何类型的对象。

　　静态只读字段：静态只读字段与常量比较类似，但是静态只读字段不限于基元类型，可以是.Net中的任何类型，静态只读字段不像常量是在编译时插入到元数据中的，而静态只读字段是在运行时赋值和确定的，也就是对于程序的依赖是一种强依赖关系，具体的值是在运行时去程序集中取到的，而不像常量做一个拷贝插入元数据中。静态只读字段属于类型的，通过类型访问。

　　通过反射修改私有字段，下面一个示例通过反射修改私有的一般字段，常量，只读字段，静态字段，静态只读字段并打印出结果。在这里可以可以看出反射是很强大的，既然可以修改私有的只读字段，但要注意实际上通过反射也无法修改常量，修改会报错，这与常量的存储方式有关。通过反射给人一种可以跳过验证规则的假象。示例代码：

通过反射修改私有字段

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;

namespace FalseVerification
{
    class Program
    {
        static void Main(string[] args)
        {
            Type type = typeof(SomeType);

            SomeType st = new SomeType();
            st.Print();

            // 正常字段，当然可以修改
            FieldInfo fi = type.GetField("f1", BindingFlags.NonPublic | BindingFlags.Instance);
            fi.SetValue(st, (Int32)fi.GetValue(st) + 1);

            // 常量字段，反射也无法修改，如果取消下面语句的注释，执行会出错
            /* 原因说明：常量的值必须在编译时就确定（只能是基元类型），也就是说在定义时就赋值。
               编译后常量的值是保存在程序集的元数据中，在运行时是不可修改的；
               而其它字段是存储在动态内存中，在运行时是可修改的。*/
            fi = type.GetField("f2", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.Instance);
            //fi.SetValue(null, (Int32)fi.GetValue(null) + 1);

            // 只读字段，可通过反射方式修改值
            fi = type.GetField("f3", BindingFlags.NonPublic | BindingFlags.Instance);
            fi.SetValue(st, (Int32)fi.GetValue(st) + 1);

            // 静态字段，也可修改
            fi = type.GetField("f4", BindingFlags.NonPublic | BindingFlags.Static);
            fi.SetValue(null, (Int32)fi.GetValue(null) + 1);

            // 静态只读字段，下面代码不出错，改变了反射字段的值，但类中的字段值并没有被改变
            fi = type.GetField("f5", BindingFlags.NonPublic | BindingFlags.Static);
            fi.SetValue(null, (Int32)fi.GetValue(null) + 1);
            Int32 f5 = (Int32)fi.GetValue(null); // i5 得到值为51

            st.Print();
            Console.WriteLine("f5: " + f5.ToString());
            Console.ReadKey();
        }
    }

    public class SomeType
    {
        private Int32 f1 = 30;// 私有字段
        private const Int32 f2 = 10;// 私有常量字段
        private readonly Int32 f3 = 20;// 私有只读字段
        private static Int32 f4 = 40;// 私有静态字段
        private static readonly Int32 f5 = 50;// 私有静态只读字段

        public void Print()
        {
            Console.WriteLine("f1: " + f1.ToString());
            Console.WriteLine("f2: " + f2.ToString());
            Console.WriteLine("f3: " + f3.ToString());
            Console.WriteLine("f4: " + SomeType.f4.ToString());
            Console.WriteLine("f5: " + SomeType.f5.ToString());

            Console.WriteLine();
        }
    }
}

 运行结果：

　　从这个结果可以看出，通过反射可以修改私有的普通字段，可以修改只读字段，可以修改静态字段，修改这三个都没有问题，但是不可以修改常量字段。当通过反射修改静态只读字段时（有点类似常量）时，可以正常执行，但是通过类获取的静态只读字段并没有改变，说明实际并没有修改成功，我们实际修改的只是通过反射获取的静态只读字段，并没有实际映射回去。具体原因感兴趣的同学可以通过IL分析一下，鄙人不才，不会IL。

　　第二部分：GC中的GCBeep示例

　　先看看代码：

GCBeep

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace GCBeep
{
    class Program
    {
        static void Main(string[] args)
        {
            new GCBeep();

            // 创建很多对象，让GC执行垃圾收集
            for (Int32 x = 0; x < 10000; x++)
            {
                Console.WriteLine(x);
                Byte[] b = new Byte[100];
            }
        }
    }

    internal sealed class GCBeep
    {
        /* 
         这是一个Finalize方法，GC在发现根
         中没有对于GCBeep对象的引用时会在
         垃圾收集时调用这个方法
        */
        ~GCBeep()
        {
            Console.Beep();// 让控制台发出报警的声音

            if (!AppDomain.CurrentDomain.IsFinalizingForUnload() && !Environment.HasShutdownStarted)
            {
                // 如果不是在应用程序域卸载或应用程序自行关闭时，新建一个GCBeep对象并没有变量引用它
                new GCBeep();
            }
        }
    }
}

　　GC在垃圾收集时会执行对象的Finalize方法来释放非托管的资源，在这里也就是~GCBeep()，在~GCBeep()方法内部首先让控制台发出报警声，之后会在不是应用程序域卸载和应用程序主动退出的情况下再创建一个GCBeep对象，并不让任何变量引用它，此时这个对象实际上已经成为下次GC执行垃圾收集的目标。在主函数中同样也是创建一个无变量引用的GCBeep对象作为程序的入口点，之后创建大量的对象，当托管堆的相关内存用完之后垃圾收集就会执行来回收垃圾释放内存以便容纳新创建的对象，这时垃圾收集调用~GCBeep()发出报警声。创建10000个Byte[] b = new Byte[100];在我的x86的win7笔记本上发出两次报警声，大家可以修改10000到更大测试，来根据报警声来判断执行~GCBeep()的次数。

　　这个例子我觉得设计的很精美，也很简洁，更重要的是可以说明垃圾收集时确实自动执行了对象的Finalize方法来释放非托管资源（作为示例这里并没有实际释放非托管资源）。

评论: 8　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

　　这篇文章对于高手跳过，内容比较初级。有几个概念在服务器端编程时我会经常混淆，估计有些朋友也和我一样。它们是请求（对应响应），连接，线程。这篇短文主要是对这几个概念作了一定的解释，当你理清这些概念以后，就不会习惯性的认为一个请求必须由一个线程处理了，它们之间并没有这种必然的联系。

　　请求Request
　　我们经常提到的Request实际上是指客户端发过来的用于对某些资源的访问申请或将一些客户端的数据等发送给服务端的请求，一般一个请求会相应的有一个响应。服务器端收到请求以后会对这个请求作出处理，可能是直接处理掉或者暂时放到请求的队列中等待。大家都知道Web开发中的HttpRequest和HttpResponse，它们就分别代表一个遵循Http协议的请求和一个遵循Http协议的响应，通过请求可以拿到客户端要请求的资源（URl），这个请求的客户端环境，以及请求中携带的提交数据（例如POST方式为提交一些表单数据等），与这个请求对应的响应是Http服务器给客户端的应答，包括处理的结果和一些消息内容等。可以把它们简单理解成客户端提交给服务器的数据和服务器处理这些数据以后给客户端发送的数据，也可以理解为一问一答。

　　连接Connection
　　在服务器端编程时连接可能是最重要的概念了，但是很多组件已经把连接的管理封装在了底层框架中（例如协议栈的连接管理模块），所以有时连接对于用户来说是透明的，使用者甚至不知道连接的存在，但是当发现问题时你可能就需要了解连接是如何管理的了。现在我们谈连接的概念已经局限在了Socket连接之上了（实际上是一种规范），因为它实在太广泛了。建立Socket连接时可以绑定TCP或者UDP协议。无论TCP还是UDP都是在传输层控制数据的。一个连接可以理解成一个客户端和服务器的双向数据通道，数据可以在这个通道中传输，实际上这个通道本质上就是网络的节点设备上保存的各种数据结构。要想在节点设备中传输数据就要建立连接，传输完成以后如果不再使用要关闭连接，释放这些数据结构所占用的资源（主要是内存资源），对于客户机来讲，可以对同一服务器并行存在多条连接，在微软的WINDOWS系统中默认可以同时存在2/4连接，这也是长期以来的一个潜规则，当然这个数字也可以通过配置改变或者对于不同的WINDOWS版本会有不同的值。如果对两个节点的连接使用完成以后没有关闭，再去创建连接达到上限以后就会失败，所以一些协议栈的底层框架会有一个很重要的模块就是连接的管理。它一般处理是这样的:打开一个连接以后不断的使用这个连接发送数据，如果发现长时间没有数据传输，那么策略就是关闭这个连接，这个关闭连接的操作可以由客户端发起，也可以由服务器端发起，具体的关闭操作在协议栈上一般会使用客户端的request.close()和response.close()方法实现或者服务器端的request.close()和response.close()方法实现。由此我们就可以理解为什么在应用层的协议中都会有一个类似connection.keepalive=true的东西存在。在我们经常使用的即时聊天工具（例如Fetion）中客户端要想保持这种连接也要不断的发送Keep-Alive信令消息，如果服务器发现在一定的时间内没有收到这个信令消息，则就会主动关闭对这个客户端的连接以释放资源满足其它客户端的连接能力。

　　线程Thread
　　这个概念在这里来讲确实有些不合适，因为它是几乎所有编程中都会用到的。在服务器端编程中，线程主要负责处理来自客户端的请求，这里主要想说明的是线程与请求没有直接的对应关系，也就是一个请求不一定由单独一个线程处理（例如ASP.NET中的异步httphandler），但总会有某个线程会处理它。此外线程的创建需要的开销比较大，系统需要分配线程内核对象和一个线程堆栈，为了减少每次创建线程的系统开销，windows线程池产生，代码的最终执行还要落到线程中，所以有关请求的处理也是由线程完成的，很多服务器为了提高吞吐量，会开启多个线程对请求进行处理。例如ASP.NET对于请求的处理就是这样的，一个客户端的请求到达服务器以后，ASP.NET会从.NET的线程池中提出一个空闲的线程处理这个请求，但是如果处理这个请求需要很长时间的话，这个线程就不会被释放回线程池，如果请求大量的并发而来，线程池中没有足够的线程处理这些请求，那么这些请求可能进行排队（缓存在请求队列中）等待空闲线程来处理。对于这些需要长时间处理的IO请求，我们可以使用ASP.NET的异步httphandler来处理，异步httphandler的优点就是可以异步处理请求，这样就可以将工作线程释放回线程池以便处理更多等待着的请求，这样设计毫无疑问可以提高服务器的吞吐量。异步htthandler在结束IO操作以后会执行回调函数来通知请求已经结束，这时ASP.NET可以将这个响应发给客户端了，这个连接也可以在合适的时候关闭了（这里要注意一点就是在回调执行前，在Response返回给客户端前这个连接一直是保持的）。由此可以看出这种异步htthandler只是在服务器端的异步处理，对于客户端是透明的，客户端并不知道服务器端是怎么处理的。如果要想在客户端达到异步的请求提交和响应的获取可以使用AJAX的核心对象XMLHttpRequest实现。同样这个XMLHttpRequest也是受限于默认的2/4并发连接的限制。

　　总结

　　这篇短文全都是文字，一点都不美观，大家凑合看吧。其实理解了这几个概念对排查一些问题还是有帮助的，这里主要想说明的就是三者之间没有什么必然的对应关系。其实有时候不知不觉我们就会把他们扯上一些没有必要的关系，这样会限制我们的思维。

评论: 3　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

　　最近在项目中遇到了很棘手的问题，查到最后发现是由于HttpWebRequest对于同一个domain的请求建立的连接数同时不能超过两个的限制造成的。我用这篇短文把对这个问题的处理记录下来，同时也做为个人的经验积累吧，希望对大家有所帮助。

　　这里所说的连接并发数限制是指对于同一个domain发起的最大连接数。其实在大多数微软的产品或组件中都存在这个限制，一般这个数值是2/4个，也就是说在默认情况下，对于同一个domain同时最多有两个连接处于建立状态。例如：熟悉javascript编程的人可能很清楚这个限制，在使用ajax时创建XmlHttpRequest对于同一个domain就有这个限制，实际上这个限制是继承与微软的IE浏览器的默认限制，也就是说IE浏览器本身对于同一个domain发起的连接数同时最多存在两条链路，由于Http协议是一个无状态的协议，连接也在Response返回来以后断掉（除非指定了keep-alive可以保持连接，这样可以保持一段时间），当然对于像IE这种多模式的客户端来说，这两条连接同时建立的时候几乎很少，甚至不可能，当然在comet技术应用时是很模拟。所以对于这种模式下的客户端来说这个连接限制没有那么明显，甚至很多人都不知道这个限制的存在。当然微软做这个限制是道理的，我想最大的好处可能就是防止一个客户端发起太多的并行连接来攻击服务器了（我的拆测）。但是这个连接限制在同时也阻碍了单模式下的服务器编程，当然我们可以修改这个默认值，但是毕竟还是比较麻烦。而且这个修改对于一个应用程序来说来说是全局的（我采取的方式，因为对HttpWebRequest对象的修改并不适合我的项目），当然这个修改也可以针对具体的HttpWebRequest对象进行设置。具体如何修改可以参照一下这篇文章http://www.qqdao.org/Lists/Posts/Post.aspx?List=751e96b2%2D405a%2D41cf%2Dadce%2Dc6a5b9a8c157&ID=22&RootFolder=%2A

　　我的问题是出现在刚刚上线的项目中，我的这个项目是一个服务器端程序，内部使用了HttpWebRequest去请求一个网站的url。在这个项目中请求的次数非常频繁。

　　问题表现：刚上线的服务就要承担很大的压力，据统计大概每秒钟有至少2000多个请求需要处理，有四台服务器做负载实现。但是发现在功能环境下运行很好的程序到了生产环境很多调用都失败了，成功的占了比例不大。失败的请求大都报如下错误“System.Net.WebException: The request was aborted: The request was canceled.”。但是查看网站的压力并不大，可以说是很轻，在用netstat -abn | find "xxxx"命令查看到网站的连接，发现只有两个已经建立的连接，当然这两个连接是并行的，并且是keep-alive的连接。从问题可以看出，大多数请求实际上是发送失败了，之后被取消了。但是这个发送失败并不是网站一侧没有资源来应答，而是请求在客户端就没有发出去数据包，可以说请求本身就没有发送出去。这个问题导致网站对于请求的吞吐能力再强也没有用，客户端请求发送失败。给人的感觉就像请求积压很厉害并且最后放弃了。

　　问题排查：这个问题对于没有经验的人来说却实无从下手，方法就是尽量排除一些可能的原因，剩下最后的几个原因时进行验证。首先我猜测可能是线程池中的线程用尽了，但是后来抓了dump进行分析发现并不是这个原因。在经过一个晚上沉重的思考以后，第二天早上似乎有了一点灵感，已经很确定是由于连接数的限制了。我这样说是因为我考虑到网站端如果长时间没有返回，那么这个连接就一直在占用，当两个连接都在被占用时，再发送请求是就会由于没有及时得到可用的连接而失败（虽然实际情况可能比这要复杂的多，例如缓存请求，进行重试等，但是请求很频繁是，发送的能力是有限的，总会有一些请求没有及时发送出去而抛出异常，这个问题就好比通过一个漏斗向一个容器中注入水一样，如果流入的速度大于流出的速度会使漏斗慢慢达到盛满水，这样再继续时肯定就会流到外面了，也就是这里出现了异常，也就是多出来的会放舍弃掉。

　　问题解决：既然知道了原因，那么解决起来自然也就比较容易了，修改.Net的这个默认并发连接数可以通过很多种方式，可以通过在程序初始化时执行以下代码完成ServicePointManager.DefaultConnectionLimit = 500;，也可以通过修改配置文件来达到同样的效果，由于程序已经上线，所以我是通过修改配置完成的。这个东西自然在线下也做了很多测试，发现确实是这里的问题，于是晚上做了一个更新，第二天早上发现基本所有调用都成功了，不成功的也是网站没有返回结果超时导致的，真是庆幸。同时发现以前经常报的错也不见了，正如我所料。当然我这限制设置为500而没有设置到1000主要是我想客户端的端口开的不会太多。

　　总结：这个配置我觉得是一个限制，不能设置的太大也不能太小。其实搞计算机的需要很多经验的同时，灵感也很重要，这个问题就是我在当天晚上没有办法的情况下入睡以后，第二天醒来以后突然觉察到的，之后到了公司就开始测试和验证，没想到还真解决了问题，但是有一点还是特别提醒，无论是用什么协议栈发送调用或消息，最好都不要使用for语句压消息，这会太调用量大时会出现问题。

评论: 13　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

     这一篇我将向大家讲解建造者（Builder）模式。在上一篇文章中我们主要学习了抽象工厂（Abstract Factory）模式，抽象工厂模式主要解决对不同等级结构的产品的创建工作，主要关注的是创建哪一批产品的问题，而本文所讲的建造者模式主要是解决对于一个产品如何分部创建的问题，这是对于建造者模式的最初描述。同样，这篇文章主要分为两大部分来讲解，第一部分我会对建造者模式的原型进行详细的说明，第二部分会对建造者模式如何解决具体问题进行探讨。

     建造者模式的原型

     描述：

     在软件系统中，有时候面临一个"复杂对象"的创建工作，其通常由各个部分的子对象用一定算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合到一起的算法却相对稳定。

     建造者模式是对对象的创建模式。建造者模式可以将一个产品的内部表象与产品的生成过程分隔开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。建造者模式利用一个导演者对象和具体建造者对象一个一个地建造出所有的零件，从而建造出完整的产品对象。建造者模式将产品的结构和产品的零件建造过程对客户端隐藏起来，把对建造过程进行指挥的责任和具体建造零件的责任分隔开来，达到责任划分和封装的目的。

      意图：

     将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

      模式原型UML：

     建造者模式涉及到以下角色：

     1、抽象建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。此接口中一般至少规定两个方法，一个是创建部分的方法，例如BuilderPart，另一个是返回结果的方法，例如GetProduct，以约束具体建造者实现。
     2、具体建造者（ConcreteBuilder）角色：担任这个角色的是与应用程序紧密相关的一些类，它们在应用程序的调用下创建产品的实例。这个角色产品实现了抽象建造者接口，主要完成分部创建产品并提供产品对象的实例。
     3、导演者（Director）角色：顾名思义，就是具体指挥使用哪个具体创造者来完成产品的创建，是创建工作的调用者。但是，导演者角色并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者角色。
     4、产品（Product）角色：产品角色就是建造中的复杂对象。一般只有对于复杂对象的创建才使用建造者模式，一个系统中会出现多于一个的产品类，而这些产品类并不一定有共同的接口，可能完全不关联，这时就需要提供多套抽象和具体的建造者来完成不一致的产品的创建或者是采用一个统一接口来标识产品，我个人推荐前者。请大家注意，这里的产品只是一个产品类，不存在继承关系，所以也就没有像抽象工厂中的那种客户端依赖抽象的说法了。

     模式原型代码：

Builder pattern code in C#
// 建造者模式

using System;
using System.Collections;

namespace DesignPatterns.Creational
{

    // 应用程序测试

    public class MainApp
    {
        public static void Main()
        {
            // 创建导演者和具体建造者角色
            Director director = new Director();

            Builder b1 = new ConcreteBuilder1();
            Builder b2 = new ConcreteBuilder2();

            // 根据两个建造者获得产品类，注意应用程序直接使用产品类
            director.Construct(b1);
            Product p1 = b1.GetResult();
            p1.Show();

            director.Construct(b2);
            Product p2 = b2.GetResult();
            p2.Show();

            // 等待输入
            Console.Read();
        }
    }

    // 导演者角色

    class Director
    {
        // 导演者调用建造者分部创建，注意具体的创建顺序由导演者决定
        public void Construct(Builder builder)
        {
            builder.BuildPartA();
            builder.BuildPartB();
        }
    }

    // 抽象建造者

    abstract class Builder
    {
        public abstract void BuildPartA();
        public abstract void BuildPartB();
        public abstract Product GetResult();
    }

    // 具体建造者1

    class ConcreteBuilder1 : Builder
    {
        private Product product = new Product();

        public override void BuildPartA()
        {
            product.Add("PartA");
        }

        public override void BuildPartB()
        {
            product.Add("PartB");
        }

        public override Product GetResult()
        {
            return product;
        }
    }

    // 具体建造者2

    class ConcreteBuilder2 : Builder
    {
        private Product product = new Product();

        public override void BuildPartA()
        {
            product.Add("PartX");
        }

        public override void BuildPartB()
        {
            product.Add("PartY");
        }

        public override Product GetResult()
        {
            return product;
        }
    }

    // 产品类

    class Product
    {
        ArrayList parts = new ArrayList();

        public void Add(string part)
        {
            parts.Add(part);
        }

        public void Show()
        {
            Console.WriteLine("\nProduct Parts -------");
            foreach (string part in parts)
                Console.WriteLine(part);
        }
    }
}

输出结果为：

Product Parts -------
PartA
PartB

Product Parts -------
PartX
PartY

     生活中的实例：

     这个小例子向大家展示了一辆车是如何利用建造者模式被创建的，注意商店（这里就是导演者）是如何利用VehicleBuilders按照一定的顺序创建一辆车的。

Real world code using Abstract Factory in C#
// 建造者模式应用小例子

using System;
using System.Collections.Generic;

namespace DesignPatterns.Creational.Builder.RealWorld
{

    // 主应用程序
    public class MainApp
    {

        public static void Main()
        {

            VehicleBuilder builder;

            // 利用具体Builder创建商店对象
            Shop shop = new Shop();

            // 踏板车建造者
            builder = new ScooterBuilder();
            shop.Construct(builder);
            builder.Vehicle.Show();

            // 小汽车建造者
            builder = new CarBuilder();
            shop.Construct(builder);
            builder.Vehicle.Show();

            // 摩托车建造者
            builder = new MotorCycleBuilder();
            shop.Construct(builder);
            builder.Vehicle.Show();

            // 等待用户输入
            Console.ReadKey();
        }
    }
    
    // 商店类，相当于导演者角色
    class Shop
    {

        // 经过一个复杂的建造过程
        public void Construct(VehicleBuilder vehicleBuilder)
        {

            vehicleBuilder.BuildFrame();

            vehicleBuilder.BuildEngine();

            vehicleBuilder.BuildWheels();

            vehicleBuilder.BuildDoors();

        }
    }

    // 车辆建造者，相当于抽象建造者角色
    abstract class VehicleBuilder
    {

        protected Vehicle vehicle;

        // 获得车辆产品实例
        public Vehicle Vehicle
        {
            get { return vehicle; }
        }

        // 分部建造方法
        public abstract void BuildFrame();

        public abstract void BuildEngine();

        public abstract void BuildWheels();

        public abstract void BuildDoors();
    }

    // 摩托车建造者，相当于一个具体建造者角色
    class MotorCycleBuilder : VehicleBuilder
    {

        public MotorCycleBuilder()
        {

            vehicle = new Vehicle("MotorCycle");
        }

        public override void BuildFrame()
        {

            vehicle["frame"] = "MotorCycle Frame";
        }

        public override void BuildEngine()
        {

            vehicle["engine"] = "500 cc";
        }

        public override void BuildWheels()
        {

            vehicle["wheels"] = "2";
        }

        public override void BuildDoors()
        {

            vehicle["doors"] = "0";
        }
    }

    // 小汽车建造者，相当于一个具体建造者角色
    class CarBuilder : VehicleBuilder
    {

        public CarBuilder()
        {

            vehicle = new Vehicle("Car");
        }

        public override void BuildFrame()
        {

            vehicle["frame"] = "Car Frame";
        }

        public override void BuildEngine()
        {

            vehicle["engine"] = "2500 cc";
        }

        public override void BuildWheels()
        {

            vehicle["wheels"] = "4";
        }

        public override void BuildDoors()
        {

            vehicle["doors"] = "4";
        }
    }

    // 踏板车建造者，相当于一个具体建造者角色
    class ScooterBuilder : VehicleBuilder
    {

        public ScooterBuilder()
        {

            vehicle = new Vehicle("Scooter");
        }

        public override void BuildFrame()
        {

            vehicle["frame"] = "Scooter Frame";
        }

        public override void BuildEngine()
        {

            vehicle["engine"] = "50 cc";
        }

        public override void BuildWheels()
        {

            vehicle["wheels"] = "2";
        }

        public override void BuildDoors()
        {

            vehicle["doors"] = "0";
        }
    }

    // 车辆类，相当于产品类。注意这里的车辆类与摩托车、小汽车、踏板车等不是继承关系
    class Vehicle
    {

        private string _vehicleType;

        // 使用一个字典来保存部分
        private Dictionary<string, string> _parts =
          new Dictionary<string, string>();

        // 构造器
        public Vehicle(string vehicleType)
        {

            this._vehicleType = vehicleType;
        }

        // 索引器
        public string this[string key]
        {

            get { return _parts[key]; }

            set { _parts[key] = value; }
        }

        public void Show()
        {

            Console.WriteLine("\n---------------------------");

            Console.WriteLine("Vehicle Type: {0}", _vehicleType);

            Console.WriteLine(" Frame : {0}", _parts["frame"]);

            Console.WriteLine(" Engine : {0}", _parts["engine"]);

            Console.WriteLine(" #Wheels: {0}", _parts["wheels"]);

            Console.WriteLine(" #Doors : {0}", _parts["doors"]);
        }
    }
}

输出结果为：

---------------------------
Vehicle Type: Scooter
Frame  : Scooter Frame
Engine : none
#Wheels: 2
#Doors : 0

---------------------------
Vehicle Type: Car
Frame  : Car Frame
Engine : 2500 cc
#Wheels: 4
#Doors : 4

---------------------------
Vehicle Type: MotorCycle
Frame  : MotorCycle Frame
Engine : 500 cc
#Wheels: 2
#Doors : 0

     什么情况下使用建造者：

1、需要生成的产品对象有复杂的内部结构。每一个内部成分本身可以是对象，也可以仅仅是一个对象的组成部分。
2、需要生成的产品对象的属性相互依赖。建造者模式可以强制实行一种分步骤进行的建造过程，因此，如果对象的一个属性必须在另一个属性被赋值之后才可以被赋值，使用建造者模式便是一个很好的设计思想。
3、在对象创建过程中会使用到系统中的其他一些对象，这些对象在产品对象的创建过程中不易得到。

     实际项目举例

     现在我们需要在一个在PC游戏中构建房子的程序。可以构建的房子有多种样式，但是房屋的结构是相对稳定的，每个房子都有地基，墙面，房间，门，窗，地板等，同时也存在一定的构建顺序（必须先构建地基，这也就是产品类的组成部分之间的依赖关系），房子的具体风格可能包括很多种，例如居民住房，存放货物的仓储房等。由于房子的结构稳定，变化的只是房子的组成部分，这时我们可以考虑采用建造者模式来完成具体房屋的创建工作，即创建房屋和使用房屋责任的分离，房屋的构建与其表示相分离。同样的建造过程可以创建不同的表示（居民住房，存放货物的仓储房等）。

     本案例中的类与建造者模式中的角色的对应关系：

BuildingBuilder（房屋建造者）——Builder（抽象建造者）

Architect（建造师）——Director（导演者）

HousingBuilder（住房建造者）——ConcreteBuilder1（具体建造者1）

StorageBuilder（仓储房建造者）——ConcreteBuilder2（具体建造者2）

Building（房子）——Product（产品）

     实现的代码如下：

Project code using Abstract Factory in C#
// 建造者模式项目应用案例

using System;
using System.Collections.Generic;

namespace DesignPatterns.Creational.Builder.Project
{

    // 主应用程序
    public class MainApp
    {

        public static void Main()
        {

            BuildingBuilder builder;

            // 利用具体Builder创建建筑师对象
            Architect architect = new Architect();

            // 住房建造者
            builder = new HousingBuilder();
            architect.Construct(builder);
            builder.Building.DisplayMe();

            // 仓储建造者
            builder = new StorageBuilder();
            architect.Construct(builder);
            builder.Building.DisplayMe();

            // 等待用户输入
            Console.ReadKey();
        }
    }
    
    // 建筑师，相当于导演者角色
    class Architect
    {

        // 经过一个复杂的建造过程
        public void Construct(BuildingBuilder buildingBuilder)
        {
            buildingBuilder.BuildBase();

            buildingBuilder.BuildWall();

            buildingBuilder.BuildWindows();

            buildingBuilder.BuildDoors();

            buildingBuilder.BuildRooms();

            buildingBuilder.BuildFloor();
        }
    }

    // 房子建造者，相当于抽象建造者角色
    abstract class BuildingBuilder
    {

        protected Building building;

        // 获得房子实例
        public Building Building
        {
            get { return building; }
        }

        // 分部建造方法
        public abstract void BuildBase();

        public abstract void BuildWall();

        public abstract void BuildWindows();

        public abstract void BuildDoors();

        public abstract void BuildRooms();

        public abstract void BuildFloor();
    }

    // 住房建造者，相当于一个具体建造者角色
    class HousingBuilder : BuildingBuilder
    {

        public HousingBuilder()
        {

            building = new Building("Housing");
        }

        public override void BuildBase()
        {

            building["base"] = "Housing Base";
        }

        public override void BuildWall()
        {

            building["wall"] = "Housing Wall";
        }

        public override void BuildWindows()
        {

            building["windows"] = "2";
        }

        public override void BuildDoors()
        {

            building["doors"] = "2";
        }

        public override void BuildRooms()
        {

            building["rooms"] = "3";
        }

        public override void BuildFloor()
        {

            building["floor"] = "3*20m2";
        }
    }

    // 仓储房建造者，相当于一个具体建造者角色
    class StorageBuilder : BuildingBuilder
    {

        public StorageBuilder()
        {

            building = new Building("Storage");
        }

        public override void BuildBase()
        {

            building["base"] = "Storage Base";
        }

        public override void BuildWall()
        {

            building["wall"] = "Storage Wall";
        }

        public override void BuildWindows()
        {

            building["windows"] = "0";
        }

        public override void BuildDoors()
        {

            building["doors"] = "1";
        }

        public override void BuildRooms()
        {

            building["rooms"] = "0";
        }

        public override void BuildFloor()
        {

            building["floor"] = "1000m2";
        }
    }

    // 房子类，相当于产品类
    class Building
    {

        private string _buildingType;

        // 使用一个字典来保存部分
        private Dictionary<string, string> _parts =
          new Dictionary<string, string>();

        // 构造器
        public Building(string buildingType)
        {

            this._buildingType = buildingType;
        }

        // 索引器
        public string this[string key]
        {

            get { return _parts[key]; }

            set { _parts[key] = value; }
        }

        public void DisplayMe()
        {

            Console.WriteLine();

            Console.WriteLine(" Building Type: {0}", _buildingType);

            Console.WriteLine(" Base : {0}", _parts["base"]);

            Console.WriteLine(" Wall : {0}", _parts["wall"]);

            Console.WriteLine(" #Windows : {0}", _parts["windows"]);

            Console.WriteLine(" #Doors : {0}", _parts["doors"]);

            Console.WriteLine(" #Rooms : {0}", _parts["rooms"]);

            Console.WriteLine(" Floor : {0}", _parts["floor"]);
        }
    }
}

输出结果为：

Building Type : Housing
Base : Housing Base
Wall : Housing Wall
#Windows : 2
#Doors : 2
#Rooms : 3
Floor : 3*20m2

Building Type : Storage
Base : Storage Base
Wall : Storage Wall
#Windows : 0
#Doors : 1
#Rooms : 0
Floor : 1000m2

     小结

1、Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是稳定的，而复杂对象的各个部分则经常变化。
2、Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
3、Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder械通常和Composite模式组合使用。

      Welcome to share our idea,thank you!欢迎分享您的想法,谢谢!

      大家一起学面向对象设计模式系列 索引贴

评论: 1　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

附录61条面向对象设计的经验原则(来源于互联网)

     我觉得这61条经验原则说的很好，所以我把它作为设计模式系列的一个附录贴到这里提供给大家参考（实际上与设计模式关系不大）。对于每一条原则我们都可以进行深入的思考，理解其中的内涵，遵循这些原则的设计可能在复用性和扩展性上会更好些。

     这些经验原则是:

(1)所有数据都应该隐藏在所在的类的内部。

(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。

(3)尽量减少类的协议中的消息。

(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。

(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。

(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。

(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。

(8)类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响。

(9)把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。朝着稳定的方向进行依赖。

(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。

(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。

(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。

(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。

(15)对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。

(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。

(18)从你的设计中去除不需要的类。一般来说，我们会把这个类降级成一个属性。

(19)去除系统外的类。系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。

(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。

(22)尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。

(23)尽量减少类和协作者之间传递的消息的数量。

(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。

(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。

(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。

(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。

(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。

(29)让系统功能在窄而深的继承体系中垂直分布。

(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。

(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。

(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。

(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。

(34)类必须知道它包含什么，但是不能知道谁包含它。

(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。

(36)继承只应被用来为特化层次结构建模。

(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。

(38)基类中的所有数据都应当是私有的，不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

(39)在理论上，继承层次体系应当深一点，越深越好。

(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。

(41)所有的抽象类都应当是基类。

(42)所有的基类都应当是抽象类。

(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。

(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。

(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。

(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。

(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。

(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。

(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。

(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。

(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。

(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。

(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。

(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。

(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。

(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？

(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。

(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。

(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。

(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。

(61)不要绕开公共接口去修改对象的状态。

      Welcome to share your idea,thank you!欢迎分享您的想法,谢谢!

     大家一起学面向对象设计模式系列 索引贴

评论: 5　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

     现在我们正式进入GoF23种设计模式中的创建型模式的讲解中来，创建型模式主要解决对象如何创建的问题，提倡创建对象的责任和使用对象的责任分离，以达到更好对创建对象的控制的目的，创建型模式主要包括抽象工厂(Abstract Factory)，建造者(Builder)，工厂方法(Factory Method)，原型(Prototype)，单子(Singleton)。这篇文章主要分为两大部分内容，在第一部分中我将介绍抽象工厂模式的原型，包括抽象工厂的意图，可以解决的问题，原型代码和UML等，再结合一个生活中的小例子进行原型的说明。第二部分我会结合实际项目来讲述一下抽象工厂模式是如何应用的。最后我会对抽象工厂模式进行一个小结。

     工厂模式的几种形态

     工厂模式专门负责将大量有共同接口的类实例化。工厂模式可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。工厂模式有以下几种形态：

简单工厂（Simple Factory）模式：又称静态工厂方法模式（Static Factory Method Pattern）。主要是工厂中提供一个静态的方法用来根据不同的参数创建不同的抽象产品的具体实例，一般在IoC中应用比较多，例如通过反射机制和简单工厂模式可以解决依赖注入的问题。简单工厂模式不属于GoF23种设计模式，这里也就不再作过多的分析。感兴趣的园友可以找找相关资料。

工厂方法（Factory Method）模式：又称多态性工厂（Polymorphic Factory）模式或虚拟构造子（Virtual Constructor）模式。这个模式属于GoF23种设计模式之一，在后面的文章中会做详细的介绍。

抽象工厂（Abstract Factory）模式：又称工具箱（Kit或Toolkit）模式。这是本文的重点。

     抽象工厂模式的原型

     描述:

     假设一个子系统需要一些产品对象，而这些产品对象又属于一个以上的产品等级结构。那么为了将消费这些产品的责任和创建这些产品对象的责任分割开来，可以引进抽象工厂模式。这样的话，消费产品的一方不需要直接参与产品的创建工作，而只需要向一个公用的工厂接口请求所需要的产品。

      意图：

     抽象工厂模式可以向客户端（Client指代码模式的使用者，后文类同）提供一个接口，使得客户端在不必指定产品的具体类型的情况下，创建多个产品族（Product Family指位于不同产品等级中，功能相关联的产品的集合）中的产品对象。

     模式原型UML：

      模式原型代码：

Abstract Factory pattern code in C#
// 抽象工厂模式原型代码

using System;

namespace DesignPatterns.Creational
{

    // 测试程序

    class MainApp
    {
        public static void Main()
        {
            // 抽象工厂1 
            AbstractFactory factory1 = new ConcreteFactory1();
            Client c1 = new Client(factory1);
            c1.Run();

            // 抽象工厂2 
            AbstractFactory factory2 = new ConcreteFactory2();
            Client c2 = new Client(factory2);
            c2.Run();

            // 等候用户输入 
            Console.Read();
        }
    }

    // 抽象工厂

    abstract class AbstractFactory
    {
        public abstract AbstractProductA CreateProductA();
        public abstract AbstractProductB CreateProductB();
    }

    // 具体工厂1

    class ConcreteFactory1 : AbstractFactory
    {
        public override AbstractProductA CreateProductA()
        {
            return new ProductA1();
        }
        public override AbstractProductB CreateProductB()
        {
            return new ProductB1();
        }
    }

    // 具体工厂2 

    class ConcreteFactory2 : AbstractFactory
    {
        public override AbstractProductA CreateProductA()
        {
            return new ProductA2();
        }
        public override AbstractProductB CreateProductB()
        {
            return new ProductB2();
        }
    }

    // 抽象产品A，产品族中一个成员

    abstract class AbstractProductA
    {
    }

    // 抽象产品B，产品族中一个成员 

    abstract class AbstractProductB
    {
        public abstract void Interact(AbstractProductA a);
    }

    // 具体产品A1

    class ProductA1 : AbstractProductA
    {
    }

    // 具体产品B1

    class ProductB1 : AbstractProductB
    {
        public override void Interact(AbstractProductA a)
        {
            Console.WriteLine(this.GetType().Name +
              " interacts with " + a.GetType().Name);
        }
    }

    // 具体产品A2

    class ProductA2 : AbstractProductA
    {
    }

    // 具体产品B2

    class ProductB2 : AbstractProductB
    {
        public override void Interact(AbstractProductA a)
        {
            Console.WriteLine(this.GetType().Name +
              " interacts with " + a.GetType().Name);
        }
    }

    // 客户端，使用环境 

    class Client
    {
        private AbstractProductA AbstractProductA;
        private AbstractProductB AbstractProductB;

        // 构造，注意通过构造传入抽象工厂
        public Client(AbstractFactory factory)
        {
            AbstractProductB = factory.CreateProductB();
            AbstractProductA = factory.CreateProductA();
        }

        public void Run()
        {
            AbstractProductB.Interact(AbstractProductA);
        }
    }
}

输出结果为：

ProductB1 interacts with ProductA1
ProductB2 interacts with ProductA2

     生活中的实例：

     这个生活中的实例代码演示了一个电脑游戏，在游戏中建立不同的动物世界会使用不同的工厂。虽然创建动物的大陆工厂是不同的，但是动物之间的相互关系保持不变。

Real world code using Abstract Factory in C#
using System;

namespace DesignPatterns.Creational.AbstractFactory.RealWorld
{

    class MainApp
    {
        public static void Main()
        {
            // 创建非洲大陆
            ContinentFactory africa = new AfricaFactory();
            AnimalWorld world = new AnimalWorld(africa);
            world.RunFoodChain();

            // 创建美洲大陆
            ContinentFactory america = new AmericaFactory();
            world = new AnimalWorld(america);
            world.RunFoodChain();

            // 等待用户输入
            Console.ReadKey();
        }
    }

    // 抽象工厂
    abstract class ContinentFactory
    {
        // 创建食草动物
        public abstract Herbivore CreateHerbivore();

        // 创建食肉动物
        public abstract Carnivore CreateCarnivore();
    }

    // 具体工厂1
    class AfricaFactory : ContinentFactory
    {
        public override Herbivore CreateHerbivore()
        {
            // 返回牛羚
            return new Wildebeest();
        }

        public override Carnivore CreateCarnivore()
        {
            // 返回狮子
            return new Lion();
        }
    }

    // 具体工厂2
    class AmericaFactory : ContinentFactory
    {
        public override Herbivore CreateHerbivore()
        {
            // 返回野牛
            return new Bison();
        }

        public override Carnivore CreateCarnivore()
        {
            // 返回狼
            return new Wolf();
        }
    }

    // 抽象产品A
    abstract class Herbivore
    {

    }

    // 抽象产品B
    abstract class Carnivore
    {
        // 交互关系，食肉动物可以吃掉食草动物
        public abstract void Eat(Herbivore h);
    }

    // 具体产品A1
    class Wildebeest : Herbivore
    {

    }

    // 具体产品B1
    class Lion : Carnivore
    {

        public override void Eat(Herbivore h)
        {
            // 吃掉牛羚
            Console.WriteLine(this.GetType().Name +
              " eats " + h.GetType().Name);
        }
    }

    // 具体产品A2
    class Bison : Herbivore
    {

    }

    // 具体产品B2
    class Wolf : Carnivore
    {

        public override void Eat(Herbivore h)
        {
            // 吃掉野牛
            Console.WriteLine(this.GetType().Name +
              " eats " + h.GetType().Name);
        }
    }

    // 客户端
    class AnimalWorld
    {

        private Herbivore _herbivore;

        private Carnivore _carnivore;

        // 通过构造器传入具体工厂
        public AnimalWorld(ContinentFactory factory)
        {

            _carnivore = factory.CreateCarnivore();

            _herbivore = factory.CreateHerbivore();
        }

        public void RunFoodChain()
        {

            _carnivore.Eat(_herbivore);
        }
    }
}

输出的结果为：

     什么情况下使用抽象工厂：

文献【GOF95】指出，在以下情况下应当考虑使用抽象工厂模式：
1.一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。
2、这个系统的产品有多于一个产品族，而系统只消费其中某一个族的产品（上面这一条叫做抽象工厂模式的原始用意。）
3、同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。
4、系统提供一个产品类的库，所有的产品以同样的接口实现，从而使客户端不依赖于实现。

     实际项目举例

     现在需要创建分属于不同操作系统的视窗构件。比如命令按钮（Button）与文本框（Text）等都是视窗构件，在UNIX系统的视窗环境和Windows操作系统的视窗环境中，这两个构件有不同的本地体现，它们的细节也有所不同。在每一个操作系统中，都有一个视窗构件组成构件家族。在这里就是Button和Text组成的产品族。而每一个视窗构件都构成自己的等级结构，由一个抽象角色给出抽象的功能描述，而由具体子类给出不同操作系统的具体实现，如下图所示。

     可以发现在上面的产品类图中，有两个产品的等级结构，分别是Button等级结构和Text等级结构、同时有两个产品族，也就是UNIX产品族和Windows产品族。UNIX产品族由UnixButton和UnixText产品组成；而Windows产品族由WinButton和WinText产品构成。

     系统对产品对象的创建需求由一个工厂的等级结构满足，其中有两个具体工厂角色，即UnixFactory和WinFactory。UnixFactory对象负责创建Unix产品族中的产品，而WinFactory对象负责创建Windows产品族中的产品。这就是抽象工厂模式的应用，抽象工厂模式的解决方案如下图所示。

     显然，一个系统只能够在某一个操作系统的视窗环境下运行，而不能够同时在不同的操作系统上运行。所以，系统实际上只能消费属于同一个产品族的产品。这个案例实际上也正是抽象工厂模式的起源。实现的代码如下。

Project code using Abstract Factory in C#
// 抽象工厂起源案例

using System;

namespace DesignPatterns.Creational.AbstractFactory.Project
{

    class MainApp
    {
        public static void Main()
        {
            // 创建Unix使用环境
            OSFactory unix = new UnixFactory();
            Client client = new Client(unix);
            client.Run();

            // 创建Windows使用环境
            OSFactory windows = new WinFactory();
            client = new Client(windows);
            client.Run();

            // 等待用户输入
            Console.ReadKey();
        }
    }

    // 抽象工厂
    abstract class OSFactory
    {
        // 创建按钮构件
        public abstract Button CreateButton();

        // 创建文本框构件
        public abstract Text CreateText();
    }

    // 具体工厂1
    class UnixFactory : OSFactory
    {
        public override Button CreateButton()
        {
            // 返回Unix下的Button
            return new UnixButton();
        }

        public override Text CreateText()
        {
            // 返回Unix下的Text
            return new UnixText();
        }
    }

    // 具体工厂2
    class WinFactory : OSFactory
    {
        public override Button CreateButton()
        {
            // 返回Windows下的Button
            return new WinButton();
        }

        public override Text CreateText()
        {
            // 返回Winodws下的Text
            return new WinText();
        }
    }

    // 抽象产品A
    abstract class Button
    {

    }

    // 抽象产品B
    abstract class Text
    {
        // 交互关系
        public abstract void Interact(Button b);
    }

    // 具体产品A1
    class UnixButton : Button
    {

    }

    // 具体产品B1
    class UnixText : Text
    {

        public override void Interact(Button b)
        {
     
            Console.WriteLine(this.GetType().Name +
              " interact with " + b.GetType().Name);
        }
    }

    // 具体产品A2
    class WinButton : Button
    {

    }

    // 具体产品B2
    class WinText : Text
    {

        public override void Interact(Button b)
        {

            Console.WriteLine(this.GetType().Name +
              " interact with " + b.GetType().Name);
        }
    }

    // 客户端
    class Client
    {

        private Button _button;

        private Text _text;

        // 通过构造器传入具体工厂
        public Client(OSFactory factory)
        {

            _button = factory.CreateButton();

            _text = factory.CreateText();
        }

        public void Run()
        {

            _text.Interact(_button);
        }
    }
}

 输出结果为：

UnixText interact with UnixButton
WinText interact with WinButton

     小结

     抽象工厂模式是一个在实际项目中应用比较多的设计模式之一，抽象工厂模式面对的问题是多个产品等级结构的系统设计，运用抽象工厂模式的关键在于如果把创建产品的职责交给工厂去完成，希望大家在把握住工厂模式原型的基础上尽量的考虑到应用，形成一种思维上的定势。

      Welcome to share your idea,thank you!欢迎分享您的想法,谢谢!

      大家一起学面向对象设计模式系列 索引贴

评论: 8　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

     我们为什么要使用设计模式呢？有人可能会说为了设计出"高内聚低耦合"的软件。"高内聚低耦合"的软件实际上也就是本文所说的具有可维护性和可复用性的软件。

     这篇文章主要讲解两方面内容，这两方面是软件设计中很重要，也是很关键的内容，希望大家认真思考并深刻理解。第一部分就是关于软件的可维护性和可复用性的相关内容，第二部分就是在第一部分的基础上逐条讲解面向对象软件设计的基本原则，本文内容都是些很理论性的东西，这些理论是软件设计的基础。凡是有理论的地方，就有如何恰当的将理论应用到实践中去的问题，设计模式是对于学习OO设计原则的具体指导，也就是说设计模式就是将这些理论应用到实践的一种成熟的方式。

     软件的可维护性和可复用性

     首先来上一段大师所说的话，很经典。

“通常认为，一个易于维护的系统，就是复用率较高的系统；而一个复用率较高的系统，就是一个易于维护的系统。但是实际上，可维护性和可复用性是两个独立的目标，就像两只奔跑的兔子一样，并不总是方向一致的。对于面向对象的软件系统设计来说，在支持可维护性（Maintainability）的同时，提高系统的可复用性（Reuseability）是一个核心的问题。”－－《Java与模式》阎宏博士

      软件系统的可维护性：

     软件维护就是软件的再生。一个好的软件设计，必须能够允许新的设计要求以比较容易和平稳的方式加入到已有的系统中去，从而使这个系统能够不断的的焕发出活力。一个可维护性较好的系统，应当允许维护工作能够以容易、准确、安全和经济的形式进行。

【导致可维护性较低的原因】

1、过于僵硬：在系统中加入一个新的功能，不管大小都很难，不仅意味着建造一个独立的新的模块，而且因为这个新功能会波及很多其他模块，最后成跨越几个模块的改动。
2、过于脆弱：与软件的过于僵硬同时存在，是软件系统在修改已有代码时过于脆弱。对一个地方的修改，往往会导致看上去没有什么关系的另外一个地方发生故障。
3、复用率低：所谓复用，就是指一个软件的组成部分，可以在同一个项目的不同地方甚至另一个项目中重复使用。复用率低，指当一段代码，函数，模块的功能可以在新的模块或新的系统使用，但是已有代码依赖于其他很多东西，很难分开。
4、黏度过高：一个改动可以保存原始设计意图和原始设计框架的方式进行，也可以以破坏原始意图和框架进行。第一种方法对系统的未来有利，第二种办法是权宜之计，可以解决短期的问题，但是会牺牲中长期的利益。如果一个系统中使用第二种方法比使用第一种方法容易，那么就是黏度过高。

【设计的目标】

1、可扩展性：新的性能可以很容易地加入到系统中去，就是可扩展性。这就是系统“过于僵硬”的属性的方面。
2、灵活性：可以允许代码修改平稳地发生，而不会波及到很多其他的模块，这就是灵活性。灵活性其实就是“过于脆弱”的属性的方面。
3、可插入性：可以很容易地将一个类抽出去，同时将另外一个有同样接口的类加入进来，这就是可插入性。其实，这就是“黏度过高”的方面。

      软件系统的可复用性：

【软件复用的好处】

1、较高的生产效率；
2、较高的软件质量；
3、恰当使用复用可以改善系统的可维护性。

【传统的复用形式】

1、代码的剪贴复用；
2、算法的复用；
3、数据结构的复用。

【面向对象设计的复用】

在面向对象语言中，数据的抽象化，继承，封装和多态性使得一个系统可以在更高层次上提供可复用性。数据的抽象化和继承关系使得概念和定义可以复用；多态性使得实现和应用得到复用；而抽象化和封装可以保持和促进系统的可维护性，复用的重点转移到含有宏观商业逻辑的抽象层次上。在面向对象的设计里面，可维护性复用是以设计原则和设计模式为基础的。

     提高系统可维护性和可复用性的设计原则

1、“开－闭”原则(Open-Closed Principle，或者OCP)；

一个软件实体应该对扩展开放，对修改关闭；

在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。这个原则实际上是对“对可变性的封闭原则“：找到一个系统的可变因素，将之封装起来。这个原则意昧着两点：
1) 一个可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意昧着同一个继承等级结构中的具体子类。
继承就当被看作是封装变化的方法，而不应当被认为是从一般的对象生成特殊对象的方法。
2) 一种可变性不应当与另一种可变性混合在一起。（所有类图的继承结构一般不会超过两层，不然就意昧着将两种不同的可变性混合在了一起。）

这个原则是总的原则，其它几条是这个原则的手段和工具。

评论: 16　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

     大家好，几个月后我又开始写文章了，上一关于BlogEngine.Net的系列得到很多园友的支持,让我体会到了分享的快乐。这是我的新系列，主要是讲解GOF23种设计模式的文章。其实，这是一个被讲得很多的一个话题，博客园中关于设计模式的文章太多了，例如TerryLee的.NET设计模式系列等。不过好的东西不怕被讲烂，可能讲法不一样给大家带来的收获也不一样，对于我来说，其实基本上博客园中任何一篇文章都可以给我带来新的收获。

     我的这个系列对于那些大拿们可能觉得很无趣，但是对于一些刚刚接触设计模式，刚刚接触软件开发的新手们还是很有用的。设计模式是软件设计中很核心的知识，我刚开始接触时并没感到它到底牛在哪，时间久了就会发现它给你带来的震撼要比一般的技术多得多，经过再三思索，我决定本年度还是要把设计模式好好研究一下。

     为什么写这个系列

     干一件事总要有个目的吧！写文章也是，绝对不是三分钟热血，我写这个系列需要花费我很多的时间，总结起来目的有三：

1、主要想系统的学习一下设计模式（这里所说的设计模式特指面向对象的设计模式,下文类同）。要想灵活的应用设计模式，首先还是要深深的理解每种模式的原型，优缺点，适用的场景...，这样才能运用灵活。也就是说要想用好，就必须要学好（符合人类的认识世界和改造世界）。经过长久的设计与开发，我觉得设计模式是必须要掌握的，这才下定决心把它学好，掌握好，当然这里不是说要想掌握设计模式仅仅靠写几篇文章就可以实现的，文章也就是一个抛砖引玉的作用，更多系统的挖掘可能需要自己的领悟与实践。在这一系列中我会尽我最大的努力把每一种模式都写好，所以时间上可能不能一鼓作气。

2、分享给需要学习设计模式的园友们。如果你已经看了很多设计模式的文章，我相信你也会从这个系列中得到一定的收获。我这一系列主要是写给那些在设计模式门口徘徊的初学者的。尽量做到容易理解，讲解全面。

3、作为本人知识的积累，留在博客园中，我写的文章在我的电脑上其实没有做任何备份，我相信博客园可以永存。此外，这可能是我2009年唯一的一个系列。

     几个基本概念的区分

     模式:

     模式，即Pattern。其实就是解决某一类问题的方法论。把解决某类问题的方法总结归纳到理论高度，那就是模式。Alexander给出的经典定义是：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需再重复相同的工作。模式有不同的领域，建筑领域有建筑模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现很多模式。

     设计模式和面向对象的设计模式:

     设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式最初来源于建筑学。GOF（“四人帮”，指Gamma, Helm, Johnson & Vlissides, Addison-Wesley四人）的《设计模式》（1995年出版）是第一次将设计模式提升到理论高度，并将之规范化，本系列文章主要就是讲解这23种经典的设计模式。

     面向对象设计的模式，顾名思义，就是在面向对象分析与设计中使用的设计模式，GOF23种设计模式同时也是面向对象的设计模式，本文不做区分。良好的设计模式运用可以实现软件设计的“高内聚、低耦合”，提高软件的复用性和可扩展性。

     框架:

     框架，即Framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。

     架构：

     架构（Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。架构是一个系统的草图。架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

     一些刚入门的程序员经常会混淆“框架”和“架构”这两个名词，这里做了一下解释。

     文章如何组织

     这个系列文章首先从面向对象软件设计的基本原则出发，然后对GOF23种设计模式进行一一讲解（讲解过程中先讲解模式原型，常见变型，典型应用和模式分析，最后小结），在讲解的过程中可能会从某个有名的开源项目中抽取出采用相应模式的源代码讲解，以了解模式在实际项目中的运用。最后做一个大的总结。在对每一种模式讲解的文章中可能会与其它模式进行对比。

     整个系列文章将采用C#代码作为演示，IDE采用vs2005或vs2008。此外阅读本系列文章需要对UML有少许了解。

     系列文章的主要参考文献

 1、http://www.dofactory.com
 2、博客园中相关文章.
 3、《Java与模式》阎宏博士.
 4、《设计模式》 GOF.
 5、李建忠老师的Webcast视频课程.

     Welcome to share your idea,thank you!欢迎分享您的想法,谢谢!

     大家一起学面向对象设计模式系列 索引贴

评论: 8　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

大家一起学面向对象设计模式系列目录(更新中)

【PartⅤ】：总结与附录
      Chapter 26 本系列总结
      Chapter 27 附录－－61条面向对象设计的经验原则 

     Welcome to share your idea,thank you!欢迎分享您的想法,谢谢!

评论: 16　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

     我写这篇是由于看了小羊的"对技术的掌握到底应该有多深？"以及下面园友的评论加上自己对这一问题也有一定的看法,想表达出来与大家分享一下,同时也作为自己认识的一个记载.写的可能有些语无伦次,希望大家理解,有什么自己的想法大家可以评论.

     技术篇

     我基本赞同小羊对于"精通"二字的理解,实际上我也是这样理解它的.当你做了一年的时,你可能觉得自己做得已经很好了,觉得ASP.NET也就是那么回事,当你做了两年时你会发现不会的东西越来越多,当你做了n久以后你会发现几年前做的东西太烂了,为那时觉得自己很牛而感到可笑.那么什么才算"精通"呢?这个问题每个人理解得不太一样.我觉得"精通"有时还是可以写在简历上的,即使自己认为自己真的没有达到精通的地步,因为简历是写给别人看的,你要充分表达出你的长处,让别人了解你所擅长的技术,如果以为自己很谦虚而没有在自己的简历上写"精通"二字的话,而看简历的人不是真正的技术出身(或者做的技术不是很久或者不是很牛),那么你的简历很有可能直接的被pass掉(除非你遇到了传说中的伯乐,直接看出你得简历写很谦虚,认为你深藏不露).我有一次被面试的经历:去年去一家小公司面试,那个面试的人一直问我是否对ASP.NET已经很精通了(他们要的可能是比较高级一点的程序员),而我简历上确实没有写"精通"二字,于是我只好和他解释说"精通这个词我们理解的可能不太一样",其实一个程序员的素质也不是几个面试题就可以考验出来的(面试题网上多的很),于是以后我就直接在简历上也写上了"精通"二字,实际上我到底是什么水平只有我自己知道.在面试中就是尽可能的展现自己的长处,实际上"精通"二字已经被滥用了.大家可以使用,但是最好不要动不动就用,也要把握好一个度的问题.

     方法篇

     一个优秀的程序员是很值得我们去追求的.对于技术知识的把握我们也需要按需所取,计算机以及相关领域的技术太多了,我们只要擅长自己所需要的技术就行了,对其它一些技术是要大概了解一下,需要时再去学习.在四年大学生活和两年的工作中我懂得了比学习知识更重要的是培养自己分析问题和解决问题的能力(人类就是在不断的通过使用工具来认识世界和改造世界),培养自己的兴趣和爱好,这些东西要胜过知识本身.所以我们在学习技术时不仅要知道How,更要知道What和Why.这几年我一直在做.NET平台上的研究与开发,最近几天有空研究了一下Java方面的东西,在看一些资料时有一种非常亲切的感觉,好多东西基本差不多,包括实现的思想等,可能这就是学习的能力带给我们的好处吧.相反,就在前几天看到一个很基础的面试题时,我也有一种很熟悉但是就是不能准确的回答正确的感觉,实际上已经由于总也不用给忘了(有点类似于记忆性的题目).知识可能随着时间的推移而被慢慢的淡忘,而能力确永远属于自己.

     生活篇

     在小羊的"对技术的掌握到底应该有多深？"的评论中,有一个未注册网友的评论我觉得很经典,他是这样说的"技术当然越精通越好，但人的精力是有限的，工作的分工是变化的，如果你有时间你可以学得更多，但同时你也需要一定的生活享受，爱情、婚姻、家庭以及对社会的参与，你把大多精力放到学习上也不一定表示你多伟大，也许这样之后你成了一个技术大牛，有一定的价值感，但同时你也许就成为一个不合格的男友（或女友）、不合格的丈夫（或妻子）、不合格的儿子（或女儿）等等，所以兄弟姐妹们，除了这个物质不是很丰富的社会需要我们努力学习技术，同时我们更应该学会平衡一些东西，学会学习学会生活，如果说硬要说技术需要掌握多深，我的答案是----在你的追求环境和现实环境中，够用就行！（因为你还需要其他的东西）".写的很好,这和我想的一样,但是我就表达不出来,人生短暂,我们不能每天都为了自己的工作,为了自己的发展而放弃对其他方面的追求,"机会成本"这个词语大家都很清楚,我也经常和女朋友讲这方面的东西.你得到了这个东西,同时也就放弃了另一个东西.除了去专研技术,攻克技术难题的工作上的事情外,还有很多事情我们可以做,也等着我们去做好(无论你是否愿意).人的成功是多方面的成功,这样你才会成为大家的楷模,成为别人的偶像(例如菲尔普斯吸食大麻被禁止,因为他已经成为了很多人的偶像,不良的做法会影响到很多人,同时他也不是成功的人.还有很多影视明星等,以前我只觉得他们电影等演的好就行了,但是现在我也不那么认为了,我也很少关注他们了).我认识一个哥们也是做我们这行的,他就特别忙,他本身也特喜欢工作,每天工作从8:30一直到晚上11:00才睡觉,除了吃饭的时间基本都在工作,周末一般也会加一天的班,事业上可能比较成功,去年他有个女朋友也是由于时间问题和他分手了,我也曾经给过他一些这方面的建议.生命真的很短暂"眼睛一闭一睁一天过去了,眼睛一闭不睁一辈子过去了",我们需要让生命更加多彩.这些需要我们自己把握.

     总结

     人的生活是一个过程,不是一个结果(最终结果就是死亡,你的名字可能会流芳百世,但是迟早会被人们所遗忘).如果有人让我现在立即就成为比尔盖茨,我可能不会接受,我希望经过自己努力去实现,因为我需要体会这个过程.也就是体味人生.

评论: 25　查看评论　发表评论

最新新闻：
· Yahoo脑震荡 关闭服务汇总贴(2010-02-10 12:06)
· 2003年微软遭遇iTunes：我们彻底晕头转向了(2010-02-10 12:06)
· 百度数据能被“作弊”软件篡改？百度:追究侵权(2010-02-10 11:52)
· Ksplice为Linux提供永远不用重启服务(2010-02-10 11:51)
· 视频网站2010年格局之变：七成企业将被淘汰(2010-02-10 11:48)

编辑推荐：Google社会化产品Buzz发布会实录

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库