Ram*_*Vel 6 c# language-agnostic design-patterns
我是一名拥有4年.Net编码经验的开发人员,从不关心我的设计模式.最近我被要求接受IT部门的一位大佬的采访,已经完成了5轮(解决问题,配对编程,逻辑推理,2轮技术面试)的采访,并没有提供工作.
我从他们那里获得的反馈是不擅长设计原则,尽管他们对我的技术和逻辑推理技巧感到满意.这个让我觉得知道设计模式是解决问题的唯一方法吗？
虽然我从未在编码中使用过很多设计模式,但我总是试图实现OOPS的基本原理
我可以使用这些原则来设计一个松散耦合和开放的系统,以增强和易于维护.事实上,这些是所有设计模式的核心结构.
但我的问题是为正确的问题找到一个正确的模式.我知道只有阅读设计模式和实践中出版的所有书籍才能获得这些知识.这些知识伴随着构建不同系统的经验.
是否有任何用例可用于模式问题匹配 ..您对学习设计原则的建议是什么？
干杯
Eri*_*ert 15
虽然我认为变得更熟悉设计模式并不会有什么坏处,但我想确保你的问题中没有两个东西的混合.你说你得到的反馈是你应用设计原则的能力很弱,你从反馈中得出结论,你需要研究设计模式.但那是不同的.
"设计模式"是您在许多不同域中看到的重复模式.例如,在建筑中,您可以看到许多不同类型的建筑中的"内部庭院"的模式.在编程中,您可以在许多不同类型的程序中看到类似"只能拥有单个实例的类"或"将这一点与此相关的一小块代码"的模式.
但原则不是模式.模式是一种特殊的反复出现的设计; 原则是一个构思的基础,这个构思使得设计对于正在设计的工件的用户有益.
例如,JScript语言的设计原则是"容忍小错误".如果您在11月31日创建了一个日期对象,它将默默地将其更正为12月1日,而不是给出错误.没有"小错误的宽恕模式".设计容错是一个设计原则 - 当我们可以选择如何设计一个特定的特征时,我们会考虑它与所有原理的一致性 - 其中一些是矛盾的 - 并用它们来指导设计的功能.
这不是 C#的设计原则; 实际上,相反的是C#的设计原则.设计原则本身并不好或坏; 它们是使设计适合其目标用户群的指导原则.
编写代码而不理解模式意味着没有工具箱中的工具可以更轻松地完成常见任务.编写代码而不理解设计原则意味着编写不一致,难以理解且与用户需求相反的代码.两者都很重要,但它们非常不同.
设计模式被称为模式,因为它们在许多独立程序中一次又一次地显示出来,而不是因为它们习惯于将方块拼接在一起以便将方块拼接在一起以形成被子.它们可以帮助解决软件问题,但它们本身并不是解决方案.
即使您使用C#,我也建议您浏览一些有关模式的书籍.首先是GoF书 - Design Pattens.然后尝试阅读一些关于企业设计模式的书.在阅读时,您将识别(或看到)模式.这通常是一个"啊哈"的时刻.
您也可以从自己的代码中识别出相同的内容.了解模式将有助于您进行良好的设计.它有助于了解模式,因为当出现与之相关的问题时,您会立即回忆起模式.
您指定的编程原则很好,并且遵循它们.然而,他们更多的是在班级.向上移动到系统设计,模式将更有帮助.
最重要的是 - 模式为您提供了与整个团队讨论设计理念的词汇.