圭臬

温州杨姓书记旅法兰西而不归，坊间哄传，江湖哗笑，而鹿城大窘焉。窘迫情急，忽出奇计曰“越洋追韩信”也，派使者三，怀锦囊而西，越大洋而追书记焉。抵巴黎，出锦囊一，欲与书记晤谈，书记隐于市，晤面未遂；出锦囊二，游说侨领诱其出，侨领等嗫嗫回避，又未遂；锦囊三，到此一游而返也。
噫嘻！温州之追韩信，其锦囊之计令人喷饭也乎哉！昔者，萧何月下追韩信，乃韩信大才也，不追则为项王用，用则难克也；今之杨书记，大才乎？法兰西必用其才乎？皆非也。如是则温州之必追，恐另有难言之隐也：上必责以懈怠，致国威有损，此其一也；大员动辄去国，后来接踵仿效，此其二也；该员或有贪渎，远走外邦避祸，此其三也。有此三端，鹿城惶急，是以巴黎追韩信焉。对上则曰我已追之，对下则曰我已仁尽，自命乎上下周全也。
愚哉！鹿城有司！该杨谋定而动，策划于内外，慎密乎始终，前有逃匿之官悠悠隐寓，后有络绎之贼蠢蠢欲来，归也乎？不归也！是故温州之劝返，明知无功而必追，矫情之蠢一也；所谓使者劝返，无非党国大计，乡梓殷殷之类，该杨贵为地方大吏，岂不知外崇内凶之实相？该杨乃洞悉实相而远走，岂能再入尔等彀中？此又温州劝返假情之蠢二也；该杨既走，追之何益？察其贪渎，开其职缺，通报国际，一体擒拿可也，不思以法治其罪，依然弄权饰其非，此则温州劝返可恶之蠢三也。
有此三端，则杨氏之后，再发沪上吏员之逃，接踵而奔避之贼官络绎不绝者必也，有何怪哉？
来源: http://www.blogchina.com/20081103623591.html

亲爱的经济学家：
我是金丝雀码头(Canary Wharf,伦敦金融区之一——译者注)的一名三陪。我这个行业的人该如何应对雷曼兄弟(Lehman Brothers)倒闭后的需求骤降，我不知道您是否有一些好的建议？
C小姐
亲爱的C小姐：
我并没有注意到三陪服务是顺周期性的，但我会相信你的话。你有三个选择，不过没有一个是尽善尽美的。
选择一：换工作地点。金丝雀码头纯粹是银行业，你可以找到一个更加多样化的市场。伦敦西区到处是对冲基金、石油大亨和旧富们。不过，我承认找到新客户需要花费一番工夫。经济学家史蒂文•莱维特(Steven Levitt)和社会学家素德赫•文卡特斯赫(Sudhir Venkatesh)最近对芝加哥的街头卖淫进行了分析。他们发现，该行业非常集中，因为如果不是这样，妓女和嫖客会找不到对方。当然，你和她们并不完全一样，或许可以轻松地换个工作地点。
选择二：在金丝雀码头撑下去，期待供给会随着需求而下降。莱维特和文卡特斯赫发现，面对需求的激增，街头卖淫的供给极具弹性。（7月4日的假期会造成卖淫交易量飙升——谁知道呢？）现有的妓女会延长工作时间，其他妓女会来到该地区，而通常不是妓女的女性也会涉足卖淫行业。这意味着在困难时期，你的许多竞争对手会找些其他事情来做。
选择三：你也许会发现三陪服务有点像房地产中介，即便是严重的需求冲击往往也不会降低费用。你会发现自己工作时收入很高，但常常没有工作可做。你可以用空出的时间进行学习或者找一份兼职。
对于房地产中介，我也会给出一模一样的建议。
经济学家
来源: http://blog.sina.com.cn/s/blog_406e77d10100bbw4.html

