我是一名拥有4年.Net编码经验的开发人员，从不关心我的设计模式。最近我被要求接受IT部门的一位大佬的采访，已经完成了5轮（解决问题，配对编程，逻辑推理，2轮技术面试）的采访，并没有提供工作。
我从他们那里获得的反馈是不擅长设计原则，尽管他们对我的技术和技术感到满意。逻辑推理技巧。这个让我觉得知道设计模式是解决问题的唯一方法吗？
虽然我的编码中从未使用过很多设计模式，但我总是试图实现OOPS的基本原理
我可以使用这些原则来设计一个松散耦合和开放的系统，以增强和易于维护。事实上，这些是所有设计模式的核心结构。
但我的问题是为正确的问题找到合适的模式。我知道只有阅读设计模式和实践中出版的所有书籍才能获得这些知识。这些知识伴随着构建不同系统的经验。
是否有任何用例可用于模式问题匹配 ..您对学习设计原则的建议是什么？
干杯
答案 0 :(得分：15)
虽然我认为对设计模式更加熟悉并不会有什么坏处，但我想确保你的问题中没有两个东西的混合。你说你得到的反馈是你应用设计原则的能力很弱，你从反馈中得出结论，你需要研究设计模式。但那是不同的。
“设计模式”是您在许多不同域中看到的重复模式。例如，在建筑中，您可以在许多不同类型的建筑物中看到“内部庭院”的图案。在编程中，你会看到许多不同类型的程序中的模式，如“只能有一个实例的类”或“将这一点粘合在一起的一小块代码”。
但原则不是模式。模式是一种特殊的反复出现的设计;一个原则是一个想法，它是为设计的工件的用户设计好的基础。
例如，JScript语言的设计原则是“容忍小错误”。如果您在11月31日创建了一个日期对象，它将默默地将其更正为12月1日，而不是给出错误。没有“小错误的宽恕模式”。设计容错是一个设计原则 - 当我们可以选择如何设计一个特定的特征时，我们会考虑它与所有原则的一致性 - 其中一些是相互矛盾的 - 并使用它们来指导功能的设计。
这不是 C＃的设计原则;实际上，相反的是C＃的设计原则。设计原则本身并不好或坏;它们是指导设计为其目标用户组的的指南。
编写代码而不理解模式意味着没有工具箱中的工具可以更轻松地完成常见任务。编写代码而不理解设计原则意味着编写不一致，难以理解且与用户需求相反的代码。两者都很重要，但它们非常不同。
答案 1 :(得分：8)
设计模式被称为模式，因为它们在许多独立程序中一次又一次地出现，而不是因为它们习惯于将方块拼接在一起以便将方块拼接在一起制作一个被子。它们可以帮助解决软件问题，但它们本身并不是解决方案。
答案 2 :(得分：5)
即使您使用C＃，我也建议您阅读一些有关模式的书籍。首先是GoF书 - Design Pattens。然后尝试阅读一些关于企业设计模式的书。在阅读时，您将识别（或看到）模式。这通常是一个“啊哈”时刻。
您也可以从自己的代码中识别出相同的内容。了解模式将有助于您进行良好的设计。它有助于了解模式，因为当与之相关的问题出现时，您会立即回想起模式。
您指定的编程原则很好，并且遵循它们。然而，他们更多的是在班级。向上移动到系统设计，模式将更有帮助。
最重要的是 - 模式为您提供了与整个团队讨论设计理念的词汇。
答案 3 :(得分：4)
我确信你已经使用了一些设计模式，如果你已经编程了4年，尽管你可能不知道你做过。
设计模式将教你解决一些已经经历过的问题并找到解决方案。最后为我们记录了它。
如果你想学习设计模式，你可以从“Head First Design Patterns”开始，这是一本很棒的书。
答案 4 :(得分：2)
我不确定你真正需要的是设计模式。您可能需要对设计有更全面的了解。如果没有更多信息，就会提出更多建议。
设计模式（如GoF风格）最适合使用特定样式的代码编写。想象一下，你的课程不是作为事物，而是作为人。想象一下，这些人然后通过传递笔记，或通过部门间邮件或类似的东西相互沟通。
一般而言，这些人沟通的方式和消息流的模式与GoF设计模式非常接近。与此不匹配的模式通常是编写适合此模型的应用程序所需的“帮助程序”。
答案 5 :(得分：2)
试试这本书，它很有趣，不仅为您提供了如何实施模式，还提供了何时实施模式。
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124