@塘外人

XP(Extreme Programming)http://xprogramming.com/index.phpKISS(Keep it simple, Stupid!)http://en.wikipedia.org/wiki/KISS_principleYAGNI(You Aren't Going to Need It)http://www.artima.com/weblog

1.支持的操作符有 "+", "-", "*", "/"2.撤销符号为"3.例如输入"1", "+", "2", "4.例如输入"100", "/", "2", "要求：1）使用TDD     2）使用命令模式5.简单类图设计6.单元测试package com.pattern.command;import junit.framewor

源代码就是设计Jack Reeves著 邓辉 译本文摘自《敏捷软件开发：原则、模式与实践》(清华大学出版社，2003年9月版)。这是一篇伟大的论文，该文撰写于1992年，作者在当时就能有这样的反思，实在是非常了不起。至今，我仍能记起当我顿悟并最终产生下面文章时所在的地方。那是1986年的夏天，我在加利福尼亚中国湖海军武器中心担任临时顾问。在这期间，我有幸参加了一

敏捷设计•全局视图和软件一起演化•设计尽可能适合当前系统，关注当前系统结构•增量地演化出系统最佳架构和设计•设计和架构过程是持续不断进行的•从根本上讲，源代码就是设计•敏捷设计是一个过程，不是一个事件，是一个持续的应用原则、模式以及实践来改进软件结构和可读性的过程•敏捷设计步骤–遵循敏捷实践去发现问题–应用设计原则去诊断问题–应用适当模式去解决问题

人的力量•过程和技术对于项目的结果只有次要的影响，首要的影响是人。•如果项目要取得成功，必须构建起具有合作精神、自组织的团队。•凝聚在一起的软件团队是最强大的软件开发力量。敏捷宣言•人和交互 > 过程和工具•可以工作的软件> 面面俱到的文档•客户合作 > 合同谈判•随时应对变化> 遵循计划人和交互 >过程和工具•沟通能力比技术能力更重要

按行为划分系统•程序的中心是行为•不基于行为的系统划分，基本上是严重错误的。•正是系统的行为为我们提供了第一个关于应该如何划分系统的线索水蒸气类•没有任何成员变量、状态•只是一个调用转换器•水蒸气类没有存在的必要虚拟抽象•抽象是非常微妙的•对抽象类，多问问：谁使用它们？•一个仅仅含有抽象方法并且不具有任何使用者的类，完全是一个无用的类

完整团队•客户、管理者、开发紧密工作在一起。•客户–指定义产品特性并排列特性优先级的人或团体。–同一公司的业务分析师、质量保证专家、市场专家；用户团体的代表；支付开发费用的人。–都是能和团队一起工作的成员。•客户或能代替客户的人最好和开发在同一个房间工作。用户故事•了解需求只要做到能估算的程度就够了。•必须知道存在很多细节及细节分类，但不必知道特

Command模式Command模式的3种用法Active object模式是对Command的应用是实现多线程的基础技术Active Object 并发模式在 Java 中的应用http://www.ibm.com/developerworks/cn/java/j-lo-activeobject/index.html模板方法与策略模式为什么说组

系统设计的本质•系统设计的本质是寻找隐藏于应用背后抽象•需求和用例不会表述或提及这些抽象，它们太过专注细节以至于不能表达底层抽象的一般性如何抽象•抽象需要根据需求的全局来展开•不能只按个别用例来展开•抽象就是归纳、总结，并提炼需求的共同逻辑关于数据库•数据库是实现细节！应该尽可能的推迟考虑数据库。有太多的应用程序之所以和数据库绑定在一起而