﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>语源科技BlogJava-tangbao</title><link>http://www.blogjava.net/tangbao/</link><description /><language>zh-cn</language><lastBuildDate>Tue, 12 May 2026 22:58:01 GMT</lastBuildDate><pubDate>Tue, 12 May 2026 22:58:01 GMT</pubDate><ttl>60</ttl><item><title>管理学30大理论故事</title><link>http://www.blogjava.net/tangbao/archive/2010/01/22/310528.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Fri, 22 Jan 2010 07:28:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2010/01/22/310528.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/310528.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2010/01/22/310528.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/310528.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/310528.html</trackback:ping><description><![CDATA[<p><strong>1、</strong> <strong>彼得原理</strong></p>
<p>每个组织都是由各种不同的职位、等级或阶层的排列所组成，每个人都隶属于其中的某个等级。彼得原理是美国学者劳伦斯&#183;彼得在对组织中人员晋升的相关现象研究后，得出一个结论：在各种组织中,雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为向上爬的原理。&nbsp;这种现象在现实生活中无处不在：一名称职的教授被提升为大学校长后，却无法胜任；一个优秀的运动员被提升为主管体育的官员，而无所作为。对一个组织而言，一旦相当部分人员被推到其不称职的级别，就会造成组织的人浮于事，效率低下，导致平庸者出人头地，发展停滞。因此，这就要求改变单纯的根据贡献决定晋升的企业员工晋升机制，不能因某人在某个岗位上干得很出色，就推断此人一定能够胜任更高一级的职务。将一名职工晋升到一个无法很好发挥才能的岗位，不仅不是对本人的奖励，反而使其无法很好发挥才能，也给企业带来损失。</p>
<p>这个问题其实是普遍存在的，就不多说了。但是还有一种情况就是，上司总是趋向于把你放在你能力暂时达不到的职位。而过一段时间之后，你会通过压力、调节、学习等来达到与该职位要求相符的能力。这样便达到了个人的提高。两种情况其实都有道理，还是因人而异。决定性因素是领导看人与用人的标准。</p>
<p><strong>2、</strong> <strong>酒与污水定律</strong></p>
<p>酒与污水定律是指把一匙酒倒进一桶污水，得到的是一桶污水；如果把一匙污水倒进一桶酒，得到的还是一桶污水。在任何组织里，几乎都存在几个难弄的人物，他们存在的目的似乎就是为了把事情搞糟。最糟糕的是，他们像果箱里的烂苹果，如果不及时处理，它会迅速传染，把果箱里其他苹果也弄烂，烂苹果的可怕之处，在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没，而一个无德无才者能很快将一个高效的部门变成一盘散沙。组织系统往往是脆弱的，是建立在相互理解、妥协和容忍的基础上的，很容易被侵害、被毒化。破坏者能力非凡的另一个重要原因在于，破坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器，一头驴子一秒钟就能毁坏掉。如果一个组织里有这样的一头驴子，即使拥有再多的能工巧匠，也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子，你应该马上把它清除掉，如果你无力这样做，就应该把它拴起来。</p>
<p>我们部门有这样的人，之前差点把所有花瓶都打了，还好，及时把这头驴子栓起来才防止了损失的进一步扩大。对于这个理论，我深有体会。作管理，要及时的发现身边谁是这头搞破坏的驴子。找到这头驴子之后的措施倒是简单得多了。</p>
<p><strong>3、</strong> <strong>木桶定律</strong></p>
<p>水桶定律是讲一只水桶能装多少水，这完全取决于它最短的那块木板。这就是说任何一个组织，可能面临的一个共同问题，即构成组织的各个部分往往是优劣不齐的，而劣势部分往往决定整个组织的水平。水桶定律与酒与污水定律不同，后者讨论的是组织中的破坏力量，最短的木板却是组织中有用的一个部分，只不过比其他部分差一些，你不能把它们当成烂苹果扔掉。强弱只是相对而言的，无法消除，问题在于你容忍这种弱点到什么程度，如果严重到成为阻碍工作的瓶颈，你就不得不有所动作。</p>
<p>与你合作的同事、受你支配的下属其实都是各个不同长短的板子，绝对不可能有一样齐的情况，除了对于特别矮的板子要剔除之外，我们要作的就是让相对较矮的那块板子提升高度。一直这样循环往复，你的桶子里面装的水将越来越多。</p>
<p>另外现在除了木桶定律之外，还有一个箍桶理论。</p>
<p>木桶能装多少水，除了木板的高低之外，还有各个板子之间的紧密程度。如果板子都很高，但是之间的缝隙很大，那么水一样会从中间漏出来。这个箍，就是团队合作。我非常重视这个箍。</p>
<p><strong>4、</strong> <strong>马太效应</strong></p>
<p>《新约&#183;马太福音》中有这样一个故事：一个国王远行前，交给3个仆人每人一锭银子，吩咐道：你们去做生意，等我回来时，再来见我。国王回来时，第一个仆人说：主人，你交给我的一锭银子，我已赚了10锭。于是，国王奖励他10座城邑。第二个仆人报告：主人，你给我的一锭银子，我已赚了5锭。于是，国王奖励他5座城邑。第三仆人报告说：主人，你给我的1锭银子，我一直包在手帕里，怕丢失，一直没有拿出来。于是，国王命令将第三个仆人的1锭银子赏给第一个仆人，说：凡是少的，就连他所有的，也要夺过来。凡是多的，还要给他，叫他多多益善，这就是马太效应，反应当今社会中存在的一个普遍现象，即赢家通吃。对企业经营发展而言，马太效应告诉我们，要想在某一个领域保持优势，就必须在此领域迅速做大。当你成为某个领域的领头羊时，即便投资回报率相同，你也能更轻易地获得比弱小的同行更大的收益。而若没有实力迅速在某个领域做大，就要不停地寻找新的发展领域，才能保证获得较好的回报。</p>
<p>不要抱怨这个世界为什么不公平，因为这个世界从来就没有公平过。</p>
<p><strong>5、</strong> <strong>零和游戏原理</strong></p>
<p>零和游戏是指一项游戏中，游戏者有输有赢，一方所赢正是另一方所输，游戏的总成绩永远为零，零和游戏原理之所以广受关注，主要是因为人们在社会的方方面面都能发现与零和游戏类似的局面，胜利者的光荣后面往往隐藏着失败者的辛酸和苦涩。&nbsp;20世纪，人类经历两次世界大战、经济高速增长，科技进步、全球一体化以及日益严重的环境污染，零和游戏观念正逐渐被双赢观念所取代。人们开始认识到利已不一定要建立在损人的基础上。通过有效合作皆大欢喜的结局是可能出现的。但从零和游戏走向双赢，要求各方面要有真诚合作的精神和勇气，在合作中不要小聪明，不要总想占别人的小便宜，要遵守游戏规则，否则双赢的局面就不可能出现，最终吃亏的还是合作者自己。</p>
<p><strong>6、</strong> <strong>华盛顿合作规律</strong></p>
<p>华盛顿合作规律说的是一个人敷衍了事，两个人互相推诿，三个人则永无成事之日。多少有点类似于我们三个和尚的故事。人与人的合作，不是人力的简单相加，而是要复杂和微妙得多。在这种合作中，假定每个人的能力都为1，那么，10个人的合作结果有时比10大得多，有时，甚至比1还要小。因为人不是静止物，而更像方向各异的能量，相互推动时，自然事半功倍，相互抵触时，则一事无成。&nbsp;我们传统的管理理论中，对合作研究得并不多，最直观的反映就是，目前的大多数管理制度和行为都是致力于减少人力的无谓消耗，而非利用组织提高人的效能。换言之，不妨说管理的主要目的不是让每个人做得更好，而是避免内耗过多。</p>
<p>跟箍桶原理类似的，这也是强调了合作的重要性。</p>
<p><strong>7、</strong> <strong>手表定理</strong></p>
<p>手表定理是指一个人有一只表时，可以知道现在是几点钟，当他同时拥有两只表时，却无法确定。两只手表并不能告诉一个人更准确的时间，反而会让看表的人失去对准确时间的信心。手表定理在企业经营管理方面，给我们一种非常直观的启发，就是对同一个人或同一个组织的管理，不能同时采用两种不同的方法，不能同时设置两个不同的目标，甚至每一个人不能由两个人同时指挥，否则将使这个企业或这个人无所适从。手表定理所指的另一层含义在于，每个人都不能同时选择两种不同的价值观，否则，你的行为将陷于混乱。</p>
<p>我个人觉得这个是在管理中最容易出现问题的环节，也是最难以解决的。因为这个的问题出在管理层，管理层的标准不统一，对下属员工造成的影响是巨大的。奖励标准、惩罚标准不统一，不同领导不一样，同一个领导对待不通员工标准不一样，这都是会影响到团队士气的重要因素，因此，作为中间管理层，最应该做好的是与上级统一管理标准，同时不要轻易的惩罚或奖励一个下属，评定好事情的级别再做出奖惩反应也不迟。</p>
<p><strong>8、</strong> <strong>不值得定律</strong></p>
<p>不值得定律最直观的表述是：不值得做的的事情，就不值得做好。这个定律再简单不过了，重要性却时时被人们忽视遗忘。不值得定律反映人们的一种心理，一个人如果从事的是一份自认为不值得做的事情，往往会保持冷嘲热讽，敷衍了事的态度，不仅成功率低，而且即使成功，也不觉得有多大的成就感。&nbsp;因此，对个人来说，应在多种可供选择的奋斗目标及价值观中挑选一种，然后为之奋斗。选择你所爱的，爱你所选择的，才可能激发我们的斗志，也可以心安理得。而对一个企业或组织来说，则要很好地分析员工的性格特性，合理分配工作，如让成就欲较强的职工单独或牵头完成具有一定风险和难度的工作，并在其完成时，给予及时的肯定和赞扬；让依附欲较强的职工，更多地参加到某个团体*同工作；让权力欲较强的职工，担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感，让员工感觉到自己所做的工作是值得的，这样才能激发职工的热情。</p>
<p><strong>9、</strong> <strong>蘑菇管理</strong></p>
<p>　　蘑菇管理是许多组织对待初出茅庐者的一种管理方法，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。相信很多人都有过这样一段蘑菇的经历，这不一定是什么坏事，尤其是当一切刚刚开始的时候，当几天蘑菇，能够消除我们很多不切实际的幻想，让我们更加接近现实，看问题也更加实际。一个组织，一般对新进的人员都是一视同仁，从起薪到工作都不会有大的差别。无论你是多么优秀的人才，在刚开始的时候，都只能从最简单的事情做起，蘑菇的经历，对于成长中的年轻人来说，就象蚕茧，是羽化前必须经历的一步。所以，如何高效率地走过生命的这一段，从中尽可能汲取经验，成熟起来，并树立良好的值得信赖的个人形象，是每个刚入社会的年轻人必须面对的课题。</p>
<p>对于刚出校园的学生来说，一般都有一些通病：自命不凡，激情四射，骄傲浮躁，不甘心作配角等。采用蘑菇管理其实是对毕业生的磨练，我很赞成使用这种方法来对待毕业生。</p>
<p><strong>10、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>奥卡姆剃刀定律</strong></p>
<p>12世纪，英国奥卡姆的威廉主张唯名论，只承认确实存在的东西，认为那些空洞无物的普遍性概念都是无用的累赘，应当被无情地剃除。他主张如无必要，勿增实体。这就是常说的奥卡姆剃刀。这把剃刀曾使很多人感到威胁，被认为是异端邪说，威廉本人也因此受到迫害。然而，并未损害这把刀的锋利，相反，经过数百年的岁月，奥卡姆剃刀已被历史磨得越来越快，并早已超载原来狭窄的领域，而具有广泛、丰富、深刻的意义。　　</p>
<p>奥卡姆剃刀定律在企业管理中可进一步演化为简单与复杂定律：把事情变复杂很简单，把事情变简单很复杂。这个定律要求，我们在处理事情时，要把握事情的主要实质，把握主流，解决最根本的问题，尤其要顺应自然，不要把事情人为地复杂化，这样才能把事情处理好。</p>
<p><strong>11、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>墨菲定律</strong></p>
<p>１９４９年，一位名叫墨菲的空军上尉工程师，认为他的某位同事是个倒霉蛋，不经意间开了句玩笑：&#8220;如果一件事情有可能被弄糟，让他去做就一定会弄糟。&#8221;</p>
<p>这句话迅速流传，并扩散到世界各地。在流传扩散的过程中，这句笑话逐渐失去它原有的局限性，演变成各种各样的形式，其中一个最通行的形式是：&#8220;如果坏事情有可能发生，不管这种可能性多么小，它总会发生，并引起最大可能的损失。&#8221;</p>
<p>这就是著名的&#8220;墨菲定律&#8221;。</p>
<p><strong>12、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>破窗理论</strong></p>
<p>美国政治学家威尔逊和犯罪学家凯林经过观察提出了&#8220;破窗理论&#8221;。</p>
<p>如果有人打坏了一栋建筑上的一块玻璃，又没有及时修复，别人就可能受到某些暗示性的纵容，去打碎更多的玻璃。久而久之，这些窗户就给人造成一种无序的感觉，在这种麻木不仁的氛围中，犯罪就会滋生、蔓延。</p>
<p>&nbsp;&#8220;破窗理论&#8221;更多的是从犯罪的心理去思考问题，但不管把&#8220;破窗理论&#8221;用在什么领域，角度不同，道理却相似：环境具有强烈的暗示性和诱导性，必须及时修好&#8220;第一扇被打碎玻璃的窗户&#8221;。</p>
<p><strong>13、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>雷鲍夫法则</strong></p>
<p>提出者：美国管理学家雷鲍夫</p>
<p>在你着手建立合作和信任时要牢记我们语言中：</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最重要的八个字是：我承认我犯过错误</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最重要的七个字是：你干了一件好事</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最重要的六个字是：你的看法如何</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最重要的五个字是：咱们一起干</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>最重要的四个字是：不妨试试</strong></p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最重要的三个字是：谢谢您</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最重要的两个字是：咱们</p>
<p>l&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>最重要的一个字是：您</strong></p>
<p><strong>14、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>牢骚效应</strong></p>
<p>凡是公司中有对工作发牢骚的人，那家公司或老板一定比没有这种人或有这种人而把牢骚埋在肚子里的公司要成功得多。</p>
<p>提出者：美国密歇根大学社会研究院<br />
点评：1、牢骚是改变不合理现状的催化剂。2、牢骚虽不总是正确的，但认真对待牢骚却总是正确的。</p>
<p>&nbsp;</p>
<p><strong>15、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>一分钟&#8221;</strong><strong>管理法则</strong></p>
<p>目前，西方许多企业纷纷采用&#8220;一分钟&#8221;管理法则，并取得了显著的成效。具体内容包括一分钟目标、一分钟赞美及一分钟惩罚。具体地说：1、&#8220;一分钟目标&#8221;，就是要求企业中的每个人都将自己的主要目标和职责随时记在一张纸上，每一个目标及其检验<a href="http://www.csai.cn/incsearch/search.asp?key=%B1%EA%D7%BC" target="_blank"><font color="#333333">标准</font></a>都应该在250个字内表达清楚，一个人在一分钟内能读完。这样不仅便于每个人明确自己为何而干、如何去干，而且还可以据此定期检查自己的工作业绩；2、&#8220;一分钟赞美&#8221;，就是领导要花费不长的时间，及时对员工的业绩加以赞美，这样可以促使每位员工明确自己所做的事情、更加努力地工作，起到一种激励和鞭策作用，充分激发员工的积极性和创造性，使其不断向完美的方向发展；3、&#8220;一分钟惩罚&#8221;，是指对于应该做好但却没有做好的事情，领导要对相关人员进行及时批评，指出其错误，然后提醒他，你是如何器重他，不满的是他此时此地的工作。这样可使做错事的人乐于接受批评，达到&#8220;惩前毖后、治病救人&#8221;的效果，避免类似错误的再度发生。</p>
<p><strong>16、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>热炉&#8221;</strong><strong>法则</strong></p>
<p>&#8220;热炉&#8221;法则不仅形象地阐述了规章制度的权威性，而且活灵活现地描述了惩处所需掌握的原则：（1）热炉火红，不用手去摸也知道炉子是热的，是会灼伤人的，这就是惩处的警告性原则。领导者要经常对下属进行规章制度<a href="http://www.csai.cn/incsearch/search.asp?key=%BD%CC%D3%FD" target="_blank"><font color="#333333">教育</font></a>，警告或劝戒不要触犯规章制度，否则会受到惩处。（2）每当碰到热炉，肯定会被火灼伤，这就是规章制度的权威性。也就是说只要触犯单位的规章制度，就一定会受到惩处。（3）当你碰到热炉时，立即就被灼伤，这就是惩处的即时性原则。惩处必须在错误行为发生后立即进行，决不拖泥带水，决不能有时间差，以达到及时改正错误行为的目的。（4）不管是谁碰到热炉，都会被灼伤，这就是规章制度的公平性原则。</p>
<p><strong>17、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>金鱼缸&#8221;</strong><strong>法则</strong></p>
<p>金鱼缸是玻璃做的，透明度很高，不论从哪个角度观察，里面的情况都一清二楚，这就是管理上的&#8220;金鱼缸&#8221;法则。&#8220;金鱼缸&#8221;法则运用到管理中，就是要求领导者必须增加规章制度和各项工作的透明度。各项规章制度和工作有了透明度，领导者的行为就会置于员工的监督之下，就会有效地防止领导者滥用权力，从而强化领导者的自我约束机制。同时，员工在履行监督义务的同时，自身的主人翁意识和责任感得到极大的提升，而敬业、爱岗和创新的精神也必将得到升华。</p>
<p><strong>18、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>南风&#8221;</strong><strong>法则</strong></p>
<p>&#8220;南风&#8221;法则也称&#8220;温暖&#8221;法则，源于法国作家拉封丹写过的一则寓言：北风和南风比威力，看谁能把行人身上的大衣脱掉。北风首先吹得人寒冷刺骨，结果行人为了抵御北风的侵袭，便把大衣裹得紧紧的。南风则徐徐吹动，顿时风和日丽，行人觉得温暖如春，随之开始解开纽扣，继而脱掉大衣，最终南风获得了胜利。这则寓言形象地说明一个道理：温暖胜于严寒、柔性胜于刚性。领导者在管理中运用&#8220;南风&#8221;法则，就是要尊重和关心员工，以员工为本，多点&#8220;人情味&#8221;，少点官架子，尽力解决员工日常生活中的实际困难，使员工真正感觉到领导者给予的温暖，从而激发他们工作的积极性。</p>
<p><strong>19、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>刺猬&#8221;</strong><strong>法则</strong></p>
<p>&#8220;刺猬&#8221;法则讲的是：两只困倦的刺猬，由于寒冷而拥在一起。可因为各自身上都长着刺，刺得对方怎么也睡不舒服。于是它们离开了一段距离，但又冷得受不了，于是凑到一起。几经折腾，两只刺猬终于找到了一个合适的距离，既能互相获得对方的温暖又不致于被扎。&#8220;刺猬&#8221;法则就是管理和人际交往中的&#8220;心理距离效应&#8221;。心理学研究认为：领导者要搞好工作，就应该与员工保持亲密关系，这样做可以获得他们的尊重。与员工保持一定的心理距离，不仅可以避免员工之间的嫉妒和紧张，而且可以减少他们的恭维、奉承、行贿等行为，防止与员工称兄道弟、吃喝不分，并在工作中丧失原则。事实上，雾里看花，水中望月，给人的是&#8220;距离美&#8221;的感觉，管理上也是如此。一个原本很受员工敬佩的领导者，往往由于与员工&#8220;亲密无间&#8221;，就会使自己的缺点显露无遗，结果在不知不觉中丧失了严肃性，不利于对其更进一步的管理。另外，&#8220;刺猬&#8221;法则还启示我们，彼此间的亲密协作是必不可少的，员工之间、管理者与员工之间、管理者之间，尽管每个人都有其特点和个性，但各自为战在工作中却是不可取的，&#8220;独木难成林&#8221;、众人划桨开大船就是这个道理。线务局的工作千头万绪，各位局领导、中层干部、管理人员，各区域局、各部室都要各司其职、各负其责、立足本岗、发挥作用，同时也要注意分工不分家、补台不包办、到位不越位，切实形成合力、发挥<a href="http://www.csai.cn/incsearch/search.asp?key=%CD%C5%B6%D3" target="_blank"><font color="#333333">团队</font></a>作用。</p>
<p><strong>20、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>青蛙原理&#8221;</strong></p>
<p>关于&#8220;问题管理&#8221;有个著名的&#8220;青蛙原理&#8221;，说的是如果把一只青蛙扔进沸水中，青蛙肯定会马上跳出来。但是如果把一只青蛙放入冷水中逐渐加温，青蛙则会在不知不觉中丧失跳出去的能力，直至被热水烫死。这个原理是用来形容企业中存在的两种性质的问题，即显性问题和隐性问题。人们对显性问题的反应就如同青蛙对沸水的反应一样，会马上采取相应的措施，及时地将其扼杀在萌芽状态；而隐性问题由于自身的隐匿性，不易被发现，往往是等到发现时，已经对企业酿成了严重的损失。这就启示我们，很多线路障碍都是一些不起眼的小问题日积月累的结果，有客观的，但是也有主观的，跟我们的部分线务员在巡回或随工配合中的麻痹大意有关，听任一些小问题长期自由发展，最终酿成了影响线路通畅的大祸。&#8220;冰冻三尺，非一日之寒&#8221;，因此我们要时刻关注潜在的问题，而不是等小问题变大了、危机降临了再临时抱佛脚。</p>
<p><strong>21、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>鲶鱼效应</strong></p>
<p>&#8220;鲶鱼效应&#8221;来自一个古老的传说：一个小渔村的渔民靠到深海捕捉沙丁鱼（一种比较懒的鱼）为生。但由于捕鱼点距离陆地比较远，渔民捕的鱼运回渔村时，往往死掉大半，很难卖出好价钱。只有一个渔翁，他运回陆地的鱼，都是活的，总能卖出好价钱，但是他从来不让人看他的鱼舱。直到他死后，好奇的村民才发现，原来他的鱼舱里总是放着一条鲶鱼。由于鲶鱼是以捕食沙丁鱼为生，所以鲶鱼在鱼舱里会不停地追逐沙丁鱼，结果一些老弱的沙丁鱼被吃掉，但其他的沙丁鱼由于总在不停游动，所以都活着到岸。而其他渔船所捕的沙丁鱼静止不动，结果一大半都会死掉。这个传说告诉我们一个浅显的道理：&#8220;生于忧患、死于安乐&#8221;，如果一个企业缺少活力与竞争意识，没有生存的压力，就如同&#8220;沙丁鱼&#8221;一样，在&#8220;鱼舱&#8221;里混吃混喝，必然会被日益残酷的市场竞争所淘汰。一个员工也是如此，长期安于现状、不思进取，必然会成为时代的弃儿。</p>
<p><strong>22、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&nbsp;&#8220;</strong><strong>走动式&#8221;</strong><strong>管理</strong></p>
<p>这种管理方式属于最典型的柔性管理，目的很明确，就是要求企业的管理层要经常深入到基层和员工群众中去，体察民意、了解实情，与员工打成一片，从而增强领导层的亲和力和企业的凝聚力，激发员工的自豪感、自信心，起到上下一心、团结一致、共同进步的理想效果。&#8220;走动式&#8221;管理启示我们：一个整天忙忙碌碌、足不出户的领导决不是好领导，而事无巨细、事必躬亲的领导也不是好领导，只有削掉&#8220;椅子背儿&#8221;，从办公室中解放出来、深入基层与员工群众中去，才能取得事半功倍的效果。</p>
<p>23、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>&#8220;垃圾桶&#8221;理论</strong></p>
<p>　　荷兰有一个城市为解决垃圾问题而购置了垃圾桶，但由于人们不愿意使用垃圾桶，乱扔垃圾现象仍十分严重。该市卫生机关为此提出了许多解决办法。第一个方法是：把对乱扔垃圾的人的罚金从２５元提高到５０元。实施后，收效甚微。第二个方法是：增加街道巡逻人员的人数，成效亦不显著。后来，有人在垃圾桶上出主意：设计了一个电动垃圾桶，桶上装有一个感应器，每当垃圾丢进桶内，感应器就有反应而启动录音机，播出一则故事或笑话，其内容还每两周换一次。这个设计大受欢迎，结果所有的人不论距离远近，都把垃圾丢进垃圾桶里，城市因而变得清洁起来。</p>
<p>　　在垃圾桶上安装感应式录音机，丢垃圾进去播出一则故事或笑话，效果远比那些惩罚手段好得多，既省钱，又不会让人们感到厌恶。同样，要解决员工在工作期间偷懒的问题，用监管和处罚的手段实际上也是很难奏效的，因为员工的工作成效主要还是要靠其用心努力。员工偷懒，是故意偷懒还是忙里偷闲？是员工自身的原因还是公司管理出了问题？具体问题要具体分析。在处理员工偷懒问题上，加强沟通很重要。须注意的是，让员工超时且拘束地工作，已是不合时宜的管理方法；给员工多点理解、关心和体谅，会有助于发挥员工的工作积极性和创造力。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p><strong>24、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>最高气温效应</strong></p>
<p>　　每天最热总是下午２时左右，我们总认为这个时候太阳最厉害，其实这时的太阳早已偏西，不再是供给最大热量的时候了。此时气温之所以最高，不过是源于此前的热量积累。现实中因为缺乏这种判断——一种未雨绸缪的认识，从而使一个又一个企业管理者败走麦城的，为数实在不少。因为在企业虎虎有生气、效益直线上升的当口，管理者最容易被那种热火朝天的景象挡住识别的慧眼。</p>
<p>　　一个优秀的管理者，可以不拥有渊博的知识，可以不是善于煽情的鼓动家，甚至可以连超常的勤奋都没有，但他一定要有敏锐的头脑和活跃的思维，能够捕捉坏苗头、发现新苗头和催生新苗头。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p>25、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>互惠关系定律</strong></p>
<p>　　&#8220;给予就会被给予，剥夺就会被剥夺。信任就会被信任，怀疑就会被怀疑。爱就会被爱，恨就会被恨。&#8221;这就是心理学上的互惠关系定律。人是三分理智、七分感情的动物。士为知己者死，从业者可以为认可自己存在价值的上司鞠躬尽瘁。当你真诚地帮助员工的时候，员工才能真正地帮助你！</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p>26、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>圣人理论</strong></p>
<p>　　贝里奇担任美国美孚石油公司董事长时，有一次看到本公司一名青工跪着擦地板，擦一下还叩一下头，觉得奇怪，便上前询问。青工说他是在感谢一位圣人帮他找到这份工作、使他有了饭碗。贝里奇心灵受到震撼，沉思了一会儿说：&#8220;我在南非的温特胡克也遇到过一个&#8216;圣人&#8217;，我今天取得了这样的成就全靠他。这位&#8216;圣人&#8217;乐于助人，你愿意见见他吗？&#8221;青工说：&#8220;我现在仅能赚钱糊口，如果这位&#8216;圣人&#8217;能使我赚更多的钱，我就用以感谢所有曾关心过我这个孤儿的好心人。&#8221;于是贝里奇给青工假期，让他去见那位&#8220;圣人&#8221;。一个月后，青工风尘仆仆地回到公司，说：&#8220;董事长先生，我历经千辛万苦，爬上那座人迹罕至的大雪山，山上除了我，根本没有什么圣人。&#8221;贝里奇说：&#8220;这就对了，除了你，根本没有什么圣人！&#8221;这位青工就是后来接任美孚石油公司总经理的贾姆纳。２０００年出席在上海召开的世界经济论坛大会时，贾姆纳在记者招待会上说了一句浓缩人生精华的名言：&#8220;你发现自己的那一天，就是你遇到圣人的时候。&#8221;这就是贾姆纳对贝里奇的&#8220;圣人理论&#8221;的精辟解释。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p>27、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong>海因里希法则</strong></p>
<p>　　&#8220;海因里希法则&#8221;是美国人海因里希通过分析工伤事故的发生概率，为保险公司的经营提出的法则。海因里认为在一件重大灾害的背后，有２９件轻度灾害，还有３００件有惊无险的体验。这一法则完全可以用于企业的安全管理上，即在一件重大的事故背后必有２９件&#8220;轻度&#8221;的事故，还有３００件潜在的隐患。可怕的是对潜在性事故毫无觉察，或是麻木不仁，结果导致无法挽回的损失。了解&#8220;海因里希法则&#8221;的目的，是通过对事故成因的分析，让人们少走弯路，把事故消灭在萌芽状态。例如，东日本铁道公司为使员工认识事故的严重性，建立起&#8220;失败博览馆&#8221;，丰田公司专门建立了一处模拟汽车事故的场所，让人们体验汽车失控时的危险。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p><strong>28、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>超限效应</strong></p>
<p>　　刺激过多、过强和作用时间过久而引起心理极不耐烦或反抗的心理现象，称之为&#8220;超限效应&#8221;。</p>
<p>　　超限效应在批评教育中时常发生。如：当某人做错某事后，管理者如果一次、两次、三次，甚至四次、五次地重复对一件事作同样的批评，使他从内疚不安变得不耐烦，变得反感讨厌，被逼急了，还会出现&#8220;我偏这样&#8221;的反抗心理和行为。因为他一旦受到批评，总是需要一段时间才能恢复心理平衡，受到重复批评时，他心里会嘀咕：&#8220;怎么这样对待我？&#8221;他挨批评的心情就无法复归平静，反抗心理就高亢起来。</p>
<p>　　可见，管理者对下属的批评不能超过限度，应对下属&#8220;犯一次错，只批评一次&#8221;。如果非要再次批评，那也不应简单重复，要换个角度，换种说法。这样，员工才不会觉得同样的错误被&#8220;揪住不放&#8221;，厌烦心理、逆反心理也会随之减低。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p><strong>29、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>&#8220;弼马瘟&#8221;效应</strong></p>
<p>　　两千多年前，我国一些养马的人在马厩中养猴，以避马瘟。据有关专家分析，因为猴子天性好动，这样可以使一些神经质的马得到一定的训练，使马从易惊易怒的状态中解脱出来，对于突然出现的人或物、以及声响等不再惊恐失措。马是可以站着消化和睡觉的，只有在疲惫和体力不支或生病时才卧倒休息。在马厩中养猴，可以使马经常站立而不卧倒，这样可以提高马对吸血虫病的抵抗能力。在马厩中养猴，以&#8220;辟恶，消百病&#8221;，养在马厩中的猴子就是&#8220;弼马瘟&#8221;，&#8220;弼马瘟&#8221;所起的作用就是&#8220;弼马瘟&#8221;效应。在一个经济组织中，也应该配备&#8220;弼马瘟&#8221;式的人物，以增强员工的活力，避免疲沓和懈怠，进而增进整个组织的活力。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p><strong>30、&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong> <strong>懒蚂蚁效应</strong></p>
<p>　　生物学家研究发现，成群的蚂蚁中，大部分蚂蚁很勤劳，寻找、搬运食物争先恐后，少数蚂蚁却东张西望不干活。当食物来源断绝或蚁窝被破坏时，那些勤快的蚂蚁一筹莫展。&#8220;懒蚂蚁&#8221;则&#8220;挺身而出&#8221;，带领众伙伴向它早已侦察到的新的食物源转移。著名经济学家、北京大学教授郑学益在阐述市场营销理念时，以上述现象作类比：相对而言，在蚁群中的&#8220;懒蚂蚁&#8221;更重要，在企业中注意观察市场、研究市场、把握市场的人更重要，这就是所谓的&#8220;懒蚂蚁效应&#8221;。</p>
<img src ="http://www.blogjava.net/tangbao/aggbug/310528.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2010-01-22 15:28 <a href="http://www.blogjava.net/tangbao/archive/2010/01/22/310528.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>sola</title><link>http://www.blogjava.net/tangbao/archive/2010/01/17/309867.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Sun, 17 Jan 2010 09:53:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2010/01/17/309867.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/309867.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2010/01/17/309867.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/309867.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/309867.html</trackback:ping><description><![CDATA[http://zhidao.baidu.com/question/50571500.html?fr=ala0
<img src ="http://www.blogjava.net/tangbao/aggbug/309867.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2010-01-17 17:53 <a href="http://www.blogjava.net/tangbao/archive/2010/01/17/309867.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>大话JAVA设计模式</title><link>http://www.blogjava.net/tangbao/archive/2007/10/30/156874.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Tue, 30 Oct 2007 02:27:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2007/10/30/156874.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/156874.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2007/10/30/156874.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/156874.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/156874.html</trackback:ping><description><![CDATA[<div class="f14 p90 pl10">Factory <br />
Singleton(单态) <br />
Builder <br />
Prototype(原型) <br />
Flyweight <br />
Bridge <br />
Decorator(油漆工) <br />
Composite(组合) <br />
Adapter(适配器) <br />
Proxy(代理) <br />
Facade(外观 总管 Manager) <br />
Visitor <br />
Observer</div>
<a name="71998825">
<div class="f14 p90 pl10">1、FACTORY?追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说&#8220;来四个鸡翅&#8221;就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 <br />
<br />
2、BUILDER?MM最爱听的就是&#8220;我爱你&#8221;这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出&#8220;我爱你&#8221;这句话了，国外的MM也可以轻松搞掂，这就是我的&#8220;我爱你&#8221;builder。（这一定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 <br />
<br />
3、FACTORY METHOD?请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说&#8220;要一个汉堡&#8221;，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 <br />
<br />
4、PROTOTYPE?跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 <br />
<br />
5、SINGLETON?俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道&#8220;老公&#8221;，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事) 单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的&#8220;单一实例&#8221;的需求时才可使用。 [b:9ceca65206]结构型模式[/b:9ceca65206] <br />
<br />
6、ADAPTER?在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我) 适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。 <br />
<br />
7、BRIDGE?早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我&#8220;早上碰到MM新做了个发型怎么说&#8221;这种问题，自己用BRIDGE组合一下不就行了 桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 <br />
<br />
8、COMPOSITE?Mary今天过生日。&#8220;我过生日，你要送我一件礼物。&#8221;&#8220;嗯，好吧，去商店，你自己挑。&#8221;&#8220;这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。&#8221;&#8220;喂，买了三件了呀，我只答应送一件礼物的哦。&#8221;&#8220;什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。&#8221;&#8220;&#8230;&#8230;&#8221;，MM都会用Composite模式了，你会了没有？ 合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 <br />
<br />
9、DECORATOR?Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上&#8220;最好的的礼物，就是爱你的Fita&#8221;，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来&#8230;&#8230;，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？ 装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 <br />
<br />
10、FACADE?我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。 门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 <br />
<br />
11、FLYWEIGHT?每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。 享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。 <br />
<br />
12、PROXY?跟MM在网上聊天，一开头总是&#8220;hi,你好&#8221;,&#8220;你从哪儿来呀？&#8221;&#8220;你多大了？&#8221;&#8220;身高多少呀？&#8221;这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自己的回答，接收到其他的话时再通知我回答，怎么样，酷吧。 代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。 [b:9ceca65206]行为模式[/b:9ceca65206] <br />
<br />
13、CHAIN OF RESPONSIBLEITY?晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上&#8220;Hi,可以做我的女朋友吗？如果不愿意请向前传&#8221;，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑! 责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接 起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。 <br />
<br />
14、COMMAND?俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：&#8220;我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。&#8221;， 命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。 <br />
<br />
15、INTERPRETER?俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。 解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。 <br />
<br />
16、ITERATOR?我爱上了Mary，不顾一切的向她求婚。 Mary：&#8220;想要我跟你结婚，得答应我的条件&#8221; 我：&#8220;什么条件我都答应，你说吧&#8221; Mary：&#8220;我看上了那个一克拉的钻石&#8221; 我：&#8220;我买，我买，还有吗？&#8221; Mary：&#8220;我看上了湖边的那栋别墅&#8221; 我：&#8220;我买，我买，还有吗？&#8221; Mary：&#8220;我看上那辆法拉利跑车&#8221; 我脑袋嗡的一声，坐在椅子上，一咬牙：&#8220;我买，我买，还有吗？&#8221; &#8230;&#8230; 迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。 <br />
<br />
17、MEDIATOR?四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。 调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。 <br />
<br />
18、MEMENTO?同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。 备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。 <br />
<br />
19、OBSERVER?想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦 观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。 <br />
<br />
20、STATE?跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说&#8220;有事情啦&#8221;，对你不讨厌但还没喜欢上的MM就会说&#8220;好啊，不过可以带上我同事么？&#8221;，已经喜欢上你的MM就会说&#8220;几点钟？看完电影再去泡吧怎么样？&#8221;，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。 状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。 <br />
<br />
21、STRATEGY?跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。 策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。 <br />
<br />
22、TEMPLATE METHOD??看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)； 模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。 <br />
<br />
23、VISITOR?情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了； 访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。</a></div>
<img src ="http://www.blogjava.net/tangbao/aggbug/156874.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2007-10-30 10:27 <a href="http://www.blogjava.net/tangbao/archive/2007/10/30/156874.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>61条面向对象设计的经验原则</title><link>http://www.blogjava.net/tangbao/archive/2007/10/30/156873.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Tue, 30 Oct 2007 02:26:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2007/10/30/156873.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/156873.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2007/10/30/156873.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/156873.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/156873.html</trackback:ping><description><![CDATA[<p align="center">作者：Arthur J.Riel &nbsp;&nbsp;&nbsp;&nbsp;来自：《OOD 启思录》</p>
<p>　　<strong>你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。</strong></p>
<p align="right">-----Arthur J.Riel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>
<p>　　(1)所有数据都应该隐藏在所在的类的内部。p13 </p>
<p>　　(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15 </p>
<p>　　(3)尽量减少类的协议中的消息。p16 </p>
<p>　　(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16 </p>
<p>　　(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17 </p>
<p>　　如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 </p>
<p>　　(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17 </p>
<p>　　(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 p18 </p>
<p>　　(8)类应该只表示一个关键抽象。p19 </p>
<p>　　包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 . </p>
<p>　　(9)把相关的数据和行为集中放置。p19 </p>
<p>　　设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 </p>
<p>　　(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19 </p>
<p>　　朝着稳定的方向进行依赖. </p>
<p>　　(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23 </p>
<p>　　(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。p30 </p>
<p>　　(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30 </p>
<p>　　规划一个接口而不是实现一个接口。 </p>
<p>　　(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30 </p>
<p>　　(15)对包含太多互不沟通的行为的类多加小心。p31 </p>
<p>　　这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 </p>
<p>　　(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。p33 </p>
<p>　　(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36 </p>
<p>　　(18)从你的设计中去除不需要的类。p38 </p>
<p>　　一般来说，我们会把这个类降级成一个属性。 </p>
<p>　　(19)去除系统外的类。p39 </p>
<p>　　系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。 </p>
<p>　　(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40 </p>
<p>　　(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。p43 </p>
<p>　　(22)尽量减少类的协作者的数量。p52 </p>
<p>　　一个类用到的其他类的数目应当尽量少。 </p>
<p>　　(23)尽量减少类和协作者之间传递的消息的数量。p55 </p>
<p>　　(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。p55 </p>
<p>　　(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55 </p>
<p>　　(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。p55 </p>
<p>　　(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57 </p>
<p>　　(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57 </p>
<p>　　当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。 </p>
<p>　　(29)让系统功能在窄而深的继承体系中垂直分布。p58 </p>
<p>　　(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60 </p>
<p>　　(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60 </p>
<p>　　(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。p60 </p>
<p>　　(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。p60 </p>
<p>　　(34)类必须知道它包含什么，但是不能知道谁包含它。p61 </p>
<p>　　(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。p61 </p>
<p>　　(36)继承只应被用来为特化层次结构建模。p74 </p>
<p>　　(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。p74 </p>
<p>　　(38)基类中的所有数据都应当是私有的，不要使用保护数据。p75 </p>
<p>　　类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。 </p>
<p>　　(39)在理论上，继承层次体系应当深一点，越深越好。p77 </p>
<p>　　(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。p77 </p>
<p>　　(41)所有的抽象类都应当是基类。p81 </p>
<p>　　(42)所有的基类都应当是抽象类。p82 </p>
<p>　　(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。p85 </p>
<p>　　(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。 p88 </p>
<p>　　(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。 p89 </p>
<p>　　(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。 p89 </p>
<p>　　(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。p89 </p>
<p>　　(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。 p96 </p>
<p>　　(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。p97 </p>
<p>　　(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。p99 </p>
<p>　　(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。 p103 </p>
<p>　　(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。p103 </p>
<p>　　(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。p108 </p>
<p>　　(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。p112 </p>
<p>　　(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。p120 </p>
<p>　　(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？p121 </p>
<p>　　(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。p122 </p>
<p>　　(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。p135 </p>
<p>　　(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。p140 </p>
<p>　　(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 p149 </p>
<p>　　(61)不要绕开公共接口去修改对象的状态。p164</p>
<img src ="http://www.blogjava.net/tangbao/aggbug/156873.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2007-10-30 10:26 <a href="http://www.blogjava.net/tangbao/archive/2007/10/30/156873.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>2007-10-29 震荡规律</title><link>http://www.blogjava.net/tangbao/archive/2007/10/29/156593.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Mon, 29 Oct 2007 02:15:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2007/10/29/156593.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/156593.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2007/10/29/156593.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/156593.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/156593.html</trackback:ping><description><![CDATA[1.开始是权重股<br />
2.然后是银行股
<img src ="http://www.blogjava.net/tangbao/aggbug/156593.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2007-10-29 10:15 <a href="http://www.blogjava.net/tangbao/archive/2007/10/29/156593.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>2007-10-29 炒股教训</title><link>http://www.blogjava.net/tangbao/archive/2007/10/29/156590.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Mon, 29 Oct 2007 02:02:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2007/10/29/156590.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/156590.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2007/10/29/156590.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/156590.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/156590.html</trackback:ping><description><![CDATA[1.炒股在高点时是不能买进的<br />
2.股票总有跌下来的时候<br />
3.股票也总会涨上去的<br />
4.买入时要考虑好这几周的形式<br />
5.不能着急
<img src ="http://www.blogjava.net/tangbao/aggbug/156590.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2007-10-29 10:02 <a href="http://www.blogjava.net/tangbao/archive/2007/10/29/156590.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>开发测试</title><link>http://www.blogjava.net/tangbao/archive/2007/10/23/155301.html</link><dc:creator>糖包</dc:creator><author>糖包</author><pubDate>Tue, 23 Oct 2007 07:13:00 GMT</pubDate><guid>http://www.blogjava.net/tangbao/archive/2007/10/23/155301.html</guid><wfw:comment>http://www.blogjava.net/tangbao/comments/155301.html</wfw:comment><comments>http://www.blogjava.net/tangbao/archive/2007/10/23/155301.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/tangbao/comments/commentRss/155301.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/tangbao/services/trackbacks/155301.html</trackback:ping><description><![CDATA[今天看到测试机上我负责的那个模块里<br />
有三处bug<br />
测试时没有仔细测
<img src ="http://www.blogjava.net/tangbao/aggbug/155301.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/tangbao/" target="_blank">糖包</a> 2007-10-23 15:13 <a href="http://www.blogjava.net/tangbao/archive/2007/10/23/155301.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>