java 每个开发人员都必须知道的设计模式？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1247803/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Design patterns that every developer must know?
提问by Shaw
What are the design patterns that every developer must know?
每个开发人员必须知道的设计模式是什么？
I'm interested in the context of Java web developers working with Spring & Hibernate. I have often heard that good knowledge in design patterns is essential for working with those frameworks. Can anyone list the specifics?
我对使用 Spring 和 Hibernate 的 Java Web 开发人员的上下文感兴趣。我经常听说设计模式方面的良好知识对于使用这些框架是必不可少的。谁能列出具体的？
For example, I know that understanding abstract factory & factory pattern, singleton pattern etc is absolutely essential. I'm looking for a comprehensive list.
例如，我知道理解抽象工厂和工厂模式、单例模式等是绝对必要的。我正在寻找一份完整的清单。
回答by Elijah
Inversion of Control
控制反转
If you are ever going to design decoupled systems, you will need to know how to properly link dependencies between classes.
如果您打算设计解耦系统，您将需要知道如何正确链接类之间的依赖关系。
Command Pattern and Variants
命令模式和变体
In Java in particular, it is essential to learn how to pass a piece of functionality to another method as an object because of the lack of closures and function pointers in the language.
特别是在 Java 中，由于语言中缺少闭包和函数指针，因此必须学习如何将一个功能作为对象传递给另一个方法。
Factory Pattern
工厂模式
Factories are ubiquitous in Java frameworks and it is essential to learn why and when to use the factory pattern.
工厂在 Java 框架中无处不在，了解为什么以及何时使用工厂模式至关重要。
Singleton (pattern and anti-pattern)
单例（模式和反模式）
Learning how to use the singleton pattern responsibly is very helpful for understanding the pitfalls in other people's code you may be reading.
学习如何负责任地使用单例模式对于理解您可能正在阅读的其他人代码中的陷阱非常有帮助。
Overall, learning the whywith regards to patterns is much more important the the how. Knowing when not to apply a pattern is just as important as knowing when to.
总体而言，学习为什么至于图案是更重要的是如何。知道何时不应用模式与知道何时应用一样重要。
回答by Greg Hewgill
Everybody should know aboutSingleton, but also when notto use it! It's currently the source of much pain for me on a project at work.
每个人都应该知道的关于辛格尔顿，也当不使用它！目前，它是我在工作项目中非常痛苦的根源。
Singletons make the code hard to understand and follow, and make writing unit tests much more difficult. I like the blog post Singletons are Pathological Liars.
单例使代码难以理解和遵循，并使编写单元测试变得更加困难。我喜欢博客文章单身人士是病态的骗子。
回答by Bill K
Most design patterns are pretty obvious--you already know and use them if you've been programming a few years.
大多数设计模式都非常明显——如果你已经编程了几年，你就会知道并使用它们。
The biggest advantage I've found to design patterns is sharing a common set of names. If someone says "Callback" that can mean quite a few things, but if someone says "Listener Pattern" that means a more specific set of calls and implies a higher level relationship between objects.
我发现设计模式的最大优势是共享一组通用名称。如果有人说“回调”可能意味着很多事情，但如果有人说“侦听器模式”则意味着更具体的调用集并暗示对象之间的更高级别的关系。
So in essence, read through a good design patterns book, get an idea of the name of each pattern, spend some time understanding any you don't know, and you're good to go.
因此，本质上，通读一本优秀的设计模式书，了解每个模式的名称，花一些时间了解您不知道的任何内容，然后就可以开始了。
I wouldn't completely ignore any of them--they are all good to have seen. You should be able to recognize a situation that might benefit from a specific pattern and know where to look to find out more about it.
我不会完全忽略其中任何一个——他们都很高兴看到。您应该能够识别可能从特定模式中受益的情况，并知道去哪里寻找更多相关信息。
回答by karim79
Model–view–controller just has to be on the list, Spring has an MVC framework:
模型-视图-控制器只需要在列表中，Spring 有一个 MVC 框架：
回答by karim79
I recommend you to read Head First Design Patternsbook. This is a well written book about all commons and useful patterns.
我建议你阅读Head First Design Patterns一书。这是一本关于所有共同点和有用模式的好书。
回答by Thorbj?rn Ravn Andersen
I would recommend you get and read the Design Patterns book, since it gives you the vocabulary.
我建议您阅读并阅读 Design Patterns 一书，因为它为您提供了词汇。
回答by programmernovice
But don't forget the fundamentals :)
但不要忘记基本面:)
Interviewing Java Developers With Tears in My Eyes http://java.sys-con.com/node/1040135
含泪采访 Java 开发人员 http://java.sys-con.com/node/1040135
回答by Ravindra babu
Apart from Abstract factory, Factory Methodand Singletonpatterns, which you have quoted already, I think below patterns are useful.
除了您已经引用的Abstract factory,Factory Method和 Singleton模式之外，我认为以下模式很有用。
Bridge Pattern: Abstraction and implementation can change independently
桥接模式：抽象和实现可以独立变化
Decorator Pattern: Change the behaviour of object at run time
装饰模式：在运行时改变对象的行为
Mediator Pattern: Enable central communication medium between different objects
中介者模式：启用不同对象之间的中央通信媒介
Chain of Responsibility: If you are adding filters to web service request, this is very useful.
责任链：如果您要向 Web 服务请求添加过滤器，这非常有用。
Strategy Pattern: If you want to change the algorithm from a family of algorithms at run time by checking a parameter
策略模式：如果您想在运行时通过检查参数来更改算法系列中的算法
Facade Pattern: If you have many services in your system and don't want to expose all the services to client, have one Facade class, which will interact with other services.
Facade 模式：如果您的系统中有很多服务，并且不想将所有服务都暴露给客户端，那么可以使用一个 Facade 类，它会与其他服务进行交互。
sourcemakingprovides excellent details on each design-pattern : Intent, Strucutre, Checklist and Rules of thumb.
sourcemaking为每个设计模式提供了极好的细节：意图、结构、清单和经验法则。
One more SE question would be definitely help you :
再问一个 SE 问题肯定会对您有所帮助：
回答by Karl
Hibernate? Then the Unit Of Work is a must http://martinfowler.com/eaaCatalog/unitOfWork.html
休眠？那么工作单元是必须的http://martinfowler.com/eaaCatalog/unitOfWork.html
Composite, it's present in the JUnit framework. (Test-TestCase-TestSuite)
Composite，它存在于 JUnit 框架中。（测试-测试用例-测试套件）
The Adapter, Builder, Command, Template Method and Strategy patterns are easy and often usable in practice.
Adapter、Builder、Command、Template Method 和 Strategy 模式在实践中很容易并且经常使用。
The State pattern also helped me to clean up mess in inherited source codes.
状态模式还帮助我清理继承的源代码中的混乱。
回答by CPerkins
This would be a comment to Greg Hewgill's reference to "Singletons Are Pathological Liars", but I can't make comments yet.
这将是对 Greg Hewgill 对“单身人士是病态的骗子”的引用的评论，但我还不能发表评论。
That article makes a convincing case, but his ire is misdirected. As several commenters on his blog noted, his problem is really global state. His code fix could still be making use of singletons, and still gain the exact increase in clarity and testability.
那篇文章提出了一个令人信服的案例，但他的愤怒被误导了。正如他博客上的几位评论者指出的那样，他的问题实际上是全局状态。他的代码修复仍然可以使用单例，并且仍然在清晰度和可测试性方面获得了确切的提高。
Re-read the article. He's not bothered that OfflineQueue needs an initialized Database instance, nor that CreditCardProcessor needs an initialized OfflineQueue. He's bothered that those dependencies aren't visible, which causes issues with maintainability and testability.
重新阅读文章。他并不担心 OfflineQueue 需要一个初始化的 Database 实例，CreditCardProcessor 也不需要一个初始化的 OfflineQueue。他担心这些依赖项不可见，这会导致可维护性和可测试性问题。
His problem is with secret global state (does this make me sound like a conspiracy theorist?).
他的问题是秘密的全球状态（这是否让我听起来像一个阴谋论者？）。
However, he's (imo) misinterpreting that secret global state as being the fault of singletons.
然而，他（imo）将那个秘密的全局状态误解为单身人士的错。
That doesn't mean I'm in favor of singletons where they're not necessary - certainly, they have drawbacks (including the obvious thread contention bottleneck possibility). But I prefer to be clear about what practices I'm eschewing.
这并不意味着我支持没有必要的单例——当然，它们有缺点（包括明显的线程争用瓶颈可能性）。但我更愿意明确我要避免的做法。
Incidentally, I'd go further in my refactoring - based on the class names, I'd assert in a code review that CreditCardProcessor should, well, process the charges, so instead of his:
顺便说一句，我会在重构中更进一步 - 基于类名，我会在代码中断言 CreditCardProcessor 应该处理费用，而不是他的：
card.charge(cardProcessor, 100);
I'd have this, instead:
我有这个，而不是：
cardProcessor.chargeCard (card, 100);
(and yes, I replaced his variable names cand ccpwith names I considered more readable)
（是的，我取代他的变量名c和ccp用名字，我认为更易读）
