要避免的设计模式 [英] Design patterns to avoid

问题描述

很多人似乎都同意，单例模式有很多缺点，有些人甚至建议完全避免这种模式.这里有很好的讨论.请将有关单例模式的任何评论指向该问题.

A lot of people seem to agree, that the Singleton pattern has a number of drawbacks and some even suggest avoiding the pattern entirely. There's an excellent discussion here. Please direct any comments about the Singleton pattern to that question.

我的问题:是否还有其他设计模式应该避免或谨慎使用?

My question: Are there other design patterns, that should be avoided or used with great care?

推荐答案

模式很复杂

应谨慎使用所有设计模式.在我看来你应该在有正当理由的情况下重构模式而不是立即实施模式.使用模式的普遍问题是它们增加了复杂性.过度使用模式会使给定的应用程序或系统难以进一步开发和维护.

Patterns are complex

All design patterns should be used with care. In my opinion you should refactor towards patterns when there is a valid reason to do so instead of implementing a pattern right away. The general problem with using patterns is that they add complexity. Overuse of patterns makes a given application or system cumbersome to further develop and maintain.

大多数时候，有一个简单的解决方案，您不需要应用任何特定的模式.一个好的经验法则是在代码片段需要替换或需要经常更改时使用模式，并准备好在使用模式时承担复杂代码的警告.

Most of the time, there is a simple solution, and you won't need to apply any specific pattern. A good rule of thumb is to use a pattern whenever pieces of code tend to be replaced or need to be changed often and be prepared to take on the caveat of complex code when using a pattern.

请记住，您的目标应该是简单，如果您看到，请使用一种模式支持更改代码的实际需求.

Remember that your goal should be simplicity and employ a pattern if you see a practical need to support change in your code.

如果模式显然会导致过度设计和复杂的解决方案，那么使用模式似乎没有实际意义.然而，对于程序员来说，阅读为大多数模式奠定基础的设计技术和原则会更有趣.事实上，我最喜欢的一本关于设计模式"的书籍强调了这一点，它重申了哪些原则适用于有问题的模式.它们足够简单，在相关性方面比模式有用.一些原则足够通用，涵盖的不仅仅是面向对象编程 (OOP)，例如 Liskov 替换原则，只要您可以构建代码模块.

It may seem like a moot to use patterns if they can evidently lead to over-engineered and complex solutions. However it is instead much more interesting for a programmer to read up on design techniques and principles that lay the foundation for most of the patterns. In fact one of my favorite books on 'design patterns' stresses this by reiterating on what principles are applicable on the pattern in question. They are simple enough to be useful than patterns in terms of relevance. Some of the principles are general enough to encompass more than object oriented programming (OOP), such as Liskov Substitution Principle, as long as you can build modules of your code.

有很多设计原则，但在 GoF 书籍第一章中描述的那些是开始时非常有用.

There are a multitude of design principles but those described in the first chapter of GoF book are quite useful to start with.

• 为接口"编程，而不是实现".(Gang of Four 1995:18)
• 更喜欢对象组合"而不是类继承".(Gang of Four 1995:20)

• Program to an 'interface', not an 'implementation'. (Gang of Four 1995:18)
• Favor 'object composition' over 'class inheritance'. (Gang of Four 1995:20)

让那些人沉迷于你一段时间.应该注意的是，在编写 GoF 时，interface 意味着任何抽象的东西(这也意味着超类)，不要与作为 Java 或 C# 类型的接口混淆.第二个原则来自观察到的继承的过度使用，遗憾的是今天仍然很普遍.

Let those sink in on you for a while. It should be noted that when GoF was written an interface means anything that is an abstraction (which also means super classes), not to be confused with the interface as a type in Java or C#. The second principle comes from the observed overuse of inheritance which is sadly still common today.

从那里你可以阅读SOLID 原则，由 Robert Cecil Martin (又名鲍勃叔叔).Scott Hanselman 在关于这些原则的播客中采访了鲍勃叔叔:

From there you can read up on SOLID principles which was made known by Robert Cecil Martin (aka. Uncle Bob). Scott Hanselman interviewed Uncle Bob in a podcast about these principles:

• S单一责任原则
• O笔封闭原则
• Liskov 替换原则
• I接口隔离原则
• D周期倒置原则

• Single Responsibility Principle
• Open Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

这些原则是阅读并与同行讨论的良好开端.您可能会发现这些原则相互交织，并与其他流程(例如关注点分离和依赖注入.在练习了一段时间 TDD 之后，您可能还会发现这些原则在您的实践中自然而然地出现需要在某种程度上遵循它们以创建隔离和可重复单元测试.

These principles are a good start to read up on and discuss with your peers. You may find that the principles interweave with each other and with other processes such as separation of concerns and dependency injection. After doing TDD for a while you also may find that these principles come naturally in practice as you need to follow them to some degree in order to create isolated and repeatable unit tests.

这篇关于要避免的设计模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！