为什么我们在设计模式中需要这么多的类？

#1 楼

这是一个优化问题

一个好的工程师理解没有目标的优化问题是没有意义的。您不仅可以优化，还必须针对某些事物进行优化。例如，您的编译器选项包括速度优化和代码大小优化；这些有时是相反的目标。

我想告诉我的妻子，我的办公桌经过优化，可以增加。这只是一堆，添加东西非常容易。如果我为检索进行了优化，我的妻子会更喜欢它，即，对我的东西进行一些整理，以便我可以找到东西。当然，这使添加起来更加困难。

软件是相同的方法。您当然可以为产品创建进行优化-尽快生成大量的整体代码，而不必担心组织它。正如您已经注意到的那样，这可能非常非常快。替代方案是优化维护-使创建过程更加困难，但使修改更容易或风险更低。这就是结构化代码的目的。

我建议一个成功的软件产品只能创建一次，却可以多次修改。经验丰富的工程师已经看到，非结构化代码库可以依靠自己的生命生存，并成为产品，其规模和复杂性不断增长，直到即使不进行巨大风险也很难进行很小的更改。如果代码是结构化的，则可以控制风险。这就是为什么要去解决所有这些麻烦的原因。
复杂性来自关系，而不是元素

我在您的分析中注意到，您正在查看数量-代码量，类数等。尽管这些很有趣，但真正的影响来自元素之间的关系，这些关系组合爆炸。例如，如果您有10个功能，而又不知道哪个取决于哪个，则您有90个可能的关系（依赖项）需要担心-十个功能中的每个都可能取决于其他九个功能中的任何一个，而9 x 10 =90。您可能不知道哪个函数会修改哪些变量或如何传递数据，因此编码人员在解决任何特定问题时有很多事情要担心。相反，如果您有30个班级，但它们排列得很巧妙，则它们最多可以有29个关系，例如如果它们是分层的或排列在堆栈中。

这如何影响您团队的吞吐量？好吧，依赖更少了，问题更容易解决了；编码人员在进行更改时不必费神费力。因此，最小化依赖关系可以极大地提高您胜任推理问题的能力。这就是为什么我们将事物划分为类或模块，并尽可能严格地限制变量并使用SOLID原理的原因。

评论

---

但是，我要指出的是，过多的类和间接寻址对理解NOR维护都无济于事。复杂的控制流（也称为回调地狱）也不会。

– Matthieu M.
18年4月11日在8:33

---

@JohnWu这种解释是我读过的最好，最容易理解的方法。

–阿德里亚诺·雷佩蒂（Adriano Repetti）
18年4月11日在9:04

---

写得很好，但是为什么“一次创建但修改了很多次”为何重要呢？ （如果所有代码都在EntityTransformationServiceImpl中，则必须先了解整个过程，然后才能对其进行修复-但是，例如，如果格式有问题，并且Formatter类可以解决该问题，则只需了解该部分的工作原理再加上大约3个月后阅读自己的代码，就像阅读一个陌生人的代码一样。）我觉得我们大多数人下意识地想到了这一点，但这可能是因为经验。对此不是100％肯定。

–R。Schmitz
18年4月11日在14:48

---

对于组合，我会选择完整的10×10 = 100：这些函数很可能是递归的，并且在特别糟糕的代码中，显然不一定如此。

– KRyan
18年4月11日在15:06

---

“另一种选择是优化维护-使创建工作更困难，但使修改更容易或风险更低。这就是结构化代码的目的。”我对隐含的观念表示怀疑，即更多的类=更多的可维护性。尤其是，将逻辑分散在许多类中通常会使得很难在代码中找到总体逻辑概念（尤其是在没有非常专心致力确保概念非常可见的情况下），这极大地降低了可维护性。

– jpmc26
18年4月11日在17:51

---

#2 楼

好吧，首先，易读性和可维护性通常在旁观者的眼中。

对您而言可读的内容可能对您的邻居而言不是。

