设计模式挫折

Question

我是一名拥有4年.Net编码经验的开发人员，我从来不关心我的carreer中的设计模式。最近，我被要求与IT界的一位大人物进行面试，完成了5轮面试(问题解决、配对推进、逻辑推理、2轮技术面试)，但没有提供一份工作。

我从他们那里得到的反馈不是很好的设计原则，尽管他们对我的技术和逻辑推理技能很满意。这一次让我认为了解设计模式是解决问题的唯一途径？

虽然我在编码中从未使用过很多设计模式，但我总是尝试实现OOPS的基本原则。

• 开放/封闭原则 (OCP)
• 依赖反演 (DI)
• 界面重构
• Liskov取代原理 (LSP)

我可以使用这些原则来设计一个松散耦合、开放的增强和易于维护的系统。最后，这些都是所有设计模式的核心结构。

但我的问题是为正确的问题找到一个正确的模式。我知道，这种知识不会仅仅通过阅读所有在设计模式和实践中出版的书籍来获得。这种知识伴随着建立不同系统的经验。

是否有任何可用的用例用于模式-问题匹配.你对学习设计原则的建议呢？

干杯

Answer 1

虽然我认为对设计模式更加熟悉不会有什么坏处，但我想确保在您的问题中没有将两件事情混为一谈。你说你得到的反馈是你应用设计原则的能力很弱，你从反馈中得出结论，你需要研究设计模式。但那不一样。

“设计模式”是一种反复出现的模式，您可以在许多不同的领域看到这种模式。例如，在建筑中，你可以看到许多不同类型建筑中的“室内庭院”模式。在编程中，您可以在许多不同类型的程序中看到“只能有一个实例的类”或“将其粘合在一起的少量代码”之类的模式。

但原则不是模式。模式是一种特殊的反复出现的设计；原则是使设计对正在设计的工件的用户有益的思想的基础。

例如，JScript语言的设计原则是“宽恕小错误”。如果您为11月31日设置了一个日期对象，它将静默地将其更正到12月1日，而不是给出一个错误。没有“小错误宽恕模式”。设计容错是一项设计原则--当我们选择如何设计一个特定的特性时，我们会考虑它与所有原则的一致性--其中一些原则是相互矛盾的--并利用这些原则来指导功能的设计。

这不是C#的设计原则；实际上，与之相反的是C#的设计原则。设计原则本身并不是好的或坏的；它们是如何使设计对其目标用户集有利的准则。

编写代码而不理解模式意味着工具箱中没有使执行常见任务更容易的工具。在不理解设计原则的情况下编写代码意味着编写不一致、难以理解和违背用户需求的代码。两者都很重要，但它们是非常不同的。

Answer 2

设计模式之所以被称为 patterns ，是因为它们在许多独立的程序中一次又一次地出现，而不是因为它们被用来将程序组装在一起，就像用正方形拼接成被子一样。它们可以帮助解决软件问题，但它们本身并不是一个解决方案。

Answer 3

即使您使用C#，我还是建议您阅读一些关于模式的书籍。首先是GoF的书-- 设计模式。然后试着读一些关于企业设计模式的书。当你阅读的时候，你会认出(或看到)这个模式。这通常是一个“啊哈”的时刻。

您还可以从自己的代码中识别出相同的代码。了解模式将有助于您进行良好的设计。它有助于了解模式，因为当与其相关的问题出现时，您将立即回忆起该模式。

您指定的编程原则是好的，并遵循它们。然而，它们更多的是在班级级别上。向更高层次的系统设计迈进，模式将更有帮助。

最重要的是-模式为您提供了与整个团队讨论设计思想的词汇表.