每个开发人员必须知道的设计模式？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了每个开发人员必须知道的设计模式？相关的知识，希望对你有一定的参考价值。
每个开发人员必须知道的设计模式是什么？
我对使用Spring和Hibernate的Java Web开发人员的上下文感兴趣。我经常听说，设计模式方面的良好知识对于使用这些框架至关重要。任何人都可以列出具体细节吗？
例如，我知道理解抽象工厂和工厂模式，单例模式等是绝对必要的。我正在寻找一份全面的清单。
Inversion of Control
如果您要设计解耦系统，则需要知道如何正确链接类之间的依赖关系。
Command Pattern and Variants
特别是在Java中，由于缺少语言中的闭包和函数指针，因此必须学习如何将一个功能作为对象传递给另一个方法。
Factory Pattern
工厂在Java框架中无处不在，了解为何以及何时使用工厂模式至关重要。
Singleton (pattern and anti-pattern)
学习如何负责任地使用单例模式非常有助于理解您可能正在阅读的其他人的代码中的陷阱。
总的来说，了解模式的原因更重要的是如何。知道什么时候不应用模式与知道什么时候一样重要。
除了你已经引用的Abstract factory，Factory Method和Singleton模式之外，我认为下面的模式很有用。
桥模式：抽象和实现可以独立改变
装饰器模式：在运行时更改对象的行为
中介模式：启用不同对象之间的中央通信媒介
责任链：如果要向Web服务请求添加过滤器，这非常有用。
策略模式：如果要通过检查参数在运行时从一系列算法更改算法
Facade Pattern：如果您的系统中有许多服务，并且不希望将所有服务公开给客户端，请使用一个Facade类，它将与其他服务进行交互。
sourcemaking提供了每种设计模式的优秀细节：Intent，Strucutre，Checklist和Rules of thumb。
一个SE问题肯定会帮助你：
Design Patterns web based applications
Singleton - Singletons显然可以而且应该用于一切
每个人都应该了解Singleton，但也不应该使用它！对于我来说，这是我工作项目的痛苦来源。
单身人士使代码难以理解和遵循，并使编写单元测试变得更加困难。我喜欢博客文章Singletons are Pathological Liars。
大多数设计模式都非常明显 - 如果你已经编程了几年，你就已经知道并使用它们了。
我发现设计模式的最大优点是共享一组通用名称。如果有人说“Callback”可能意味着很多事情，但如果有人说“Listener Pattern”意味着更具体的一组调用并暗示了对象之间更高层次的关系。
所以从本质上讲，阅读一本好的设计模式书，了解每个模式的名称，花一些时间了解你不知道的任何东西，并且你很高兴去。
我不会完全忽略它们中的任何一个 - 它们都很好看。您应该能够识别可能从特定模式中受益的情况，并知道在哪里查找有关它的更多信息。
模型 - 视图 - 控制器只需要在列表中，Spring有一个MVC框架：
http://en.wikipedia.org/wiki/Model–view–controller
我建议你阅读Head First Design Patterns书。这是一本关于所有公共和有用模式的书。
我建议你阅读并阅读Design Patterns一书，因为它为你提供了词汇。
但不要忘记基本面:)
在我的眼中采访泪水http://java.sys-con.com/node/1040135采访Java开发人员
休眠？那么工作单位是必须的http://martinfowler.com/eaaCatalog/unitOfWork.html
Composite，它出现在JUnit框架中。 （测试的TestCase-的TestSuite）
适配器，构建器，命令，模板方法和策略模式很容易并且通常可以在实践中使用。
State模式还帮助我清理了继承源代码中的混乱。
这将是对Greg Hewgill提到的“Singletons Are Pathological Liars”的评论，但我还不能发表评论。
那篇文章提出了一个令人信服的案例，但他的愤怒是错误的。正如他博客上的几位评论者所说，他的问题实际上是全球性的。他的代码修复仍然可以使用单例，并且仍然可以获得清晰度和可测试性的确切增加。
重新阅读文章。他并不担心OfflineQueue需要初始化的数据库实例，也不需要CreditCardProcessor需要初始化的OfflineQueue。他担心这些依赖关系不可见，这会导致可维护性和可测试性问题。
他的问题在于秘密的全球状态（这是否让我听起来像一个阴谋理论家？）。
然而，他（imo）误解了这个秘密的全球国家是单身人士的错。
这并不意味着我赞成单身人士，他们没有必要 - 当然，他们有缺点（包括明显的线程争用瓶颈可能性）。但我更愿意清楚我正在避免的做法。
顺便说一句，我会进一步进行重构 - 基于类名，我在代码审查中断言，CreditCardProcessor应该处理收费，所以不是他的：
card.charge(cardProcessor, 100);
我有这个，相反：
cardProcessor.chargeCard (card, 100);
（是的，我用他认为更具可读性的名字替换了他的变量名称c和ccp）
以上是关于每个开发人员必须知道的设计模式？的主要内容，如果未能解决你的问题，请参考以下文章