可维护性通常归结为发现能力（在代码库中发现行为或概念的难易程度）和发现能力是另一件事，这是主观的。

DDD

DDD帮助开发人员团队的一种方式是建议一种组织代码概念和行为的特定方式（但仍是主观的）。此约定使发现事物更容易，从而更易于维护应用程序。


域概念被编码为实体和集合
域行为驻留在实体或域服务中
聚合根确保了一致性
持久性问题由存储库处理

这种安排在客观上并不容易维护。但是，当每个人都了解他们在DDD上下文中运行时，维护起来就容易得多。

类

类有助于维护，提高可读性，发现能力等。因为它们是众所周知的约定。

在面向对象的设置中，类通常用于对密切相关的行为进行分组并封装需要仔细控制的状态。

我知道这听起来很抽象，但是您可以这样考虑：

使用类，您不必知道它们中的代码是如何工作的。您只需要知道类负责什么即可。

类使您可以根据定义良好的组件之间的交互来推理应用程序。

这样可以减轻认知负担在考虑应用程序的工作原理时。不必记住600行代码可以完成什么，您可以考虑30个组件如何交互。

而且，考虑到这30个组件可能跨越应用程序的3层，您可能每个人一次都只能推理大约10个组件。

这似乎很容易管理。

摘要

基本上，您看到的是高级开发人员正在做的事情：

他们将应用程序分解成易于理解的类。

然后他们将这些信息组织成易于推理的层。

之所以这样做，是因为他们知道随着应用程序的增长，从整体上进行推理变得越来越困难。将其细分为“层”和“类”意味着它们永远不必推理整个应用程序。他们只需要推理其中的一小部分即可。

#3 楼

请给我解释一下，为什么我们需要这种DDD样式和大量的图案？


首先，请注意：DDD的重要部分不是图案，而是对齐方式与业务一起进行的开发工作。格雷格·杨（Greg Young）表示，蓝皮书中的章节顺序错误。

但是，对于您的特定问题：班级往往比您期望的要多得多，（a）因为努力是（b）是因为要付出额外的努力来确保域模型中的概念被明确表示。

坦白地说，如果您在域模型中有两个不同的概念域，那么即使它们恰好在内存表示中共享相同的内容，它们也应该在模型中有所区别。

实际上，您正在构建一种领域特定的语言，该语言用业务语言描述您的模型，这样，领域专家就可以查看并发现错误。

此外，您还会发现更多关注点是关注点分离；以及将某些功能的使用者与实现细节隔离开来的概念。参见D. L. Parnas。清晰的边界使您能够更改或扩展实现，而不会在整个解决方案中产生影响。

这里的动机是：将应用程序作为企业核心能力的一部分（意味着一个地方（这会带来竞争优势）），您将希望能够轻松，廉价地以更好的变化方式替换域行为。实际上，您有部分程序要快速发展（状态如何随时间变化），而其他部分则要缓慢变化（状态如何存储）。额外的抽象层有助于避免无意间将彼此耦合。

公平地讲：其中一些也是面向对象的脑损伤。 Evans最初描述的模式基于他15年前参与的Java项目。状态和行为紧密地联系在一起，从而导致您可能宁愿避免的并发症；请参阅Stuart Halloway的《感知和行动》，或John Carmack的《内联代码》。


无论您使用哪种语言，以功能风格进行编程都会带来好处。您应该在方便时执行此操作，而在不方便时应认真考虑该决定。卡马克，2012年

#4 楼

其他答案中有很多优点，但我认为它们错过或不强调您犯的一个重要概念错误：

您正在比较理解完整程序的努力。

对于大多数程序来说，这不是一个现实的任务。
即使简单的程序也包含如此多的代码，以至于在任何给定的时间都不可能在头上管理所有程序。
有机会找到程序中与手头任务相关的部分（修复错误，实现新功能）并使用该部分。

