如何应用设计模式?

1. 这取决于你怎么写代码。如果这是一个我在编码之前就决定的大项目,那么在我开始编写代码之后,如果我注意到应该使用设计模式的地方,我就会重构代码。

2. 是的,如前所述。

3. Factory Pattern Singleton (像所有人一样,我在很多地方使用它,因为它易于实现,在实践中,我倾向于在重构代码时删除它)。 然后: Object Pool

5. 我认为唯一的代码提示可能是你对一个类的引用数。你也可以使用 PMD , jDepend 和 Architecture Rules 找出类包含太多依赖项的位置。我不确定这是不是一个编码提示。在设计阶段,不仅是在那里,当你决定使用一个设计模式时,只要想想它的好处。我找到了那个软件 Design Principles design patterns .

怎样 什么时候 (不)使用设计模式是:

• Pattern Hatching
• Refactoring to Patterns (作者乔希·克里耶夫斯基)

一个设计模式描述了一个通用的可重用的解决方案,在给定的上下文中解决一个反复出现的问题。当您确定一个模式可以解决的设计问题时,您应用了一个模式。这可能发生在初始设计、编码、维护等过程中。IMO表示,没有绝对配方。

• Writing Software Patterns
• Patterns in a Nutshell

1和2

我认为这是一个错误的方法,她只是盲目地决定一个最喜欢的模式,或先编写代码,然后重构到一个已知的模式。当您看到一个问题时,您将不得不认识到与使用已知模式可能解决的其他问题的相似性。

3:什么样的模式占优势很大程度上取决于领域。状态模式、代理和外观在执行与其他系统进行大量通信的应用程序时非常常见。GUI应用有不同的需求等。

在我的行业(银行业):我看到了以下许多GOF模式:工厂方法、单例、适配器和Facade。行为模式或多或少被10年前流行的javaee14层反模式所扼杀。

5:我认为一个特定模式的主要指标更多的是与问题相关,它与特定模式解决的其他问题的相似性。是的,如果代码有异味,这表明它可能需要重写,应该再次分析问题。虽然有些问题很复杂,而且不能简化,但大多数问题都可以简化,而且模式可能有助于组织问题。

他说:我的同事们似乎喜欢我,所以我可能什么都没做过头。我自己对代码中过度使用工厂和工厂方法感到相当恼火,这些代码不太可能同时在不同的实现中更改或存在——如果最终会更改,那么无论如何都需要重写。这只是浪费时间,而且会使代码复杂化并延迟bug搜索。

根据我的经验,它取决于方法论和预先设计的水平,以及何时应用模式。通常在敏捷过程中,我会看到随着代码意图的发展,模式会很快出现,然后相应地重构。

尽管声明明显的单元测试会降低很多风险,但越早做越好。我从未对代码进行过重大的重构以支持实现新模式,因为所涉及的工作很少显示出显著的好处。除非这个项目即将进入一个新的发展阶段。

在国际海事组织,没有任何规则或常见情况。设计模式是在适当的时候使用的,有时是在设计的时候,有时是在编码的时候,有时是在重构的时候。

大多数时候我不会一对一地“应用设计模式”。他们需要适应。设计模式就像一个经验目录。您只需知道一些常见或典型的模式,并将它们更改为您需要的解决方案。(注意:它们是模式,而不是解决方案。)

别忘了那本书 Design Patters

你没有学习实现它们的模式,这是错误的方法,你学习然后你就可以和其他程序员谈论代码。它更像是你正常语言的延伸,而不是其他任何东西。需要时在代码中使用它,但不要在:-)之前使用它

我将采取不同的方法在这里,不提书或解决所有这些问题分开。

SOLID . 我认为,你可以将许多场景和模式与这些原则联系起来,遵循不断发展的代码基础思维模式通常会揭示出你对所有其他模式的需求。

至于提示,long methods=>refactor。即使它只是移动到同一类中的方法,因为通常中间步骤会显示下一步。