金桥坞

[size=medium]1.适配器模式 adapter:主要是用于一个接口和一个实现类的方法名不同时，通过实现该接口，集成该实现类实现一个适配器的作用。 object adapter :主要是实现接口，但不继承实现类，而是进行一个delegate（委托）。2.外观模式 facade模式，如果要解释最贴切的就是 demo，但是它的好处就是可重用。目的是减少集成度，...

import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;@RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration(locations={"classpath*:testAppContext.xml"})public class UserTypeTest { @Autowired private User

3. 使用dip和adapter来对3方库进行隔离，好处是低耦合和便于MOCK测试实践1. 从测试出发，学习和理解3方库2. 用好dip和adapter，对3方库隔离9. 单元测试测试驱动开发 tdd原则与实践1. 先写失败的测试代码，再完成编译通过2. 调整代码使测试通过，再进行下一步测试3. 重构时每次都只能调整一点，并保持测试通过4. 保持最高的测试代码质量，因为那是最好的稳定5. 保证测试的覆盖率6. 测试关注的是逻辑而不是性能7

◆　OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。　　◆　LSP，Liskov替换原则，派生类要与其基类自相容。 　　◆　DIP，依赖倒置原则，依赖于抽象而不是实现。 　　◆　ISP，接口隔离原则，客户只要关注它们所需的接口。 　　另外的六项是关于包的设计原则。在本文中，包是指一个二进制的可发布文件，比如.jar文件、或dll文件，而不是Java包或是C++的命名空间（译注3）。　　头三项包原则是关于包内聚性的，它们会告诉我们该把什么划分到包中：　　

.isDebugEnabled()){ // doyour things }   if(logger.isDebugEnabled()){ logger.debug(String.format("Registeredbean definition for imported @Configuration class %s",configBeanName)); } log.debug("查询搜索引擎失败，没有查询

adapter :主要是实现接口，但不继承实现类，而是进行一个delegate（委托）。2.外观模式 facade模式，如果要解释最贴切的就是 demo，但是它的好处就是可重用。目的是减少集成度，将各个功能分散到不同的类中，这样再通过一个facade来组合。3.组合模式 composites模式主要是为了灵活性，客户端可以统一的处理单个或多个对象4.桥接模式 减弱抽象类与其继承类之间的关系（低耦合）,主要是通过将一些共有方法进行归类，形成一个行为接口[/siz

<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->小心行事对所做的任何操作都应该精心思考过，否则你必将会为你的一时不小心付出代价 配合使用函数式编程 站在用户的角度审视自己的设计 自动化编码标准如果不遵守标准，打包失败标准也要实时变化...

[size=large]面向对象设计是什么？都包含了哪些内容？它所带来的好处是什么？需要你为之付出些什么？在如今这个年代，问这些问题似乎显得很愚蠢，因为这年头几乎每位软件开发人员都知道如何使用某种面向对象编程语言。可是这个问题还是很重要，因为在我看来，绝大多数人在使用这些语言的时候并不知道为什么，而且也不知该如何最充分的运用它们。软件业曾经爆发过的所有变革里，其中曾经有两个派系如此广泛的深...

[code="java"]import org.junit.Test;import org.junit.runner.RunWith;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.test.context.ContextConfiguration;...

什么是clean codeLater equals never.软件质量不仅关系到软件的效率，更加关系到软件的生存总结一下，大致满足以下几点就差不多了。1. 可读性强，清晰的表达思想，易读，易改2. 较高的运行效率3. 简单明了，单一职责，不要过度设计4. 高内聚，低耦合5. 包含单元测试1.命名原则1. 名字表现内容，让读者能通过名字即知道这个代表...

3.注释不要对差的代码增加注释，而是要去重构它。代码是最新的，而注释未必是最新的。所以会误导读者，从而使整个系统一片混乱原则1. 选择写干净的代码，而不是为差的代码添加注释。这样会越来越糟2. 用代码来描述你的想法，而不是注释。选择好的命名和组织合理的方法3. 最好的注释就是没有注释。先保证在没比写注释更好的方法时才选择用注释来补充说明，同时更要注意保证注释的正确性4....

5.对象和数据对象对象关注的更多的是它的行为，而数据对象更多关注的是它的数据结构原则1. 对象应尽量使用抽象，并不要盲目的给对象加上get和set2. 根据情况选择好是使用对象还是数据对象3. 迪米特法则，不用让对象包含和它关联不大的责任4. 责任链模式和oo思想5. 不要混合使用对象和数据对象实践1. 根据实际情形选择对象或是对象数据2. ...

8. 边界问题，三方库原则1. 不要让三方库渗透到整个业务代码中去，这样如果三方库更新或替换会要很大的代价2. 使用测试来验证和学习使用3方库3. 使用dip和adapter来对3方库进行隔离，好处是低耦合和便于MOCK测试实践1. 从测试出发，学习和理解3方库2. 用好dip和adapter，对3方库隔离9. 单元测试测试驱动开发 tdd原...

　 摘自：http://soft6.com/tech/6/65017.html；其实也就是ppp这本书上的一些基本原则。◆　SRP，单一职责原则，一个类应该有且只有一个改变的理由。 　　◆　OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。　　◆　LSP，Liskov替换原则，派生类要与其基类自相容。 　　◆　DIP，依赖倒置原则，依赖于抽象而不是实现。 　...

10. 类原则1. 良好的组织，对外的开发尽量的少2. 简短，遵循SRP原则 ， 高内聚，低耦合3. 运用tdd的实践，及时重构4. 拥抱变化，对扩展开发，遵循OCP原则5. 合理的使用模式11. 系统总的原则就是 大道至简 原则1. 层次，模块化，抽象2. 合理的利用AOP而不是滥用3. 从简，不要过度设计，简短低耦合4. 应用最新的技术和...

总结：建立数据字典，标准化日志格式  <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->Trace, debug , info , warn , error , fatal If(Log.isDebugEnabled()){ // doyour th...

代价 配合使用函数式编程 站在用户的角度审视自己的设计 自动化编码标准如果不遵守标准，打包失败标准也要实时变化 简单是最美的，大道至简  关于重构首先对现有的代码进行反思，总结，比较Thebest approach for restructuring starts by taking stock of theexistingcodebaseand the tests written against that code.Remem