如果您的程序包含巨大的功能/方法/上课这几乎是不可能的。
您必须了解数百行代码，才能确定这部分代码是否与您的问题相关。
通过估算，您可以轻松地花一周的时间来查找所需的代码您需要处理的代码。

将其与具有小的函数/方法/类的代码库进行比较，这些函数/方法/类被命名并组织到程序包/名称空间中，从而很容易在哪里找到/放置给定的逻辑。
在许多情况下，只要做对了，您就可以跳到正确的位置来解决问题，或者至少跳到调试器启动将使您跳数步的正确位置。
/>
我在两种系统中都工作过。
对于可比较的任务和可比较的系统大小，性能上的差异很容易达到两个数量级。

这对其他活动的影响：


使用较小的单元，测试变得更加容易
，因为两个开发人员处理同一段代码的机会较小，所以合并冲突更少。
重复的原因是，它更容易重用代码段（以及查找代码段）首先）。

#5 楼

因为测试代码比编写代码更难

从开发人员的角度来看，许多答案都给出了充分的理由-可以减少维护，但要从一开始就使代码变得更加费劲。

但是，还有另一个方面需要考虑-测试只能作为原始代码进行细化。

如果将所有内容都编写成一个整体，则唯一有效的测试您可以输入“给出这些输入，输出正确吗？”。这意味着发现的所有错误都被限制在“大量代码中的某个地方”。

当然，您可以让开发人员坐在调试器中，确切地找出问题的出处并进行处理。修复。这会占用大量资源，并且会浪费开发人员的时间。想象一下，您遇到的每一个小错误都会导致开发人员需要再次调试整个程序。

解决方案：许多较小的测试可以精确地确定每个特定的潜在故障。

这些小型测试（例如单元测试）具有检查代码库特定区域并帮助发现有限范围内的错误的优势。这不仅可以在测试失败时加快调试速度，而且还意味着，如果所有小型测试都失败了，那么您可以在大型测试中更轻松地找到失败的原因（即，如果它不在特定的测试功能中，则必须在交互中实现）在它们之间）。

应该很清楚，进行较小的测试意味着您的代码库需要分成较小的可测试块。在大型商业代码库上，这样做的方法通常会导致代码看起来像您正在使用的代码。

只是说明：这并不是说人们会不要把事情“推得太远”。但是有合理的理由将代码库分成较小/较少连接的部分-如果明智的话。

#6 楼

请向我解释一下，为什么我们需要这种DDD样式和许多模式？


我们中的很多人（大多数...）真的不需要它们。理论学家和非常有经验的程序员根据大量的研究和深厚的经验编写了有关理论和方法的书，这并不意味着他们编写的所有内容都适用于每个程序员的日常实践。

作为一个初级开发人员，最好阅读您提到的书籍，以扩大您的观点，并使您意识到某些问题。当您的高级同事使用您不熟悉的术语时，它还可以使您免于感到尴尬和困惑。如果您发现一些非常困难的东西，并且似乎没有任何意义或有用，请不要为之沉迷-只需将其归档在脑海中，就可以想到存在这样的概念或方法。

在您的日常开发中，除非您是一名学者，否则您的工作就是找到可行，可维护的解决方案。如果您在书中发现的想法不能帮助您实现该目标，那么只要您的工作被认为令人满意，就不要担心它。

有时候您会发现您可以使用所读到的一些内容，但是一开始并没有完全“了解”，也许不是。

#7 楼

由于您的问题涉及很多领域，有很多假设，因此我将提出您问题的主题：


为什么我们在设计模式中需要这么多的类


我们没有。没有公认的规则说设计模式中必须有许多类。

有两个主要指南可用来决定将代码放置在何处以及如何将任务切成不同的代码单元：


内聚性：任何代码单元（无论是包，文件，类还是方法）都应该属于同一类。即，任何特定的方法都应该完成一项任务，并做到这一点。任何课程都应负责一个较大的主题（无论可能是什么）。我们需要高度的内聚性。
耦合：任何两个代码单元之间的依赖关系应尽可能少-特别是不应存在循环依赖关系。我们想要低耦合。