我在程序员的时候，我一开始追逐这个API怎么用，数据库SQL怎么写更优化，Dcom技术的细节
然后我发现我写出来的产品为了符合客户需求必须要大量修改，但是我的代码却粘在了一起
第一个感觉就是一个函数太长，一看就头痛，而且一个函数干了好多事。这些事本来可以一段一段的，每段写上注释，然后有意义命名，自己管理错误和内存，然后把这些函数连在一起
然后我作了这些：
1小函数
2写上注释
3有意义命名
4自己管理错误和内存
5流程函数
最后我发现我这些函数可以组合成各种各样的流程，我的程序终于好修改了，我很高兴
但是我又发现，我的界面和我的流程混在了一起，另一个程序也想使用我的函数，但是我的函数中有对我的特定界面关联的代码，我不能连界面一起都给他，因为他有他的界面，但作的事我已经实现了
于是我把功能函数和界面控制分开了
我就作了这些，我的代码很容易理解，即使新员工，只要他看完业务手册和数据结构，他就明白我代码为什么这么写。
而且我的函数由于都是自己负责输入参数和输出参数的校验，有明确和统一的报错信息，所以很容易找到错误进行BUG修复。
由于我的程序都是小函数组成的，都有明确报错，所以错误很容易找到，经过测试组的专业测试后，我的代码很稳定
即使出错，也扩散不大，都是小bug，对系统整体没有大影响
虽然我在前进的过程中也经历过困惑，一心钻在OO和设计模式中。但是有可能是功力不够，不得其解。看着Delphi的源码
应用了很多的OO和模式，并且他的类库多年发展也没有多大的改变，所以深信OO和模式的威力，而对自己的能力很灰心。但是代码还得继续写，还想进一步提高，于是才摸索出现在的一套做法。既实用又简单应用，每个人都能办到
我认为我的代码方法已经可以满足现在的产品制造，并且在软件性能调整上也积累了一些珍贵的经验。
我发现性能最容易提高也效果最明显的就是用SQL profilter，优化SQL。
优化代码，因为涉及到业务，很不好着手。优化数据库结构，由于代码都是构建在特定数据表之上，所以这是最难改的地方
但是我高兴了没多久，我又遇到问题了。因为我的程序即使再好改，但是客户的需求真是千奇百怪，我每天在接听用户的电话，并且修改用户千奇百怪的问题。我很烦。
于是我作了实施员。我想真正看看客户到底怎么回事。
于是我理解了很多。我明白了很多的事情不是技术和软件所能解决的，而是现实环境的弊病。但是这个弊病还不是一个工程就能解决的，这是一个复杂的网。所以这些问题我就说服用户不要用软件来处理，因为软件是死的，而人的做法是灵活的。
而且我发现用户虽然提了很多需求，但是有的需求他一个月用不了一次，但是修改起来却不容易。有的需求修改完，在实际应用中却发现不可行，那个需求只是客户想解决过去的问题而想的一个办法根本没有经过实际的校验。有的需求修改来修改去都是表面问题，在实际应用中才发现重点问题没有提需求所以上线又搁下了
我作了总结：
1软件擅长大数据量计算和查询，还有数据联网共享，如果需求不能发挥软件特点，就不让软件实现。这样我少修改了一些
2有的需求都是表面需求，修改了也用处不大，反而耽误了重点需求的提出和修改，所以告诉用户只修改核心功能。但是用户提了很多需求，不修改完不上线。后来发现，由于他们没有深刻理解我们系统的整体思想，所以没有上线实际用，根本不知道新改的功能是否好用。用户只是脱离了整体，单独思考想怎么就怎么，没上线根本他不知道后果，怎么说也不行，就得让他看见教训他才反悔，但是已经修改了。往往出现这样的情况。最后得出一个结论：一次只提三个需求，并且用书面提出，免的说了不算算了不说。核心功能的需求修改可以满足80％的日常使用就上线。这样我少修改了很多
3并且我在实际做工程中，积累了大量的经验，写成FAQ，各种成功案例，让用户在没有提需求之前先看看自己到底有多少老软件实在不能解决而才买新软件帮助的事。新软件就是解决你过去解决不了的事。如果你没有解决不了的事，提什么需求
我的产品终于可以很快完成上线，所以可以大规模推广市场了
但是我们的产品制造又出问题了。因为客户越来越多，客户的需求越来越多。我们需要开发更多的系统，但是我们的时间有限，我们的人手有限，而且我们的人手大多是新手。怎么办。我们遇到了灾难。我们的代码质量因人而异。我们的版本管理混乱。我们的文档没有人编写，大家都被分配到用户处去上线。怎么准备数据字典，怎么切换系统，怎么记录客户需求，怎么管理系统，怎么修改代码，我们没有任何记录。现场不能离开程序员一步，一离开用户出事了就不知怎么办，没有任何可查的资料。
于是我又做了项目管理，我们缺少很多规范。事有千万，先从紧处来。写文档费时间，就开会给大家讲做事的经验。实施和代码修改需要什么必要规范就制定什么规范。在这期间最容易犯的错就是中央集权，什么事都必须自己做主。下属不管大事小事都请示你。我被搞的什么都干不了，都成了救火队员。我的团队陷入了混乱之中，因为我烦乱之中作了很多饮鸩止渴的决定。我于是又犯了一个错误，我说你们能决定的事尽量自己决定，不要问我，我权利下放。结果是：各自作各自的事，互相不通知。有的事没人管，有的事多人修改，各有一套。
我终于明白了，我作了总结：
1项目经理是找到得力的人，指导他们做事的方向。如果下属不知如何作时，及时提供给下属做事方法
2制定规范，其实也就是做事方法
3制定计划，分配人力去作。检查结果
4有紧急事务立刻做出果断解决，继续前进
我的团队终于平静了下来，但是大家都很疲惫。大家干的很累，但是由于实施和修改消耗了大量的钱，我们没有赚钱，大家什么都没有得到。团队很灰心，也很失望。我下了计划，我自己都很灰心，大家认为再努力也不会再有结果，所以拖拖拉拉，进度和成本已成不可再提的事情。
人，缺少了精气神，就什么都没有了。我们就是缺少了这些。
我就开始重新建立团队的精气神
我发现有人为了跳槽开始学习新的技术，而这种技术是公司现有产品不需要的，但是他们却在上班时间作。我先从此下手。
我讲了技术的方向，让他们认清他们现在所学将会很快淘汰。
我又讲了现在市场的实况，让他们认清外面公司也不好过。
我还讲了我们所从事的行业多有潜力，我们公司将有新的举措。
人心又开始一点一点收回了。
但是我们仍然需要完成那些未收尾的工作，仍然需要去奔赴新的客户市场。虽然员工很疲惫，虽然我们刚从飘摇中过来，
但是我们不能止步，因为我们为盈利而存在，我们别无选择。
我能够将代码写的很好，性能很高，产品制造很有计划和成本控制，团队很有战斗力。但是我发现了一个问题，我们的产品市场不再扩大了。市场份额大规模开拓已很艰难，因为新产品的新鲜感已经过去了。我们在动荡的日子作的项目给公司带来了阴影，公司一直没有大赚钱，投资方很生气。
我明白了。公司毕竟是为利润而存在的。公司不是为产品制造而存在，不是为了解决别人的问题而存在。赚钱是第一位。
不赚钱即使你在媒体上作的很风光也一文不值。有人靠手赚钱，有人靠嘴赚钱，有人靠脑子赚钱，有人靠身体赚钱，不管黑猫白猫，只要抓住老鼠就是好猫。成在营销，败在管理。
我开始关注资本运作，联盟伙伴建设，市场营销，客户关系营运。我知道，生活才刚刚开始。
来源: http://cscer.yculblog.com/post.316988.html

