我可以成功扩展所有未使用记录的设计模式的旧应用程序。我不知道是什么模式。在很大程度上,我只觉得需要使用简单的OOP概念。
设计模式的概念很复杂,很难理解。在实施时,如何确定实施是否正确以及应用程序是否具有真正的松散耦合?
我可以成功扩展所有未使用记录的设计模式的旧应用程序。我不知道是什么模式。在很大程度上,我只觉得需要使用简单的OOP概念。
设计模式的概念很复杂,很难理解。在实施时,如何确定实施是否正确以及应用程序是否具有真正的松散耦合?
Answers:
您提到了设计模式和耦合。这些是单独的概念,因此我将分别处理它们。唯一真正的联系是设计模式倾向于促进松散耦合(因为这是良好设计的主要方面)。
设计模式
设计模式的概念实际上非常简单:它们只是一组如何处理各种常见问题的模板。它们受欢迎的主要原因有两个:
您如何知道自己已正确实施?这是一个棘手的问题。对于大多数模式而言,它很简单-您已经摸索了,或者没有。有些模式的定义不如其他模式明确-例如model-view-controller。这样的模式最好用作一般准则。实现方式的细节并不比理解该模式存在的原因以及它要实现的目的重要。
设计模式不是“唯一的方式”。通常,您要么需要根据自己的特定目的对它们进行调整,要么有时就不会出现任何符合要求的模式。强迫不适合的设计模式是一个坏主意;当您真正想要的是螺丝起子时,就像使用一把非常好的锤子。
耦合
这是计算机科学中一个非常重要的想法。由于大多数软件项目的需求会随时间变化(有时会有很大变化),因此设计应对变化的能力非常重要。耦合基本上是“将这个组件换成另一个组件有多难?”的量度。“组件”可以是方法,类,包,库等。
Wikipedia文章中列出了各种类型的耦合。
使用设计模式是一种预防措施。稍后扩展应用程序时,可以使用设计模式来简化工作。当然,要以后减轻工作负担,您现在必须做更多的工作。因此,真正的问题是,您将来可以期待多少变化,这是什么变化。如果您不需要可伸缩性和灵活性,则可以取消设计模式。
设计模式本身就是面向对象设计原则的实现。只要遵循这些原则,您的应用程序就会变得灵活和可扩展。即使您没有真正的实际设计模式。正如Joachim Sauer上面评论的那样,它们是常见问题的通用解决方案。