为什么这两个很重要？


凝聚力：一种可以完成很多事情的方法（例如，老式CGI在一堆冗长的代码中同时进行GUI，逻辑，数据库访问等的脚本变得笨拙。在撰写本文时，很容易将您的思路付诸实践。这行得通，很容易演示，您可以完成。麻烦稍后出现：几个月后，您可能会忘记所做的事情。顶部的代码行可能与底部的代码行相距几个屏幕。很容易忘记所有细节。方法中任何地方的任何更改都可能破坏复杂事物的任何行为。重构或重用该方法的某些部分非常麻烦。依此类推。
耦合：每次更改代码单元时，都有可能破坏依赖于它的所有其他单元。在Java之类的严格语言中，您可能会在编译时获得提示（例如，有关参数，声明的异常等）。但是许多变化并不会触发这种变化（即行为变化），而其他更具动态性的语言则没有这种可能性。耦合度越高，更改任何内容的难度就越大，您可能会陷入停顿，在这种情况下，必须完全重写才能实现某些目标。

这两个方面是基本的“驱动因素”在任何编程语言和任何范例中（不仅是面向对象），都可以选择“在哪里放置什么”。并不是每个人都明确地意识到它们，而且要花很长时间（通常是数年）才能对它们如何影响软件产生一种真正根深蒂固的自动感觉。

显然，这两个概念并不能告诉您有关什么的任何信息实际去做。有些人在过多的方面犯了错误，另一些人则在过少的方面犯了错误。由于语言本身的极端静态和古怪的性质，某些语言（在这里是Java）倾向于使用许多类（这不是值声明，而是它的本质）。当您将它与动态和更具表达能力的语言（例如Ruby）进行比较时，这一点尤其明显。

另一方面，有些人赞成敏捷方法，即仅编写当前必需的代码，并且必要时在以后进行大量重构。在这种开发方式中，如果只有一个实现类，则不会创建interface。您只需实现具体类。如果以后需要第二堂课，则可以重构。

有些人根本就不那样做。他们为任何可以更普遍使用的东西创建接口（或更一般地，抽象基类）。这很快导致班级爆炸。

同样，有赞成和反对的论据，无论是我还是您更喜欢哪个。在您作为软件开发人员的一生中，您将遇到各种极端情况，从漫长的意大利面条方法到开明的，足够大的类设计，再到令人难以置信的过度设计的过度计划。随着经验的增加，您将越来越多地担任“建筑”角色，并可以朝您希望的方向开始对此产生影响。您会发现自己的黄金中间点，无论您做什么，仍然会发现很多人会不同意您的意见。

因此，保持开放的心态是最重要的，在这里，这是我对您的主要建议，考虑到其他人的判断，您似乎对此事感到非常痛苦。您的问题...

#8 楼

经验丰富的编码人员已经了解到：



由于那些小巧的程序和小技巧开始发展，尤其是那些成功的小技巧。在简单级别上起作用的简单模式无法扩展。
因为每次添加/更改都必须添加/更改多个工件似乎很麻烦，但是您知道要添加的内容并且很容易做到。 3分钟的打字比3个小时的编码好。
很多小类不是“混乱”，只是因为您不了解为什么开销实际上是一个好主意。
如果没有添加领域知识， “对我而言显而易见”的代码通常对我的队友来说都是神秘的……再加上对我的未来。
部落知识可以使项目难以置信地增加团队成员的难度，并使他们难以迅速提高生产力。
命名是计算中仍然存在的两个难题之一，许多类和方法通常是命名中的一个激烈练习，很多发现这是很大的好处。

#9 楼

到目前为止，所有答案都是好的，都是从合理的假设开始的，即询问者遗漏了一些东西，而询问者也承认这一点。提问者也可能基本正确，值得讨论这种情况如何发生。

