c# - 设计模式的挫折

Question

我是一名拥有 4 年 .Net 编码经验的开发人员，并且在我的职业生涯中从不关心设计模式。最近我被要求面试一位 IT 大佬，已经进行了 5 轮(问题解决、结对编程、逻辑推理、2 轮技术面试)面试，但没有提供工作。

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

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

• Open/closed principle (OCP)
• Dependency inversion (直接)
• Interface seggregation
• Liskov substituion principle (语言服务提供商)

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

但我的问题是为正确的问题找到正确的模式。我知道仅仅阅读所有出版的关于设计模式和实践的书籍是无法获得这些知识的。这些知识来自构建不同系统的经验。

模式-问题匹配是否有可用的用例。您对学习设计原则有何建议？

干杯

Answer 1

虽然我认为熟悉设计模式并没有坏处，但我想确保您的问题中没有将两件事混为一谈。你说你得到的反馈是你应用设计原则的能力较弱，，你从反馈中得出结论，你需要学习设计模式。但那是不同的。

“设计模式”是您在许多不同领域看到的重复出现的模式。例如，在建筑中，您会在许多不同类型的建筑物中看到“内部庭院”的模式。在编程中，您会在许多不同类型的程序中看到诸如“只能有一个实例的类”或“将这个粘合到那个的小代码块”之类的模式。

但是原则不是模式。模式是一种特殊的重复设计。原则是一种想法，它是什么使设计对正在设计的工件的用户好的基础。

例如，JScript语言的一个设计原则是“宽容小错误”。如果你为 11 月 31 日创建一个日期对象，它会默默地将其更正为 12 月 1 日，而不是给出错误。没有“小错误宽恕模式”。让设计容错是一种设计原则——当我们可以选择如何设计一个特定的特性时，我们会考虑它与所有原则的一致性——其中一些原则是矛盾的——并使用它们来指导功能的设计。

这不是 C# 的设计原则；其实恰恰相反是C#的一个设计原则。设计原则本身并无好坏之分。它们是使设计对其目标用户群有益的指南。

在不理解模式的情况下编写代码意味着您的工具箱中没有可以更轻松地完成常见任务的工具。在不理解设计原则的情况下编写代码意味着编写不一致、难以理解且违背用户需求的代码。两者都很重要，但又截然不同。