随兴所至

丽江回忆

随兴所至 — Mon, 4 May 2009 17:36:36 +0800

    四月的丽江乍暖还寒，特别是孤身走在古城的小巷，灯火明明灭灭，月色冷冷清清，分外觉得夜凉如水。
    古城之旅本该是热闹喧哗的，在酒吧街，魅惑的红灯笼映着熙熙攘攘的人群，震耳的重音乐伴着疯狂扭动的肢体，醉生梦死中展开一段段的艳遇。可这跟父母告诉我的不一样，他们说的丽江酒吧是这个模样：坐在水边，喝着小酒，两边有人对歌，唱的是他们那个年代的流行歌曲，像赞歌之类，唱到兴起，还有人爬到屋顶上高歌，微凉风中祥和喜乐，悠然自得。他们还说，没有到过酒吧街，就没到过丽江。于是，为了寻找父母口中的酒吧街，我顺水而行，走过四方街、大石桥、百岁桥、关门口、天雨流芳，渐渐迷失在幽暗的巷子里。走在青石板上，忽然想起外婆家，那个小镇也是青石板路，那些青石板也被风被雨被岁月摩娑得光滑洁净，多少年没回去，每一个转弯每一道台阶都还那么分明，哪像眼前的路，越走越是陌生。
    每座城市都是类似的吧，街道，房子，行人，只有回忆，才让一座城市在心中鲜活生动，与众不同。丽江是一座闲适的城市,在这里，很容易就遇上一些人，发生一些事，也许只是相伴一段路，或者合唱几首歌，在心上就划上了淡淡的痕。当时光模糊了音容笑貌，反倒清晰了某段路程，就像亦舒的《邂逅》，“但是我记得巴黎，巴黎对我来说是再熟没有的一个地方，从蒙马特走到圣米雪儿，可以走上三个小时，或是四个小时，走累了，可以随时坐在地下休息。”巴黎或者丽江，都浪漫得足以承载着我们期盼的悸动与激情。
    我想，我是找不到父母所说的丽江酒吧了，那是属于他们的记忆。而我，还在寻找属于我的丽江回忆。

丽江的真谛在于把生活这颗洋葱一层一层的剥，最后只剩下闲而已

魅惑的红灯笼

幽深的小巷

诗画为翼，梦想起飞

随兴所至 — Fri, 29 Dec 2006 13:57:40 +0800

    前几天，有位朋友让我看看他们为潮州制作的电子杂志，这也是他们在一个活动“寻找最佳制作人”的参赛作品。
    杂志展示了潮州的风土人情，将潮州的山光水色，名景胜迹融入一幅幅画卷，每一展开，总是令人惊叹的美不胜收。杂志以浅灰微黄的宣纸为底，仿佛承载了历久弥新的岁月；斜阳夕照下暮色苍茫的潮州是来自远古的，北阁佛灯与韩祠橡木蕴含着浓重的文化气息，而幽深的小巷中一双双古旧的门环后，也许都有一个关于怀旧的故事；春光明媚中欢声笑语的潮州是新鲜活泼的，街头一抹抹绿色是青春飞扬的脚步，历史悠久的木雕潮绣也焕发着崭新的光彩。特别喜欢画面的过场，或是在纸上一笔大泼墨，然后画面在墨痕处冉冉浮出；或先展现隔着雾蒙蒙的窗子观赏的小桥流水，然后仿佛有水滴打在窗上，一滴一滴地，朦胧的画面渐渐清晰，原来是影动波摇的西湖渔筏。诗情画意之中乐声悠悠，高亢处雄伟壮丽，低回时柔情似水，映衬着古城在岁月沉淀中散发的夺目光华。
    这个作品已经配套光盘作为地面的辅助宣传，反映很不错，政府也大力支持，并且他们还打算与平台合作，以电子杂志的形式更有效地推广企业与产品。他的梦想是“让电子杂志多元化多层次出现在这个地球村”，为此，他们将会用更好的互动手法打造各种内容，包括企业，区域文化/经济/现状等，使更多的人清晰地了解内容，同时，也是一次体验与娱乐。
    能够确定自己的梦想是一件快乐的事，而具备追求梦想的能力，并且正在这条路上努力着，那更是一件幸福的事，祝愿他能梦想成真。
    有兴趣观看的朋友可以到如下地址下载：http://huodong.zcom.com/mags/20061211165738700.exe   ;如果你愿意投上一票，地址为：http://huodong.zcom.com/topoll.php?id=133

