每个开发者都必须掌握哪些设计模式？
我对Java Web开发人员使用Spring和Hibernate的情境感兴趣。我经常听说深入了解设计模式在使用这些框架时非常重要。有人可以列出具体的内容吗？
例如，我知道理解抽象工厂、工厂模式、单例模式等是绝对必要的。我正在寻找一个全面的列表。
11个回答
22
控制反转
如果你要设计解耦合系统，就需要知道如何正确地链接类之间的依赖关系。
命令模式及其变种
特别是在Java中，由于语言本身缺少闭包和函数指针，学习如何将一个功能作为对象传递给另一个方法是非常重要的。
工厂模式
工厂在Java框架中无处不在，学习为什么和何时使用工厂模式非常重要。
单例模式（模式和反模式）
学习如何负责地使用单例模式有助于理解你可能正在阅读的其他人代码中的陷阱。
总的来说，理解设计模式的原因比掌握具体实现方式更重要。知道什么时候不适用某种模式和什么时候适用同样重要。
- Elijah
5
每个人都应该了解 Singleton，但也要知道什么时候不要使用它！在我工作的一个项目中，它目前是造成很多痛苦的根源。
Singleton 使代码难以理解和跟踪，并使编写单元测试变得更加困难。我喜欢这篇博客文章 Singletons are Pathological Liars。
Singleton 使代码难以理解和跟踪，并使编写单元测试变得更加困难。我喜欢这篇博客文章 Singletons are Pathological Liars。
- Greg Hewgill
1
Greg - 你有没有感觉到这里很多人不懂得讽刺的意味？ - Martin Beckett
4
模型-视图-控制器只是列表上的一个，Spring有一个MVC框架：
- karim79
2
实际上，Spring有一个MVC模块（Spring MVC），但除此之外，它还有很多其他的功能。 - matt b
@matt b - 我错了，我猜想是因为SO上的许多问题都涉及到'Spring MVC'。 - karim79
4
大多数设计模式都很显而易见——如果你已经编程几年，你就已经知道并使用它们了。
我发现设计模式最大的优点是共享一组通用名称。如果有人说“回调”，那可能意味着很多事情，但如果有人说“监听器模式”，那就意味着一组更具体的调用，并暗示着对象之间更高级别的关系。
因此，实质上，阅读一本好的设计模式书籍，了解每种模式的名称，花一些时间了解你不知道的任何内容，你就可以开始工作了。
我不会完全忽略任何一个模式——它们都是不可或缺的。你应该能够识别出可能受益于特定模式的情况，并知道在哪里寻找更多信息。
我发现设计模式最大的优点是共享一组通用名称。如果有人说“回调”，那可能意味着很多事情，但如果有人说“监听器模式”，那就意味着一组更具体的调用，并暗示着对象之间更高级别的关系。
因此，实质上，阅读一本好的设计模式书籍，了解每种模式的名称，花一些时间了解你不知道的任何内容，你就可以开始工作了。
我不会完全忽略任何一个模式——它们都是不可或缺的。你应该能够识别出可能受益于特定模式的情况，并知道在哪里寻找更多信息。
- Bill K
2
我建议您获取并阅读《设计模式》一书，因为它可以帮助您掌握相关术语。
- Thorbjørn Ravn Andersen
2
但不要忘记基础知识 :)
带着眼泪面试Java开发人员 http://java.sys-con.com/node/1040135
- programmernovice
1
当然！我做的事情之一就是阅读《Head First》、《Core Java - Vol 1 & 2》、《Head first servlets》和《Effective Java》。我还没有完成这些书籍的阅读，需要经常阅读/参考，特别是《Effective Java》。我粗略地看了一下Spring，并理解了基本概念，但在我能够有所作为之前，似乎需要学习很多关于设计模式的知识。当我遇到问题时，我仍然会回到基础知识。Jon Skeet在这里发表了一篇有趣的文章：http://www.yoda.arachsys.com/java/learning.html - Shaw
1
这是对Greg Hewgill关于“单例模式是病态的说谎者”的评论，但我还不能发表评论。
那篇文章提出了一个有说服力的观点，但他的愤怒方向是错误的。正如他博客上的几位评论者所指出的那样，他的问题实际上是全局状态。他的代码修复仍然可以利用单例模式，并且仍然可以获得完全清晰和可测试性的增加。
重新阅读这篇文章。他不介意OfflineQueue需要初始化的Database实例，也不介意CreditCardProcessor需要初始化的OfflineQueue。他困扰的是这些依赖关系不可见，这会导致可维护性和可测试性的问题。
他的问题在于秘密的全局状态（这让我听起来像一个阴谋论者吗？）。
然而，他（在我看来）误解了秘密全局状态是单例模式的错。
这并不意味着我支持不必要的单例模式 - 当然，它们有缺点（包括明显的线程争用瓶颈可能性）。但我更喜欢明确我避免的做法。
我会选择这个：
那篇文章提出了一个有说服力的观点，但他的愤怒方向是错误的。正如他博客上的几位评论者所指出的那样，他的问题实际上是全局状态。他的代码修复仍然可以利用单例模式，并且仍然可以获得完全清晰和可测试性的增加。
重新阅读这篇文章。他不介意OfflineQueue需要初始化的Database实例，也不介意CreditCardProcessor需要初始化的OfflineQueue。他困扰的是这些依赖关系不可见，这会导致可维护性和可测试性的问题。
他的问题在于秘密的全局状态（这让我听起来像一个阴谋论者吗？）。
然而，他（在我看来）误解了秘密全局状态是单例模式的错。
这并不意味着我支持不必要的单例模式 - 当然，它们有缺点（包括明显的线程争用瓶颈可能性）。但我更喜欢明确我避免的做法。
顺便说一下，我会在重构时进一步进行操作 - 基于类名，我会在代码审查中断言CreditCardProcessor应该处理费用，所以不是他的：
card.charge(cardProcessor, 100);
我会选择这个：
cardProcessor.chargeCard (card, 100);
（是的，我用更易读的变量名替换了他的变量名 c 和 ccp ）
- CPerkins
1
除了您已经提到的
抽象工厂、工厂方法和单例模式，我认为以下模式也很有用：
桥接模式：抽象和实现可以独立变化
装饰器模式：在运行时更改对象的行为
中介者模式：在不同对象之间启用集中式通信媒介
责任链模式：如果您正在向Web服务请求添加过滤器，则此模式非常有用。
策略模式：如果您想通过检查参数在算法族中更改算法，则可以在运行时执行此操作
外观模式：如果您的系统中有许多服务，并且不想将所有服务都公开给客户端，请使用一个Facade类与其他服务交互。
sourcemaking提供了每个设计模式的详细信息：意图、结构、清单和经验法则。
还有一个SE问题肯定会对您有所帮助：
- Ravindra babu
1
Hibernate？那么工作单元是必须的http://martinfowler.com/eaaCatalog/unitOfWork.html
组合模式，在JUnit框架中存在。（Test-TestCase-TestSuite）
适配器、生成器、命令、模板方法和策略模式在实践中易于使用。
状态模式也帮助我清理继承源代码中的混乱。
- Karl
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接