如何使用模式进行设计
我是一名大学生，正在学习软件模式（特别是 GoF 书中提到的模式）。我从来都不擅长软件设计，但我正在学习每种模式如何工作并解决不同的问题以生产更灵活的软件。我有一个问题一直困扰着我。
查看问题（需要编写的软件）并确定如何组织它和应用模式的最佳方法是什么？我最近有一个 Java 小组项目，结果非常糟糕，因为我们的设计不太灵活。老实说，我在试图将问题分解成可管理的部分来解决时遇到了很大的麻烦。我知道我可以编写代码，但我不知道如何组织它。
我目前经历过的模式有：Composite、Builder、Adapter、Proxy、Observer、State、Strategy、Template Method 和 Iterator。正如我所提到的，我知道他们应该解决什么问题，但我觉得我正在努力将模式强制到位。任何帮助或页面链接将不胜感激。谢谢大家！
I am a college student and I'm learning about software patterns (specifically the ones mentioned in the GoF book). I have never been that good at software design, but I'm learning how each pattern works and solves different problems to produce more flexible software. I have a question that has been bugging me.
What's the best way to look at a problem (a piece of software that needs to be written) and determine how to organize it and apply patterns? I recently had a group Java project that went really sour because our design just wasn't very flexible. I honestly just had a great deal of trouble trying to break down the problem into manageable pieces to sort out. I know I can write code, but I don't know how to organize it.
The patterns I have gone through currently are Composite, Builder, Adapter, Proxy, Observer, State, Strategy, Template Method, and Iterator. Like I have mentioned, I know what they are supposed to solve, but I feel like I am trying to force patterns into place. Any help or links to pages would be greatly appreciated. Thank you all!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
除非你具有非凡的直觉（就像那个从来不需要尝试获得 4.0 的家伙，或者你在电影中描述的关于 facebook 人的地方，每个人都是天才，比尔·盖茨来客座演讲），否则有一定的在除了面向对象编程主题之外其他任何地方都不存在的心理结构成为你自然推理过程的一部分之前，大量的痛苦是不可避免的。
一旦发生这种情况，如果你不放弃的话，这样的模式就会开始变得有意义并有所帮助，但可能不会在你已经与它们解决的问题作斗争之前。
我不知道我是否同意现在向本科生教授计算机科学的方式。 1994 年，我在罗格斯大学作为新生学习了 C 数据结构和计算机体系结构。我学到的模式是“链表”和“抽象树”之类的东西。这是理解更高层次的东西的基础。
Unless you are uncommonly intuitive (like the dude who never has to try to get a 4.0, or your at a place as depicted in the movie about the facebook guy where everyone is a genius and Bill Gates comes to guest speak) then there's a certain amount of pain that is unavoidable before the mental constructs that really don't exist anywhere else but in the subject of object oriented programming become part of you natural reasoning process.
Once that happens, and it will if you don't give up, then patterns like that will start making sense and helping, but probably not before you've already stuggled with the problems that they solve quite a bit.
I don't know that I agree with the way CS is being taught to undergrads these days. In 1994 at Rutgers I took C data structures and Computer Architecture as a freshman. The patterns I learned were things like "linked list" and "abstract tree". This was the foundation for understanding higher level stuff.
您提到了基本应用程序问题解决的问题。在深入研究模式之前，你需要先解决这个问题。模式不是学习设计的方法 - 它们会增加复杂性，并且通常会使设计变得有些模糊，除非您将自己的技能提升到一定程度。
致力于将问题分解为基本部分，并创建与领域知识和基本问题元素相对应的合理对象集。另外，创建 UML 图。您不必担心正式 UML 实现的所有细节，只需使用基本块和关联来表示您的模型。另外，不要尝试绘制整个应用程序的一张图表，只需绘制重要部分的图表即可。图表将提高您可视化问题、问题与设计的关系以及从问题到模型到代码以及从代码到模型再到问题的转换过程的能力。
UML 也是一个有用的检查和平衡过程。图表应该具有逻辑意义。如果您无法创建逻辑图表，则可能会遇到问题，图表还可以帮助您找到不合适的部分。 UML 通常还“引导”代码的清晰度和复杂性。我的意思是，当代码变得太难以使用时，图表通常仍然相当清晰。因此，相反，如果您的图表已经变得过于复杂或不清楚，那就完全暴露了结果代码可能难以管理，您需要重新考虑问题。
一旦您感觉自己越来越擅长将问题分解为小部分并设计和命名适合您的分析的类，您就可以开始慢慢地合并模式。首先从创建模式开始。很多时候需要单例，并且任何复杂性的大多数应用程序都可以从工厂的适当使用中受益。
之后，您应该能够越来越多地了解如何使用结构模式。 Facade 很简单并且被广泛使用——将很多东西封装到一个简单的界面中。装饰器、复合器、代理、适配器都是为了使对象“类型标识”表现出不同的行为，了解它们之间的相似之处以及为什么每个对象不同以及在哪里应用它们。最后，行为模式通常用于状态管理场景或某种对象到对象通信方面。大多数情况下，它们是由某些类型的问题建议的，例如 Memento 是由需要执行回滚或持久状态建议的。
首先练习基本的设计技能，不要过度使用图案，并逐渐融入它们，首先从创作图案开始。
You mention issues with basic application problem solving. You need to work on that first before getting heavy into patterns. Patterns are not the way to learn design - they can add complexity and often somewhat obscure a design unless you have advanced your skills to a certain point.
Work on decomposition of a problem into fundamental pieces and creating a rational set of objects that correspond to domain knowledge and fundamental problem elements. Also, create UML diagrams. You don't have to worry with all the details of a formal UML implementation, just use basic blocks and associations to represent your model. Also don't try to do one diagram of the entire app, just diagram important pieces. Diagramming will improve your ability to visualize the problem, how it relates to the design, and the process of translate from a problem to a model to code and code back to model back to problem.
UML is also a useful check and balance process. A diagram should make logical sense. If you cannot create a logical diagram you may have a problem, and diagrams also help find pieces that fit poorly. UML also typically "leads" code in terms of clarity and complexity. By that I mean that often a diagram will still be reasonably clear well past the point when the code is becoming too difficult to work with. So conversely, if your diagram is already becoming too complex or unclear that is a dead give away the resulting code is potentially unmanageable and you need to rethink the problem.
Once you feel like you are getting better at decomposing a problem into small parts and designing and naming classes that fit your analysis you can begin to slowly incorporate patterns. Start with creation patterns first. Many times a Singleton is needed and most applications of any complexity can benefit from appropriate use of Factories.
After that you should be able to find more and more how structural patterns are used. Facade is easy and one widely used - encapsulate a lot of things into a simple interface. Decorator, Composite, Proxy, Adapter are all about making object "type identity" appear to behave differently, learn the similarities between them and why each one is different and where to apply them. Finally, behavioral patterns are typically used in either state management scenarios or some sort of object - to - object communication aspect. Mostly they are suggested by certain types of problems, example Memento is suggested by need to perform roll backs or persist state.
Work on your basic design skills first, don't overdo patterns and incorporate them gradually, starting with creational patterns first.
试图“强制”设计模式并不是正确的方法。
如果您有现有代码，最好从重构的角度来解决这个问题。寻找“难闻的气味”。实际问题是什么？代码可能存在太多基本问题（函数太长、重复过多），您需要先解决这些问题，然后才能从更高的层次查看它。
一旦您清理了基本级别的代码，可能会出现一些更高级别的问题，这就是模式可能会有所帮助的地方。但是，您不会说“我如何使用这个模式”，而更有可能的是，您会看到一个问题并说“啊哈。这对于装饰器模式来说是完美的”。这可能不会发生，但一旦你学习了这本书，你就会更愿意发现其中的模式。
这里的一个好术语是serendipity。
Trying to "force" a design pattern is not the right approach.
If you have existing code, it's best to approach this from a refactoring perspective. Look for the "bad smells". What are the actual problems? It might be the case that there are so many basic problems with the code (functions too long, excessive duplication) that you need to address these before you can look at it from a higher level.
Once you've cleaned up the code on a basic level, some higher-level problems might emerge, and here is where the pattens might help. But, rather than saying "how can I use THIS pattern", it will more likely be that you'll look at a problem and say "AHA. This is perfect for the decorator pattern". This might not happen, but you'll be more open to finding the pattern once you've studied the book.
A good term here is serendipity.
模式不仅是一种编程工具，也是一种沟通工具。当有数万或数十万行代码时，您需要能够找到解决办法、可视化各个部分，并能够与其他开发人员有效地讨论代码。模式就是这样做的。
GOF 模式是了解它们的一个很好的起点，但您需要将它们应用到某种情况中，而不是创建一个情况来使用它们。
当您能够更好地将模式应用于正确的情况时，请开始扩展您对企业模式 并开始了解如何将模式连接在一起。后者将开始出现应用程序架构的模式。
相信我，可能需要很长时间和经验才能擅长它们并知道何时应用它们。只要保持耐心，同时保持好奇心即可。
Patterns are not only a programming tool but also a communication one as well. When there are tens or hundreds of thousands lines of code you need to be able to find your way round, visualise parts and be able to talk to fellow developers about the code effectively. Patterns do this.
The GOF patterns are a good starting point to learn about them but you need to apply them to a situation, not create a situation to use them.
When you get better at applying patterns to the right situation start expanding your knowledge on enterprise patterns and start to see how patterns can be connected together. The latter will start to emerge the pattern of application architecture.
Trust me it can take a long time and experience to get good at them and knowing when to apply them. Just be patient and be curious at the same time.
Bill Venners：那么，模式的价值在于，在现实世界中，当我感受到某种特定的痛苦时，我能够找到已知的解决方案吗？
Erich Gamma：这绝对是我建议人们使用模式的方式。不要立即开始将模式放入设计中，而是在进行过程中使用它们并更多地了解问题。因此，我真的很喜欢在事后使用模式，重构模式。在模式开始变得更流行之后，我在新闻组中看到了一条评论，有人声称在一个特定的程序中，他们试图使用所有23 个 GoF 模式。他们说他们失败了，因为他们只能使用 20 个。他们希望客户再次打电话给他们回来，这样也许他们可以挤进另外 3 个。
尝试使用所有模式是一件坏事，因为你最终将得到合成设计——具有无人需要的灵活性的推测性设计。现在的软件太复杂了。我们无法推测它还应该做什么。我们需要真正关注它的需求。这就是为什么我喜欢重构模式。人们应该知道，当他们遇到某种特定类型的问题或代码异味（正如人们现在所说的那样）时，他们可以转到模式工具箱来寻找解决方案。
Bill Venners：这很有趣，因为我的第二个问题是，我观察到人们常常觉得图案最多的设计是最好的。在我们的设计研讨会上，我让参与者做一个设计项目，他们在研讨会结束时向其他人展示。演讲者几乎总是想展示他们在设计中使用了多少模式，尽管我试图告诉他们目标是一个干净、易于理解的 API，而不是赢得“我使用最多的模式”竞赛。我刚刚听到你说了同样的话，这不是思考模式的正确方式。如果不是，那么在设计中使用模式的正当理由是什么？
Erich Gamma：很多模式都与可扩展性和可重用性有关。当您确实需要可扩展性时，模式会为您提供一种实现它的方法，这很酷。但是当您不需要它时，您应该保持设计简单，并且不要添加不必要的间接级别。我们 Eclipse 的座右铭之一是我们希望在重要的地方具有可扩展性。实际上，如果您对我们如何在 Eclipse 中使用模式感兴趣，我曾尝试在《Contributing to Eclipse》一书中的一章中描述它们的用途 [请参阅 参考资料]。在本章中，我使用设计模式来解释 Eclipse 体系结构的各个部分。
http://www.artima.com/lejava/articles/gammadp.html
谷歌第二部分 - 第四部分也是如此！ :) 这些都是很棒的读物
Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution?
Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.
Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.
Bill Venners: That's funny, because my second question was that I have observed that often people feel the design with the most patterns is the best. In our design seminar, I have the participants do a design project, which they present to the others at the end of the seminar. Almost invariably, the presenters want to show off how many patterns they used in their design, even though I try to tell them the goal is a clean, easy to understand API, not to win an I-used-the-most-patterns contest. I just heard you say the same thing, that that's not the right way to think about patterns. If not, what is the proper justification for using patterns in designs?
Erich Gamma: A lot of the patterns are about extensibility and reusability. When you really need extensibility, then patterns provide you with a way to achieve it and this is cool. But when you don't need it, you should keep your design simple and not add unnecessary levels of indirection. One of our Eclipse mottos is that we want extensibility where it matters. Actually, if you are interested in how we use patterns in Eclipse I did an attempt to capture their uses in a chapter in the Contributing to Eclipse book [see Resources]. In this chapter I used design patterns to explain pieces of the Eclipse architecture.
http://www.artima.com/lejava/articles/gammadp.html
google parts II - IV too! :) those are great readings