《Head First Design Patterns》分享（九）----迭代模式与合成模式

随兴所至 — Sun, 24 Dec 2006 02:11:28 +0800

    餐馆开张啦！服务员打印一份漂亮的菜单当然是刻不容缓了，但是，由于历史原因，晚餐的菜单是用数组存储的，而午餐的菜单是用链表存储的，如何访问这两份菜单呢？一个比较直观的方法是分开处理，服务员对晚餐菜单用其提供的数据结构和访问访问来处理，对午餐菜单用其提供的另一种方式。能否将这两份菜单统一一个处理模式？无论是数组还是链表，我们要访问其所有的元素都需要遍历，从第一个元素开始访问，然后是下一个，直到遍历所有的元素。将 iterator指向第一个元素，可以将访问步骤抽象成：
    while(iterator.hasNext()){
     iterator.next();
    }
    为了实现这种模式，首先要创建一个接口Iterator类，声明这两个方法hasNext()和next()给服务员统一调用。然后派生出DinerMenuIterator类和LunchMenuIterator类，DinerMenuIterator类实现用数组方式完成这两个方法，而LunchMenuIterator类实现用链表方式完成这两个方法，这样就把数据结构的差异隐藏起来了。为了通过DinerMenuIterator访问DinerMenu，需要DinerMenu类提供一个方法，例如createIterator,返回用其数据初始化的DinerMenuIterator的实例。服务员要打印晚餐菜单，首先调用DinerMenu的createIterator方法取得Iterator(其实是DinerMenuIterator），然后调用Iterator的hasNext和next方法来遍历(当然了，实际调用的是DinerMenuIterator的hasNext和next方法，基于数组的访问模式)。这就是迭代器（Iterator）模式。
    原本晚餐菜单上是一项项独立的项目(MenuItem)，现在，晚餐的菜单扩充了，增加了甜点，并且甜点有很多种，组成了甜点菜单（Dessert Menu），甜点菜单下才是独立项目。如何打印这样的菜单？当然，我们也能分开处理，遍历的时候判断其类型，如果发现不是独立项目，而是菜单，则访问该菜单下的项目。能否也将菜单和菜单项统一处理呢？为了达到这个目的，我们要定义的对象，应该既可以表达菜单，又可以表达菜单项。为此，我们需要抽取其公共行为和属性来构造这样的对象。既然我们要打印菜单，那么无论菜单还是菜单项都有公共行为print(),因此父类（MenuComponent）需要声明print()函数，然后派生出Menu(菜单)类和MenuItem(菜单项)类，它们分别要实现print()方法。对于MenuItem，print相当简单，直接输出就可以，但是对Menu就不同了，它需要递归打印出它包含的所有项（可能是菜单，也可能是菜单项），如下所示：
public Menu extends MenuComponent{
ArrayList MenuComponents=new ArrayList();
//other code
public void print(){
  iterator iterator =MenuComponents.iterator();
  while(iterator.hasNext()){
   MenuComponent newNode=(MenuComponent)iterator.next();
   newNode.print();
  }
}
}
    服务员要打印晚餐菜单，只需调用Menu的print函数，iterator会对MenuComponents的每一项依次访问，如果newNode是菜单项，则调用菜单项的print函数，直接输出，如果newNode是菜单，则调用菜单的print函数，依次访问newNode的每一项，直到完成，再访问与NewNode同层的下一个结点。这就是合成（composite）模式。（树的深度遍历，呵呵）
    考虑到晚餐菜单和甜点菜单的数据结构可能是不一样的，因此我们需要将Iterator模式应用到合成模式。可以从Iterator类派生出MenuComponentIterator类，MenuComponentIterator类当然也要实现hasNext和next方法。如果一个菜单只包含菜单项，那是很好判断的，根据数据结构判断既可，就像我们一开始讨论的DinerMenuIterator类和LunchMenuIterator类，但现在菜单可以包含菜单，这就麻烦了。一个子菜单Node包含的所有对象（包括菜单和菜单项）遍历完成后，并不意味着整个菜单遍历完成，我们必须返回到Node，判断它的后面是否还有对象。因此我们在实现这两个方法的时候，需要使用堆栈，访问菜单包含对象之前要把菜单先入栈，当某个菜单所包含的对象访问完毕，要弹出之前记录的菜单，继续访问，直到堆栈为空。

《Head First Design Patterns》分享（八）----模板方法模式

随兴所至 — Fri, 22 Dec 2006 12:51:09 +0800

    冲泡一杯咖啡的过程如下：煮水，放咖啡粉，倒进杯子，加牛奶白糖；冲泡一杯茶的过程如下：煮水，放茶叶，倒进杯子，加柠檬汁。我们当然可以分别实现这两个类，但是由于这两个类有如此多的共通之处，我们可以将其抽取出来作为父类，再派生出咖啡类和茶类。显然可以将煮水和倒进杯子这两个动作放进基类。但，这就够了吗？重新审视这两个流程，可以发现它们的步骤很相似：煮水boilwater，放冲泡物brew（咖啡放的是咖啡粉，茶放的是茶叶），倒进杯子pourincup，加调味料addcondiments（咖啡放的是牛奶白糖，茶放的是柠檬汁）。因此父类封装这个步骤，并且固化，不允许子类加以修改，使得父类的核心功能更明确。对于子类都共有的方法，如煮水和倒进杯子，父类也将其实现；而放冲泡物和加调味料这两个步骤则由子类自行决定如何进行。
    子类也可能需要调整步骤，例如柠檬茶在加了调料后，可能还会在杯子上放片柠檬来装饰。我们也许可以在柠檬茶类的addcondiments的函数中实现
public void addcondiments{
AddLemon();
Decorate();
}
    但这不是一个好主意，在放调料这个步骤里面同时装饰了杯子是很难理解的事情，并且往往不为其他类所知，在被调用的时候也许会产生一些不可知的错误。因此，装饰作为一个步骤，应该被父类连同其他步骤一起封装，并且是可选的。如下面的函数：
protect void prepareRecipe(){
boilWater();
brew();
pourInCup();
addCondiments();
if (wantDecorate()){
  decorate();
}
}
boolean wantDecorate(){
return false;
}
    这个wantDecorate()就是一个钩子(hook),子类可以完成这个hook,实现相关步骤，也可以忽略它。从而提高了子类的灵活性。
    这里还体现了一个法则“Don't call us,we'll call you”!这个法则的意思是：低层次的组件（例如子类）不应该调用高层次的组件（如父类），因为由低层次的组件调用高层次组件是比较难理解的，而应该由高层次组件来调用低层次的组件。通过模板方法模式，是可以由父类决定何时何地如何调用子类的。

《Head First Design Patterns》分享（七）----适配器模式和外观模式

随兴所至 — Thu, 21 Dec 2006 10:09:18 +0800

    在使用电器的时候，我们可能会遇到电源插头是三相的(client)，但插座是两级的情况(Adaptee)，此时我们需要一个从三相到两相的适配器(Adapter），从而使得电器可以通上电。程序设计也类似，客户（client）调用需要一个功能，例如Duck类的quack();但已有的功能（Adaptee）的名字或者参数与接口需求不一致，例如已有方法是Turkey的gobble（）。为此我们需要设计一个类，作为适配器（Adapter）。
    一种方式是这个类继承Duck类和Turkey类，例如：
    public class TurkeyDuck:Duck,Turkey{
      public void quack(){
      gobble();
      }
    }
    这种方式称为类适配器模式，同时还可以使用对象适配器的方式，这种适配器不是使用继承而是委托：
    public class TurkeyDuck:Duck{
      private Turkey trukey;
      public TurkeyDuck(Turkey _trukey){
        turkey=_trukey;
      }
      public void quack(){
        turkey.gobble();
      }
    }
    两种方法的区别是：
    类适配器，继承已有的类，并实现接口，也就是把客户发出的调用翻译为对已有类的方法的调用；
    对象适配器，它使用已有的类的实例，将客户发出的调用转发给已有类的实例。
    一般而言，对象适配器的耦合度较低，不但可以实现Adaptee的接口，还能实现其子类的接口。例如Turkey作为父类，派生出两个子类，Turkey_SoundLong和Turkey_SoundShort,他们都重载了gobble方法，Turkey_SoundLong每次5秒，Turkey_SoundShort每次3秒，要适配哪个只需将相应的类的实例用来初始化TurkeyDuck即可；如果用类适配器，则必须分别为3个类写适配器，因为每个gobble都不一样，不这样做无法确定使用哪个行为。虽然组合了父类对象适配器是可以转换父类和子类，但当子类引入了新的行为，该对象适配器是不能访问的，只能组合子类创建一个新的适配器。
    当然了，由于对象适配器没有继承Adaptee，因此不能重载Adaptee的方法。

外观模式是比较好理解的，例如洗衣机有多种功能，强洗，弱洗，浸泡，脱水，烘干，每个功能都可以单独使用，但一般而言用户可能使用弱洗--脱水--烘干三个功能组成的程序，为了便于使用，可以定义一种洗涤模式，就是依次执行弱洗--脱水--烘干三个功能，这样用户使用起来就比较方便。

《Head First Design Patterns》分享（六）----命令模式

随兴所至 — Wed, 20 Dec 2006 13:24:08 +0800

    假设我们需要实现一个遥控器。遥控器上有N个放射器，每个放射器可以控制某种家用电器，例如灯光，电视，音响等，每个放射器由两个按钮ON/OFF控制。对于灯光，按下ON，灯光打开；按下OFF，灯光熄灭。对于音响，按下ON，接下电源，放进唱片，自动播放；按下OFF，停止播放；退出唱片，关掉电源。
    一个比较简单的实现是，每一个按钮是一个类，按下ON按钮时，判断对应放射器控制的是灯光还是音响，从而调用不同的动作。显然，这样的判断比较烦人，最好是无论按下哪个按钮，都调用同一个类的同一个方法，至于是什么类，运行时决定。也许我们可以创建一个家用电器类，定义虚函数on和off,派生出灯光类和音响类等，并实现其自有的on动作和off动作；然后每一个放射器都对应一个家庭电器类，按下on/off按钮，分别调用家庭电器类的on/off函数。
    但是，假如灯光类、音响类等都是固定了，不但不会从家庭电器类派生，甚至不能增/减属性和行为，怎么办呢？
    将遥控器简化为只有一个按钮，只有一个放射器，控制灯光。当按钮按下，发射器向灯光发出命令，灯光点亮。这里面看上去只有两个实体，遥控器（包括按钮和发射器），灯光，但是，联想到我们曾经将鸭子的fly行为抽象成一个类，这里我们也可以把命令抽象成一个类。因此，一共有3个类，Light，LightCommand，RemoteControl。类Light中包括灯光的属性和行为。LightOnCommand提供execute函数，调用Light.on()来开灯。由于发射器的功用就是发出一组命令，因此可以绑定到LightOnCommand。RemoteControl提供按钮按下事件OnButtonPressed，调用发射器的execute函数，由于发射器绑定到LightOnCommand，因此实际调用的就是LightOnCommand提供的execute函数，调用Light.on()来开灯。
    现在我们加上OFF按钮，如何实现按下ON，灯光打开；按下OFF，灯光熄灭？显然ON命令和OFF命令是一类事物，因此可以创建COMMAND类，声明一个函数execute,派生出LightOnCommand类和LightOffCommand类，LightOnCommand类调用Light.on()来开灯，LightOffCommand类调用Light.off方法()来关灯。因为存在两组命令，RemoteControl定义两个COMMAND类的发射器，提供SetCommand函数，将发射器OnCommand绑定到LightOnCommand,OffCommand绑定到LightOffCommand，而on按钮按下事件OnButtonPressed调用Oncommand的execute函数，off按钮按下事件OffButtonPressed调用Offcommand的execute函数。
    当存在多个发射器与按钮对时，只需定义Oncommand和OffCommand数组，调用按钮事件时传入序列即可。注意一点，可能有些发射器还没有与家电建立联系，这时候必须加上检查，以免调用了不存在的对象的execute函数，一个技巧是缺省为所有发射器关联上空对象NoCommand.
    下面我们尝试为遥控器增加UNDO功能，也就是在遥控器上增加UNDO按钮，按下UNDO按钮，则将最后一次改变家电状态的操作消除。显然UNDO也是一种命令，因此我们在COMMAND类上增加undo函数，LightOnCommand类的undo函数就是调用Light.off方法()来关灯，从而实现反向操作。同时，RemoteControl类当然也要提供UNDO按钮按下事件UndoButtonPressed函数，但是当有多个发射器存在的情况下，究竟应该调用哪个发射器的反向函数呢？所以需要定义一个格外的命令变量，记录最后执行的是哪个命令实例，从而调用它的undo函数完成反向操作。对于灯光，反向操作只有开/关，但是对某些电器，可能有几个状态，例如风扇，可能从1档调到了3档，那么反向操作就是从3档调回1档。要实现这个操作，需要将旧状态记下来，并改动FanOnCommand类和FanOffCommand类的undo函数。如果需要多次undo,那么需要建立一个堆栈，将每次操作的命令变量记下，依次恢复。
    最后，考虑一下，如果希望一个发射器可以控制多个家电，即按下ON按钮，开灯开音响，按下OFF按钮，关灯关音响。我们当然可以在为此建立一个命令类，在execute函数集合相关的命令，但这样不够灵活。一个较好的方法是对每个家电都建立一个发射器。从COMMAND类派生出PartyCommand类，处理COMMAND数组，在execute函数依次调用各种家电的命令。

TOP KTV 腐败记

随兴所至 — Tue, 19 Dec 2006 13:52:10 +0800

    今晚，偶们同事几个打算去腐败一把，经过讨论，终于选定了TOP KTV,原因如下：
    一、地理优势，离我们公司比较近，PK掉了钱柜和金矿；
    二、价格优势，有人自愿请客，TOP KTV的价钱刚好比他愿意花的少一点点（超出部份就偶们掏钱包了哦）；
    三、心理优势，同事有VIP卡，持VIP卡四人以上就免掉女士的自助餐费，方便VIP们泡MM啊；
    四、最最重要的是，偶没去过这间，正好尝尝鲜啊！

    偶们一行七人杀到KTV，发现房间都比较小，要了个中房（8~10人）也不觉得宽松，茶几与电视之间的距离那个窄啊，大概也就站一个人。吃的东西也极少，而且都很普通，虽然都有小吃/小炒/点心/凉拌之类，但种类都不超过五种，尤其是汤啊，就罗宋汤和西洋菜汤！而且拿完了补充也非常不及时的说！吃饱喝足之后，我们开始研究点歌系统，遥控器只能输入数字来点歌，但是又没有歌簿；歌星列表就密密麻麻一排，极其难找；新歌菜单上好多歌名字都没听说过，偶认识的一两首是2002左右的，点歌榜上的歌曲也是千奇百怪，于是我们发挥专业精神，每个页面都浏览了，并且热烈讨论后形成了改造意见，差点想当场写份需求分析书跟经理谈谈合作意向！唯一贴心的设计是墙壁上，遥控器上，点歌台上都有切歌按钮，如果哪位的歌声实在让偶的胃翻江倒海，可以“不小心”地让手碰碰按钮，呵呵！
    我们都很谦虚地让埋单的同事先唱，他连连摇头“不行不行，我不会唱”，我们连忙说“没关系没关系，你唱了我们都有信心了”，结果他说“我不是唱得不好，是确实不会唱，我还是第一次来KTV”。偶们全体晕倒。虽然是处男下海，偶们也不放过他，因为他女朋友也在，于是强行点了纤夫的爱要他们对唱，结果那家伙笑得像狗头，就是一句话也哼不出来，倒是他女朋友暴强，一人分饰两角，包办了整首歌，仰慕啊！
    偶去KTV也不少，无论鬼哭式还是狼嚎式都能处之泰然，对于那些保留曲目，例如水手啊，海阔天空啊，笨小孩啊等等免疫力已经很强，但有位同事居然用普通话腔唱粤语版的《情缘巴士站》，这实在是太超过了！我听着那个荒腔走板啊，老在寻思那个音究竟是普通话还是粤语，怎么发出来的。好几次手都放在切歌按钮上了，终于还是没有按下去，hoho！
    后来上面两位实在无所事事，就玩骰子吹牛，于是在偶情深款款低吟浅唱的时候，不时有哐哐当当悉悉簌簌的背景音，甚至还有大呼小叫“五个五！”“六个六！”，听得偶忍无可忍————于是把话筒一扔，加入战团，把他们唬得落花流水，哈哈！其他人看我们玩得高兴，也纷纷加入，最后只剩一个MM自点自唱，呵呵。
    我们一共玩了五个小时，连自助餐一共花了将近四百，应该算便宜的了，玩得也还算开心，不过环境食品歌曲都不怎么滴，如果想唱歌，或者想吃好点的，不算好的选择了。

《Head First Design Patterns》分享（五）----单件模式

随兴所至 — Mon, 18 Dec 2006 16:45:41 +0800

    单件模式主要是要求一个类有且只有一个实例，并提供全局的访问点。例如一个学生宿舍可能只有一台打印机供所有人使用。最简单的方法是在程序一开始就创建一个静态的实例对象，也就是把一台打印机固定地放在宿舍里。但是，出于某种原因，例如相关数据没有准备好不能实例化（类似于插座没装好，打印机还不能用），或者资源紧张（类似于另一个宿舍需要打印机，但放了打印机的宿舍并没有使用），因此需要按需创建。也就是在需要的时候才申请使用打印机。为了使对象不能随意实例化，构造函数只能是private,再提供一个静态的实例化函数让需要的代码调用。实例化有两种模式，eager mode和 lazy mode， eager是指在声明类的时候就创建，lazy是指在函数中按需创建。
  eager:
  public class Singleton{
   private static Singleton uniqueInstance = new Singleton();
   private Singleton(){}
   public static Singleton getInstance(){
    return uniqueInstance;
   }
  }
  lazy:
  public class Singleton{
   private static Singleton uniqueInstance;
   private Singleton(){}
   public static Singleton getInstance(){
    if(uniqueInstance == null){
     uniqueInstance = new Singleton();
    }
    return uniqueInstance;
   }
  }
    在多线程的模式下，为了避免同时申请而创建了多个实例，可以加上锁来进行同步。一台打印机，正在打印一个文档的时候不能同时打印另一个文档，就需要用这个机制来处理，第一个文档打印的时候把资源锁上，另一个文档发现资源被锁就只能等待到锁打开。可以用synchronize（同步）来实现。但是具体到我们这个案例，只是为了创建加锁，创建后，可以同时访问，用这种同步锁机制就可能影响效率，因此可以采取double-checked locking的机制，先判断对象是否已经创建，如果已经创建则无须同步，还没有创建，则同步。

《Head First Design Patterns》分享（四）----工厂模式

随兴所至 — Fri, 15 Dec 2006 23:44:58 +0800

    话说有三家Pizza店刚进入中国市场，MYPAPAJOHN，MYPIZZAHUT和MYDOMINOS,让我们看看它们是如何经营的。运营需要一份Pizza的说明书和一家Pizza店，Pizza的说明书说明了Pizza的各种调料以及各生产工艺如何进行；而整个生产过程都在Pizza店里进行。当顾客向Pizza店下单，就会通过下面的生产过程完成一盒比萨给用户：制饼（create object），涂上调料 (prepare),烘培（bake）,成型（cut）,装盒（box）。
    MYPAPAJOHN生产三种Pizza, 每种制模的工具都不一样，生产过程完全一样。过了一段时间，MYPAPAJOHN发现竞争对手的两种Pizza比较畅销，自己有一种产品需要淘汰，因此它在menu中加上两种，划掉一种。现在，它需要在店里增加两种制饼工具，去掉一种制饼工具，这就不可避免要改变店里的布局！由于考虑到以后制饼工具可能还会变更，但生产过程比较稳定，因此它建立一个简单工厂，专门用于制饼，制饼工具都存放在那里，在顾客下单的时候，就通知工厂根据需要制好一个饼，再运到店里加工。此后，制饼工具的增减就不再对店铺产生影响啦。这就是简单工厂模式！
    MYPIZZAHUT在广州和四川都有了分店，它只生产一种Pizza,但是经过市场调查，广州不喜欢吃辣的，而四川喜欢吃辣的！经过研究，MYPIZZAHUT决定各地可以生产有地方特色的饼：首先，还是一份说明书规定了Pizza的调料名，各种生产工艺如何进行，但是各地方的饼可以有自己的说明书规定调料的辣度，也就是，对客户而言都是同一种调料，但在广州可以不辣，在四川可以巨辣！同时总店修改了店铺的生产过程，虽然规定了分店仍然担任制饼工作，但是可以制作有当地特色的饼。当顾客到广州店铺下单的时候，制饼师傅就知道是要制作广州的饼，通过查阅广州的饼的说明书，取出不辣的调料用于制饼后的涂料过程。这就是工厂模式！
    而MYDOMINOS面临跟MYPIZZAHUT一样的问题，而且它有两种Pizza，分别是cheese和veggie,每种调料不一样，同时，公司还希望调料按需生产，而不是预先买一堆调料放着。因此总店决定建立一些工厂生产调料，也就是将制好的饼和调料作为一套。总店首先要规定调料工厂的生产内容，但是不规定具体的生产细节，也就是广州跟四川生产同样名称的各种调料，但味道可以不同！Pizza仍然有一份总的说明书，规定了Pizza的调料名，各种生产工艺如何进行，但不再规定涂调料这一工艺的具体生产细节，各种Pizza另有一份说明书，说明在涂调料时通知当地的调料工厂送哪些调料过来。这样，当顾客到广州店铺购买 cheese pizza的时候，师傅查阅cheese的说明书，制饼之前查出送调料过来的工厂的联系电话，制饼之后，涂调料的时候通知工厂将所需的调料送过来，这就是抽象工厂模式！

《系统思考》读后

随兴所至 — Thu, 14 Dec 2006 20:13:12 +0800

    终于读完了这本《系统思考----适于管理者的创造性整体论》，很少读一本书读得如此困难，用了整整五个晚上，也就是浮光掠影地通读了一遍，大概知道了书的框架，却几乎没有吸收内容。这本书先是介绍入门性的系统概念、应用系统思想及如何增加思考性；第二部分全面回顾有关管理的最著名和最有用的整体性方法；第三部分则是这些方法的组合应用。
    我是带着问题去读这本书的，我现在有太多太多的困惑：领导随意制定规则，又不时自己破坏；领导出于某种情绪或考虑，使某些项目偏离需求；需求的入口太多，几乎没有管控，常常使我们无法招架；各个组之间界限不分明，我们似乎处于风暴的核心，好像所有人都能并且都在向我们提需求，又好像只要我们做到一百分就天下太平；如何培养其他同事，包括应届生，新同事，有了一定积累安于现状的程序员，甚至那些工作多年喜欢管事不喜欢管人的主管；出于当前局势的考虑，将大部分需求让某一个组负责，客观上造成组之间任务的不均衡，是否需要调整；让某些经验不足的同事担当多重角色，对一些小项目担任项目经理+系统分析+系统设计，是否会拔苗助长，如何协助他们；所有人都在抱怨我们的知识管理，如何改善；推行了一些措施，每个人都没有意见，似乎每个人都没有想法，如何激励他们思考，如何鼓励他们说出来。。。。。。
    这本书几乎没有解决我的任何一个问题。对我而言，最大的收获是坚定了一个信念：应该还有很多人跟我一样困惑，他们面对的问题跟我面对的一样复杂、多样和变化，所以才有这么多人研究各种各样的方法来试图解决，并且到了近期，几乎所有的方法都是基于复杂多变的局面来考虑的，这起码让我好受了很多，哈哈！
    其次，我一直觉得无法决定我所在组织的目标，我意识到这一点，但是总觉得局面复杂甚至滑向冲突和无序，不知道从何入手，所以就没有把制定目标作为要解决的问题之一。这本书提供的方法是承认目标的不一致甚至冲突的，然后在这个基础上探索目的并保证组织利益相关者之间对目标形成充分的共识。我能看进去的方法之一是组织不同利益体的成员，分成小组来互相辩论，并提供了具体操作形式，但是我觉得这种方法成本太高，难以操作。无论如何，它提供了三个方法，应该会有借鉴意义。
    再次，书中提供了九种重要的组织形象化比喻，分别是：机器、有机体、大脑、变迁和转换、文化、政治系统、心灵监狱、统治工具、狂欢节；以及在现今社会理论中存在的四种范式：功能主义范式、诠释范式、解放型范式和后现代范式。这有助于我从不同的角度观察我所在的组织及其外部环境，更好地从大局上进行把握。书中介绍的各种方法似乎都不是在解答我的困惑，是否我要解决的问题其实是细节，而我首先应该在更高层次上掌握整体，包括环境、目标、界面和检验标准？
    最后，书中介绍了不少系统方法，分别为用于“改善目标搜寻和提高生存能力”的“硬系统思考”、“系统动力学”、“组织控制论”和“复杂性理论”；用于“探索目的”的“基本假设表面化与检验”、“交互式规划”和“软系统方法论”；用于“保障公平性”的“批判系统启发法”和“团组协整”；还有用于“促进多样化”的“后现代系统思考”。可以说，每种方法的介绍都遵循一种易于接受的逻辑，先是研究背景，到方法论，到系统方法介绍和应用，到反对者意见，到总结和建议，也许我看不进去的原因是因为每句话信息量太大，而我刚好这些方法基本都没怎么接触过？或者我先按照书中的指引找相应的易懂的书先看？（偶是学软件的，不是学管理的，也不知道怎么自己就开始做管理了）呵呵，书也许是好书，只是我还没有阅读它的知识积累。
  总之，阅读这本书的过程就像在吃压缩饼干，没什么味道，也不觉得饱，就是涨。。。。。。呜呜，偶为了提神，不停吃德芙，结果，一颗痘，两颗痘。。。。。。