摘要：概念：敏捷软件：是1990年被大家广泛讨论的一种软件开发，解决的主要是应对软件开发当中的变化。和“非敏捷”比起来其中主要区别是提倡业务专家与开发人员协同工作，尽可能的面对面进行沟通，频繁的交付新的版本，紧凑的自组织型团队，良好的应对需求变化方法。历史：敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。价值观（宣言）：个体与交互 重于 流程工具可用的软件 重于 跟踪文档客户协作 重于 合同谈判响应变化 重于 循规蹈矩敏捷原则：1. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。2. 我们的最高目标是，通过尽早和持续地交付有价值 阅读全文

摘要：定义：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。对象或类职责描述：1.Content：内容2.State：状态 UML图： 重点：1.状态转换可以由State类或者是Context类控制。2.使用状态模式通常会导致类的数量增加。应用场景：针对GreaterThen、In、LessThen等或者是更多区间范围，通常使用办法是if……else……使用状态模式可以做到对扩展开放，对修改关闭。具体代码实现：下载：代码 阅读全文

摘要：应用场景：1.当一个应用程序调用者与多个目标对象之间存在调用关系时，并且目标对象之间的操作很类似的时候。2.例如当一个目标对象内部的方法调用太复杂，或者内部的方法需要协作才能完成对象的某个特点操作时。3.有时候调用者调用目标对象后，需要回调一些方法。职责定义：1.Invoker：调用者对象。2.ICommand：用于解耦目标对象与调用者之间的抽象命令对象。要点：1.对请求部分进行封装，封装使用的是：ICommand。2.调用者：Invoker把ICommand作为参数加入自身，调用Execute()执行具体请求。优劣势描述：1.能较容易地建立一个命令队列2.在需要的情况下，可以较容易地将命令记 阅读全文

摘要：装饰者模式可以动态地给一个对象增加其他职责。就扩展对象功能来说，装饰者模式比生成子类更为灵活。 装饰者模式的应用场景：想透明并且动态地给对象增加新的职责的时候。给对象增加的职责，在未来存在增加或减少可能。用继承扩展功能不太现实的情况下，应该考虑用组合的方式。 装饰者模式的优点：通过组合而非继承的方式，实现了动态扩展对象的功能的能力。有效避免了使用继承的方式扩展对象功能而带来的灵活性差，子类无限制扩张的问题。充分利用了继承和组合的长处和短处，在灵活性和扩展性之间找到完美的平衡点。装饰者和被装饰者之间虽然都是同一类型，但是它们彼此是完全独立并可以各自独立任意改变的。遵守大部分GRASP原则和常用. 阅读全文

摘要：观察者模式定义了对象间的一种一对多依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。　　观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，让他们能够自动更新自己。　　观察者模式的组成:主题(Subject):把所有对观察者(ObServer)保存在一个集合中，主题有任意数量的观察者。主... 阅读全文

摘要：策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。　　策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现方式（算法）。实现可以相互替换。策略模式让实现的变化不会影响到调用对象。在不同的项目当中，关于验证的方式有所不同，比如身份证号码，邮政编码等。比如每个人都要“交个人所得税&rd... 阅读全文

摘要：开闭原则（Open Closed Principle）是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。Softeware entities like classes,modules and functions should be open for extension but closed for modifi... 阅读全文

摘要：定义：迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP）。一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心。含义：只和朋友交流朋友类的定义是这样... 阅读全文

摘要：接口隔离原则 Interface Segregation Principle定义：客户端不应该依赖它不需要的接口 类间的依赖关系应该建立在最小的接口上 我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。接口... 阅读全文

摘要：依赖倒置原则（Dependence Inversion Principle，DIP）的原始定义：高层模块不应该依赖底层模块，两者都应该依赖其抽象； 抽象不应该依赖细节； 细节应该依赖抽象。依赖倒置原则在Java语言中的表现是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的； 接口或抽象类不依赖于实现类； 实现类依赖接口或抽象类。依赖倒置原则实际上就是... 阅读全文

摘要：里氏替换原则(Liskov Substitution Principel)是解决继承带来的问题。继承的优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性； 提高代码的重用性； 子类可以形似父类，但又异于父类； 提高代码的可扩展性； 提高产品或项目的开放性。 继承的缺点：继承是侵入性的，只要继承就必须拥有父类的所有属性和方法； 降低代码的灵活性，子类必须拥有父类的属性和方法，让子类增... 阅读全文

摘要：定义：应该有且仅有一个原因引起类的变更。There should never be more than one reason for a class to change.优点：1、类的复杂性降低，实现什么职责都有清晰明确的定义；2、可读性提高，复杂性减低，可读性当然提高；3、可维护性提高，可读性提高，可维护性当然提高；4、变更引起的风险减低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改... 阅读全文

摘要：微软的一个文章：设计模式：Model View Presenter　　个人总结一下MVP模式　　M既是模型比如我们的实体模型层。　　V既是UI界面显比如控件，JS脚本等。　　P既是连接V与M的桥梁。V层不直接引用M层的内容，P层负责连接M层与V层。V层将控件传给P层，P层通过引用填充数据，或者是获取数据。　　总结起来就是：UI界面与逻辑代码的分离。逻辑代码与数据库操作的分离。逻辑代码的重用性，例如... 阅读全文

摘要：1.通过配置+反射，可以实现“开放封闭”原则，对扩展开放，对修改封闭。　　2.易维护，通过分层，将程序进行分层，进行职责划分。　　3.可用性提高。单独维护一个DLL文件即可。可以实现插拔操作。　　工厂方法+配置文件+反射，主要是一种思路的体现，通过这种方式可以扩展我们的思维方式。　　　　1.Yang.ISQL　　数据库操作的接口，作为Yang.MSSQL、Yang.Orac... 阅读全文