Oop 欣赏优秀设计的价值

最近，我刚毕业或有1-2年的工作经验，就与一群人（来自两个不同的公司）一起工作，他们对各种行业流行语和设计模式等方面的知识给我留下了深刻的印象。此外，他们对OO设计原理和界面的使用都有很好的理解

长话短说…。在与他们一起工作的短短几天里，我发现事情并不像看上去的那样

让我来定义一些我将在这里使用的术语 知识——你在学校、书本或互联网上学习的东西

体验——你做某事的时间

技能——仅通过经验获得。这就是获得技能（随着时间的推移）并知道如何应用你所拥有的知识

我发现，尽管他们知道这些东西，但他们真的不知道如何应用这些知识。所有这些模式都会在你的脸上挥舞，但他们必须自行编写的任何代码都有基本的缺陷。他们可以告诉您某个设计模式的优点，并可以提出某种实现，但无法识别设计中的基本缺陷

当然，我也有我应得的那份“不知道自己不知道的人——孔子”

每天晚上，我都会花大量时间重复白天所说的每一句话，试图理解谁在说什么以及为什么，试图通过培训或代码审查中的示例来找出我可以做什么。但坦率地说，我很困惑

大约2-3周后，我开始明白这一点。 不管怎样，先问问题 1.你有过这种经历吗？ 2.你（或你）是如何解决这个问题的

我的结论是，要么学校做得不好，要么谷歌是他们的朋友，他们得到了所有这些“知识”，并认为自己知道

但我觉得

为了能够识别和欣赏好的设计，一个人必须编写设计得很好的代码，而不是设计得很好的代码。与它斗争，然后修复它，以了解痛苦，从而识别好的和坏的设计，并欣赏它

实践和经验——这是你无法克服的。经验（以及经验的质量）带来的东西太多了，你无法用知识或一点点经验来匹配

我还经历了其他一些事情： “为什么这是一个接口而不是一个基类”——你会得到各种各样的答案，但没有一个是正确的理由

为什么是这种设计模式而不是那种模式，或者暂时忘记设计模式，只进行设计（他们完全迷失了方向——这时你才看到他们真正的设计编码技能）

过度工程化——不认识到这一点，也不了解他们，随着系统的发展，这可能是一场维护噩梦。我发现这是个大问题。好像一切都有可能改变。除了.NET框架中用于发送电子邮件的各种类之外，发送电子邮件的简单过程还有3个类

使用框架或语言中的所有新功能只是因为（我甚至在Microsoft针对某个框架的一些源代码中看到了这一点，该框架的源代码是可用的）

因此，10年后，所有编写代码的人都在使用所有可能的设计模式，使用所有花哨的框架或语言特性来编写代码，因此“遗留”代码编写得很好，设计得很好。还是这样？你觉得怎么样

---

还有谁会觉得10年后我们会经历一种不同的困境。那些乱七八糟的东西散落在十几个代码文件中，因为现在我们有了类和所谓的松散耦合代码，但这只是另一种混乱，事实上更难清理？

有趣的讨论。我一直认为，随着时间的推移，我们正在过度设计我们的系统，所有的模式都在不断变化。额外的抽象层意味着将来在理解上会有更多的失败。我个人的做法是保持事情简单，只有在需要时才引入复杂性。如果需要解耦，则解耦。许多设计需求确实在系统中流动，因为我们盲目地在需求文档中输入它应该是可维护的、可靠的和完全可维护的。还需要了解我们对这些资源的需求程度，以及更重要的是，它们在短期和长期内如何影响我们的预算和业务价值

---

一个重要的方面是，在每个阶段，无论是功能还是预算方面，都要始终非常关注业务需求。

我完全同意，新一代的开发人员在设计模式和最新的流行语（如hibernate、jason、nant、，另一方面，我发现即使是其中最好的，那些可以被认为是明星程序员的人对幕后真正发生的事情的理解和知识也很有限

过去，我曾与一些年轻人进行过几次对话，他们将spring视为一项重大创新，试图说服他们，这个框架通过反射为我们提供的是IDL、类型库、COM和CORBA等事物的演变

当谈到四人帮引入的设计模式和术语时，我们都知道他们提出的体系结构已经使用了几十年，一位高级开发人员几乎是凭直觉使用它们，而不知道常规工厂与抽象工厂的形式差异。毫无疑问，DP运动引入的形式化对该行业是有益的，尽管模式的识别和成功实施仍然（可能是一种趋势）