http://oldboy-bj.taobao.com/

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=251&extra=page%3D33、 解决过多依赖实现类问题在该例的测试类Test.java中，通过Fruit apple = new Apple();来获得对象，造成了程序过多的依赖实现类，与实现类过度耦合，学习设计模式后，我们可以考虑采用工厂模式来实现,可对代码进行如下改进：增加工厂类FruitGardener.java，该类的工厂方法如下：publicstatic Fruit factory(String fruitType) ...{if (fruitType.equalsIg 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=253&extra=page%3D3设计模式是面向对象编程的热门话题之一，越来越多的开发人员认识到设计模式的重要性。采用各种语言实现设计模式的文章也越来越多，但是很多开发人员发现很难将设计模式与实际开发中需要解决的具体问题相联系。因为使用设计模式的难点往往不在于模式的实现，而在于很难确定哪种模式可以在现实的应用场景中采用，从而导致了在现实的项目中，面对客户的压力，我们总是采用最直截了当的方法解决问题，来不及多考虑这些方法的优劣，即使明知将带来更大的麻烦也必须如此。有些时候因为选择了不恰当的 阅读全文

摘要： 现在你对“什么是设计模式”已经有了感性认识，也许有人会问：“为什么要学习设计模式呢？”原因有很多，一些非常明显，而另一些则不那么明显。学习模式最常见的理由是因为我们可以借其：● 复用解决方案——通过复用已经公认的设计，我能够在解决问题时取得先发优势，而且避免重蹈前人覆辙。我可以从学习他人的经验中获益，用不着为那些总是会重复出现的问题再次设计解决方案了。● 确立通用术语——开发中的交流和协作都需要共同的词汇基础和对问题的共识。设计模式在项目的分析和设计阶段提供了共同的基准点。模式还为我们提供了观察问题、设计过程和面向对象的更高层次的视角，这将使我们从“过早处理细节”的桎梏中解放出来。等你读完本书 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=255&extra=page%3D3最近一直在看《Design Patterns: Elements of Reusable Object-Oriented Software》这本书，不知道看过这本书的人是不是有摸不到头绪，无处下手的感觉， OK，和我一样/hand. 书里面讲述的23种模式经常把我弄的一蹋糊涂，这本书不看个三、四遍以上是很难理解的， 而且即便看了几遍， 也是很难把握住精髓。 里面讲解的例子是用C++和SMALLTALK这两种OO语言。对于我这种对C++半生不熟的笨鸟来说 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=256&extra=page%3D3如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术 Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解CoR的优点： 因为无法预知来自外界（客户端）的请求是属于哪种类型，每个类如果碰到它不能处理的请求只要放弃就可以。 缺点是效率低，因为一个请求的完成可能要遍历到最后才可能完成，当然也可以用树的概念优化。 在Java AWT1.0中，对于鼠标按 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=257&extra=page%3D3目前整个开发社区对AOP(Aspect Oriented Programing)推崇备至，也涌现出大量支持AOP的优秀Framework,--Spring, JAC, Jboss AOP 等等。AOP似乎一时之间成了潮流。Java初学者不禁要发出感慨，OOP还没有学通呢，又来AOP。本文不是要在理论上具体阐述何为AOP, 为何要进行AOP . 要详细了解学习AOP可以到它老家http://aosd.net去瞧瞧。这里只是意图通过一个简单的例子向初学者展示 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=39&extra=page%3D4为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这*子系统更加容易使用。适用性1.当你要为一个*杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给*些不需要定制子系统的用户带来一些使用上的困难。Fa*ade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足*，而那些需要更多的可定制性的用户可以越 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=38&extra=page%3D4动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模*相比生成子类更为*活。适用性1.在不影响其他*象的情况下，以动态、透明的方式给单个对象添加职责。2.处理那些可以撤消的职责。3.当不能采用生成子类的方法进行扩充时。参与者1.Component定义一个对象接口，可以给这些对象动态地添加职责。2.ConcreteComponent定义一个对象，可以给这个对象添加一些职责。3.Decorator维持一个指向Component对象的指针，并 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=37&extra=page%3D4将对象组合成树形结构以表示"部分-整体"的层次结构。"Composite使得用户对单个对象和组合对*的使用具有一致性。"适用性1.你想表示对象的部分-整*层次结构。2.你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。参与者1.Component为组合中的对象声明接口。在适当的情况下，实现所有类共有接口的缺省行为。声明一个接口用于访问和管理Component的子组件。(可选)在递归结构中定义一个接口，用于访问一个父部件，并在合* 阅读全文

摘要： http://35java.com/zhibo/forum.php?mod=viewthread&tid=36&extra=page%3D4将抽象部分与它*实现部分分离，使它们都可以独立地变化。适用性1.你不希望在抽*和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以*选择或者切换。2.类的抽象以及它的实现都应该可以通*生成子类的方法加以扩充。这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。3.对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。4.正如在意图一节的第一个类图中所示的那样，有许多 阅读全文