经验和实践是有力的，并且如果老年人获得了在大型，复杂项目中的经验，唯一的通过大量的EntityTransformationServiceImpl来控制事物的方法是，它们变得快速，舒适，具有设计模式并紧密遵守DDD。使用轻量级方法，即使对于小型程序，它们的效率也将大大降低。奇怪的是，您应该适应，这将是一次很棒的学习经验。

尽管适应，但您应该将其作为在深入学习单一方法之间取得平衡的课程您可以使其在任何地方都可以工作，而不必保持多功能性并知道可用的工具，而不必成为其中任何一个的专家。两者都有优势，世界都需要。

#10 楼

由于此答案的第一篇文章没有达到我想要的目标，因此我购买了本书的Kindle版本，并找到了我隐约记得的内容，以便直接回答问题


为什么我们的设计模式需要这么多的类？


又短又甜-我们不需要。正是为什么这是真的，我不确定我能像这本书一样用语言表达，这就是我最初发布的答案的要旨。

以下是摘录自该书的摘录很好地直接回答了这个问题。

这本书的摘录摘自第3章“模式”和第3章“有多种实现模式的方法”：


在本书中，您会发现模式实现看起来与设计模式中的结构图完全不同。对于
示例，这是Composite模式的结构图：





这是Composite的特定实现模式：





如您所见，Composite的此实现与Composite的结构图几乎没有相似之处。这是
最低限度的Composite实现，仅通过编码即可实现。

在模式实现中实现简约是
进化设计实践的一部分。在许多情况下，可能需要发展非基于模式的实现以包含模式。在这种情况下，您可以将设计重构为简单的模式实现。我在整本书中都使用
这种方法。


在本章的稍早部分，Joshua说：


该图表示Creator和Product类是
抽象，而ConcreteCreator和ConcreteProduct类是
具体。这是实现工厂方法的唯一方法吗？
模式？绝不！实际上，“设计模式”的作者在
“实现说明”部分中竭尽全力地解释了实现每种模式的不同方法。如果您阅读Factory Method模式的实现
注释，您会发现有很多方法可以实现Factory Method。


这里是整个部分，其中只是一些细节：




[原始帖子]

我想将您指向一本书，我认为这本书更能启发您的理解，即何时有必要，何时过大，以“在设计模式中使用这么多的类”，因为该作者通常非常节俭地实现设计模式，只是一些面向对象的“零件”。



这本书是Martin Fowler签名系列之一，并且是Joshua Kerievsky撰写的关于设计模式的出色著作，标题为“重构为模式”，但实际上是关于“对和/或远离模式的正确处理”。对我来说，这是非常值得的价格。

在他的书中，他有时不使用面向对象地实现模式，而是使用一些字段和方法。而且他有时会完全删除一个模式，因为它太过杀了。因此，我很喜欢他对主题的处理，因为何时分发图案以及何时轻量化的“平衡”是他赠送给读者的礼物。

这是大多数内容的屏幕截图。目录的相关部分。这是我最好的购买之一。



在此目录中，我特别强调以下内容：


并且我强调以下内容：

过度设计
模式灵丹妙药

正在设计中的
人类可读代码
清洁
图案快乐
有很多方法可以实现图案

重构，朝向和远离模式
模式会使代码更复杂吗？
代码气味

因此，我认为您的问题可以解释为一种内部质疑：“我们真的必须使用这么多的类来实现模式吗？”答案是“有时”，当然还有看似永远存在的“取决于”。但是，要想回答您，还需要花更多的书，因此，我建议您尽可能地读一读。 （目前我还没有收到，否则我会给你一个很好的例子-抱歉。）HTH。

#11 楼

按用途使用更多的类和函数将是一种以特定方式解决问题的好方法，这将有助于将来解决任何问题。

多个类有助于确定其基本工作，任何类都可以随时可以被调用。

但是，如果您从它们的可获取名称中获得了许多类和函数，则它们很容易调用和管理。
这被称为干净代码。