设计模式的有趣解释－追MM
创建型模式?
1、FACTORY一追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory?
工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。?
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM 也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）?
建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。?
3、FACTORY?METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory?Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行 了。?
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。?
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）?
原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一 个类都必须配备一个克隆方法。?
5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)?
单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。?
结构型模式?
6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)?
适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。?
7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行 了?
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。?
8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？?
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。?
9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？?
装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。?
10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样 MM也可以用这个相机给我拍张照片了。?
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。?
11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。?
享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量 。?
12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。?
代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。?
行为模式?
13、CHAIN?OF?RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的M M把纸条传给老师了，听说是个老处女呀，快跑!?
责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接?
起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不 被任何接收端对象所接受。?
14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。”，:-(?
命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。?
15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。?
解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。?
16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。?
Mary：“想要我跟你结婚，得答应我的条件”?
我：“什么条件我都答应，你说吧”?
Mary：“我看上了那个一克拉的钻石”?
我：“我买，我买，还有吗？”?
Mary：“我看上了湖边的那栋别墅”?
我：“我买，我买，还有吗？”?
Mary：“你的小弟弟必须要有50cm长”?
我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”?
……?
迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。?
17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。?
调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。?
18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。?
备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。?
19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦?
观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。?
20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说 “有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。?
状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。?
21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。?
策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。?
22、TEMPLATE?METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template?method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；?
模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑 的细节留给具体的子类去实现。?
23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；?
访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
作者: 佚名
来源: 不详

ERP(Enterprise Resource Planning)企业资源计划系统，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。
一天中午，丈夫在外给家里打电话：“亲爱的老婆，晚上我想带几个同事回家吃饭可以吗？”（订货意向）
妻子：“当然可以，来几个人，几点来，想吃什么菜？”
丈夫：“6个人，我们7点左右回来，准备些酒、烤鸭、番茄炒蛋、凉菜、蛋花汤……。你看可以吗？”（商务沟通）
妻子：“没问题，我会准备好的。”（订单确认）
妻子记录下需要做的菜单（MPS计划），具体要准备的东西：鸭、酒、番茄、鸡蛋、调料……（BOM物料清单），发现需要：1只鸭蛋，5瓶酒，4个鸡蛋……（BOM展开），炒蛋需要6个鸡蛋，蛋花汤需要4个鸡蛋（共用物料）。
打开冰箱一看（库房），只剩下2个鸡蛋（缺料）。
来到自由市场，妻子：“请问鸡蛋怎么卖？”（采购询价）
小贩：“1个1元，半打5元，1打9.5元。”
妻子：“我只需要8个，但这次买1打。”（经济批量采购）
妻子：“这有一个坏的，换一个。”（验收、退料、换料）
回到家中，准备洗采、切菜、炒菜……（工艺线路），厨房中有燃气灶、微波炉、电饭煲……（工作中心）。妻子发现拨鸭毛最费时间（瓶颈工序，关键工艺路线），用微波炉自己做烤鸭可能来不及（产能不足），于是阅览室在楼下的餐厅里买现成的（产品委外）。
下午4点，电话铃又响：“妈妈，晚上几个同学想来家里吃饭，你帮忙准备一下。”（紧急订单）
“好的，你们想吃什么，爸爸晚上也有客人，你愿意和他们一起吃吗？”
“菜你看着办吧，但一定要有番茄炒鸡蛋，我们不和大人一起吃，6：30左右回来。”（不能并单处理）
“好的，肯定让你们满意。”（订单确定）
鸡蛋又不购了，打电话叫小贬送来。（紧急采购）
6：30，一切准备就绪，可烤鸭还没送来，急忙打电话询问：“我是李太，怎么订的烤鸭还不送来？”（采购委外单跟催）
“不好意思，送货的人已经走了，可能是堵车吧，马上就会到的。”
门铃响了。“李太太，这是您要的烤鸭。请在单上签一个字。”（验收、入库、转应付账款）
6：45，女儿的电话：“妈妈，我想现在带几个朋友回家吃饭可以吗？”（呵呵，又是紧急订购意向，要求现货）
“不行呀，女儿，今天妈已经需要准备两桌饭了，时间实在是来不及，真的非常抱歉，下次早点说，一定给你们准备好。”
（哈哈，这就是ERP的使用局限，要有稳定的外部环境，要有一个起码的提前期）
送走了所有客人，疲惫的妻子坐在沙发上对丈夫说：“亲爱的，现在咱们家请客的频率非常高，应该要买些厨房用品了（设备采购），最好能再雇个小保姆（连人力资源系统也有接口了）。
丈夫：“家里你做主，需要什么你就去办吧。”（通过审核）
妻子：“还有，最近家里花销太大，用你的私房钱来补贴一下，好吗？”（最后就是应收货款的催要）
现在还有人不理解ERP吗？记住，每一个合格的家庭都是生产厂长的有力竞争者！
来源: http://www.chinaunix.net/jh/28/330576.html