<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/abc" -->
<rss version="0.92">
<channel>
	<title>Mingbo</title>
	<link>http://shao.mingbo.de</link>
	<description>包括教育技术，编程，互联网等方面的文章及随想。</description>
	<lastBuildDate>Sun, 25 Jul 2010 05:18:53 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>洪水来袭</title>
		<description><![CDATA[媒体连篇累牍的报道，让人也想跃跃欲试，看看洪水来袭的武汉究竟变成了怎样。在骆大师的点化下，我决定这个周末不再继续宅下去&#8230;我决定，顶着炎炎烈日&#8230;记录一下这个特殊日子。于是便有——

拍摄路线：汉口江滩-长江大桥-武昌
拍摄时间：2010/07/25
拍摄主题：洪水来袭后的武汉
拍摄机器：Canon 400D / EF 24-70 2.8L
拍摄伙伴：骆大师&#8230;





更多精彩照片，点这里
]]></description>
		<link>http://shao.mingbo.de/2010/07/25/2010-flood-record/</link>
			</item>
	<item>
		<title>如何解决“连接被重置”的现象</title>
		<description><![CDATA[已经不记得从什么时候起，使用Google 老爱被连接重置。有人总结了一下，目前搜索包含“吴”、“温”、“贾”、“李”、“习”、“贺”、“周”、“胡”等字的词语，会出现上述现象。这导致一些很常用的词语，例如“学习”、“胡萝卜”、“温度计”等无法在Google 搜索。具体的原因，本文不做详解，有需要的朋友请在本文指导下解决“重置”问题之后，进行深度搜索，方可获得解答。
Google 最近启用HTTPS 加密搜索服务。Google在官方博客介绍说，普通的HTTP浏览是不安全的，用户和服务器之间的通讯会被第三方监听和干扰，对于Google来说，你在Google搜索的词语会被第三方截获，如果第三方不希望你在Google搜索这个词语，还可以通过技术手段阻止用户的搜索行为。这也就是Google发布的beta版本的SSL加密搜索的原因，在HTTPS的Google搜索中，用户搜索的信息将无法被第三方获取，也不会出现数据泄漏的问题。目前HTTPS的Google搜索覆盖了Google网页搜索的部分产品，目前还不支持图片搜索和地图搜索，而其他搜素（资讯、博客、视频、动态等）都支持。
那关键问题是如何解决标题这个问题呢？不同的浏览器有不同的解决方案，请参见月光博客的这两篇博文：
Chrome 浏览器：Google支持HTTPS加密搜索
Firefox 和 IE8 浏览器：Google SSL搜索在FireFox和IE8中的解决方案
]]></description>
		<link>http://shao.mingbo.de/2010/05/23/how-to-resolve-be-gwfed-when-using-google/</link>
			</item>
	<item>
		<title>《当幸福来敲门》观后感</title>
		<description><![CDATA[
From the opening scene to the end, I was so moved by the love that Chris has for his son. It makes me to rethink about the meaning of happiness:
Happiness means a temperamental predominance of courage over timidity, of the appetite for adventure over the love of ease. So, No matter how bad the surrounding [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/16/the-pursuit-of-happiness/</link>
			</item>
	<item>
		<title>设计模式学习总结</title>
		<description><![CDATA[这段时间更新了很多篇有关设计模式的学习笔记，收获不算太多，但起码让我对面向对象编程有了一个更深刻的认识。模式与模式之间没有界限分明的三八线，也没有一个万能的模式主宰了Programmer 的编程思维。模式学习到最后，Visitor 与Strategy 的笔记也实在没有动力更新下去，只打算在这篇设计模式笔记的大总结里，稍作复习。
不要问我还记得哪些模式的哪些细节，他们无非是，1）面向接口编程；2）使用对象组合来解耦，努力避免继承；3）在易碎变化的地方进行封装。把面向的对象的精髓“封装、继承、多态”发挥到一定境界，就是模式了。
在学习设计模式之前，其实还有一点畏惧的情绪在里面。学习的过程中，发现，这样的模式，全然都是前辈们的经验。学习完之后，感觉自己还是内功不够，比如：数据结构。虽然，目前把这些模式都领略了一遍，但可以很清楚的意识到很多内在的精髓不一定内化到自己的脑袋里。今后在工程中可能还需要回过头来重新学习。这里把一个提纲式的笔记列一下：

创建模式


Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。
Factory Method, Abstract Factory, Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。



结构模式


Adapter模式注重转换接口，将不吻合的接口适配对接
Bridge模式注重分离接口与其实现，支持多维度变化
Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系
Decorator模式注重稳定接口，在此前提下为对象扩展功能
Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系
Flyweight 模式注重保留接口，在内部使用共享技术对对象存储进行优化
Proxy 模式注重假借接口，增加间接层来实现灵活控制



行为模式


Template Method模式封装算法结构，支持算法子步骤变化
State模式注重封装与状态相关的行为，支持状态的变化
Memento模式注重封装对象状态变化，支持状态保存/恢复
Mediator模式注重封装对象间的交互，支持对象交互的变化
Chain Of Responsibility模式注重封装对象责任，支持责任的变化
Command模式注重将请求封装为对象，支持请求的变化
Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化
Observer模式注重封装对象通知，支持通信对象的变化
Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作。
Strategy模式注重封装算法，支持算法的变化
Iterator 模式注重封装集合对象内部结构，支持集合的变化


这段时间的学习告一段落，我想，这更是一个新的起点，对于如何阅读、学习别人的代码，会有很大的提升。

]]></description>
		<link>http://shao.mingbo.de/2010/05/09/design-pattern/</link>
			</item>
	<item>
		<title>初尝State 模式</title>
		<description><![CDATA[当对象拥有不同的状态，往往会导致行为不同。在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？
意图
允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。
结构图

话说，状态的改变也能用if-else 来完成逻辑演绎，但如果系统中增添了新的状态，则耦合的代码，就显得疲惫不堪了。如果状态很多，程序员自己也很难维护。这里的state 模式，将状态改变时影响的行为抽象到一个类里，用一个个具体的子类来表达不同的状态，从而很好的封装了变化点。
代码

using System;

namespace State
{
    class Program
    {
        static void Main(string[] args)
        {
            Document doc = new Document();
       [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/06/state-pattern/</link>
			</item>
	<item>
		<title>初尝Memento 模式</title>
		<description><![CDATA[在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。
意图
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。
结构图


其实结构图中Caretaker 不一定必须实现，不难发现的是，他是对“备忘录”中保存的状态的起到一种暂存的作用。下面是一段代码：

using System;
using System.Collections.Generic;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;

namespace Memento
{
    class Program
    {
        static void Main(string[] args)
        {
            Person A = new Person("A");
     [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/06/memento-pattern/</link>
			</item>
	<item>
		<title>初尝Chain Of Responsibility</title>
		<description><![CDATA[在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。
意图
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
结构图

职责链模式在其内部实现了一个自我的链式结构，采用了和Decorator 模式一样的方法，不但继承了自己，还要包含自己。下面的代码，模拟了一个公司处理订单的业务逻辑，多少金额内，什么级别的人可以处理。
代码

using System;

namespace Chain_of_Responsibility
{
    class Program
    {
        static void Main(string[] args)
        {
            Purchase p = new Purchase(2012,9678.89,"Diamond For Women");
      [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/05/chain-of-responsibility-pattern/</link>
			</item>
	<item>
		<title>初尝Observer 模式</title>
		<description><![CDATA[观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
意图
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
结构图
从具体主题角色指向抽象观察者角色的合成关系，代表具体主题对象可以有任意多个对抽象观察者对象的引用。之所以使用抽象观察者而不是具体观察者，意味着主题对象不需要知道引用了哪些ConcreteObserver类型，而只知道抽象Observer类型。这就使得具体主题对象可以动态地维护一系列的对观察者对象的引用，并在需要的时候调用每一个观察者共有的Update()方法。这种做法叫做&#8221;面向接口编程&#8221;。
实际上在C#中实现Observer模式没有这么辛苦，.NET中提供了Delegate与Event机制，我们可以利用这种机制简化Observer模式。下面我会用一段代码同时演示2种模式。
代码

using System;
using System.Collections.Generic;

namespace Observer
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("------------------------------");
           [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/04/observer-patter/</link>
			</item>
	<item>
		<title>初尝Mediator 模式</title>
		<description><![CDATA[在日常生活中，我们经常会遇到多个事物相互之间都有联系的例子。例如：聊天室。
在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
意图
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
结构图

在这里，我们模拟一个聊天室的程序，用户既可以对特定的对象进行发送消息，也可以向所有人say hello。我们用一个mediator 对象进行管理他们之间的联系。值得指出的是，代码中，仍有值得抽象的接口。
代码：

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

namespace Mediator
{
    class Program
    {
        static void Main(string[] args)
        {
            ChatRoom cr = new ChatRoom();
    [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/04/mediator-pattern/</link>
			</item>
	<item>
		<title>初尝Interpretor 模式</title>
		<description><![CDATA[这个模式，一般用的很少。通常一个解释器，都会有专门的对象或者更底层（更高效）的工具来解决相应的问题。但有通常，就会有特殊的情况。当我们需要剖析某个具有结构性的对象，而这个对象并没有那么庞大时，就可以采用Interpretor 模式。
意图：
给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。
结构图：
 

这个模式让我纠结了几天。原因不在理解这个模式本身，而是老师在课堂举的一个解释器的例子（将汉语数字转换成阿拉伯数字。比如：九千一百二十万六千三百二十一 &#8211;&#62;91206321 )这样的计算处理，不用设计模式，也能实现。但，使用了设计模式，可以在代码复用以及一些小型的语法处理问题得到很好的效果。当然最后还是实现了，但这充分说明，自己实现一个解释器，并不容易。
在写代码的过程中，我有尝试从最高位向低位来转换，但发现后期扩展就受到了这个方向的限制。所以，我得出了一个不完全的总结，就是在使用Interpretor 模式的过程中，应该先从最小的单位单元（个位）进行，然后依次递增。
代码：

using System;
using System.Collections;
using System.Collections.Generic;

namespace DesignPattern
{
    class Program
    {
        static void Main(string[] args)
        {
            //初始化翻译数据...
      [...]]]></description>
		<link>http://shao.mingbo.de/2010/05/01/interpretor-pattern/</link>
			</item>
</channel>
</rss>
