应该优先考虑什么：YAGNI或Good Design？

public class CustomerRepository : ICustomerRepository
{
    ICustomerFactory factory = null;

    public CustomerRepository() : this(new CustomerFactory() { }

    public CustomerRepository(ICustomerFactory factory) {
        this.factory = factory;
    }      

    public Customer Find(int customerID)
    {
        // data access stuff here
        return factory.Build(ds.Tables[0].Rows[0]);
    }
}

#1 楼

是否有一个很好的方法可以在适当的软件设计与不过度设计解决方案之间做出折衷？


YAGNI。


我可以牺牲一些良好的设计


错误的假设。


和基础界面，然后是单个混凝土，


那不是“牺牲”。那是好的设计。

#2 楼

在大多数情况下，避免使用不需要的代码可以带来更好的设计。最易于维护和面向未来的设计是使用最少数量的满足要求的命名简单的代码。

最简单的设计是最容易演变的。没有什么比无用的，过度设计的抽象层杀死了可维护性。

#3 楼

YAGNI和SOLID（或任何其他设计方法）不是互相排斥的。但是，它们是相反的极性。您不必都坚持100％，但是会有一些让步。您越是在一个位置上看到一个班级使用的高度抽象的模式，并说出YAGNI并将其简化，则设计变得越不牢固。反之亦然。在开发中很多次，设计都是“按信念”实现的。您看不到将如何使用它，但是您只有预感。这可能是正确的（并且您获得的经验越多，就越有可能成为现实），但它也可能使您承担像轻率的“轻而易举”的方法一样多的技术负担。而不是DIL“意大利面条代码”代码库，您可能最终会获得“果仁蜜饼代码”，因为其层数如此之多，以至于简单地添加方法或新数据字段就变成了耗费几天时间遍历服务代理和松散耦合的依赖项的过程。只有一个实现。否则，您可能最终会遇到“ spaghetti-Os代码”，它以如此小巧，结构松散的形式出现，使得体系结构中的上，下，左或右移动可带您通过50条方法，每条3行。 br />我已经在其他答案中说过，但这是：在第一遍，使其生效。在第二遍，使其优雅。在第三遍，将其设置为SOLID。在这一点上，就您所知，这是一次性的。因此，构建“象牙塔”架构以添加2和2并没有任何风格点。做您必须做的，并假设您再也看不到它了。

下次您的光标进入该代码行时，您现在就不再像首次编写那样就驳斥了这一假设。您正在重新访问该代码，可能会将其扩展或在其他地方使用它，因此它不是一次性的。现在，应该实现一些基本原理，例如DRY（不再重复）和其他一些简单的代码设计规则。为重复的代码提取方法和/或形成循环，为常见的文字或表达式提取变量，可能添加一些注释，但是总体上您的代码应自行记录。现在，您的代码井井有条，甚至可能是紧密耦合的，其他任何查看它的人都可以通过阅读代码轻松地了解您在做什么，而不是逐行跟踪。

第三次您的光标输入该代码时，可能会很麻烦；您要么再次扩展它，要么在代码库中的至少其他三个不同地方变得有用。在这一点上，它是系统的关键（如果不是核心的话）元素，因此应如此设计。在这一点上，您通常还了解到目前为止如何使用它，这将使您可以就如何设计设计以简化这些用法和任何新用法做出良好的设计决策。现在，SOLID规则应输入方程式；提取包含特定目的代码的类，为具有相似目的或功能的任何类定义通用接口，在类之间建立松耦合的依赖关系，并设计依赖关系，以便您可以轻松地添加，删除或交换它们。

从这一点开始，如果您需要进一步扩展，重新实现或重用此代码，则将它们很好地打包并以我们都知道和喜欢的“黑匣子”格式抽象；将其插入您需要的其他位置，或在主题上添加新的变体作为该接口的新实现，而不必更改该接口的用法。

#4 楼

我更喜欢WTSTWCDTUAWCROT而不是这两种方法？

（我们能做的最简单的事情是什么有用，我们可以在星期四发布？）要做的事情，但不是优先事项。

#5 楼

YAGNI和良好的设计没有冲突。 YAGNI即将（不）支持未来的需求。好的设计是要透明化您的软件当前所执行的操作以及其执行方式。

引入工厂会使您现有的代码更简单吗？如果没有，请不要添加它。如果可以，例如在添加测试时（应该做！），就添加它。复杂性，同时仍支持所有当前功能。

#6 楼

它们没有冲突，您的目标是错误的。

您要完成什么？

您要编写高质量的软件，并希望做到这一点您的代码库很小，没有问题。

现在我们陷入了冲突，如果我们不编写不打算使用的案例，那么如何掩盖所有案例？

这是您的问题所在。

（任何有兴趣的人，这被称为蒸发云）

那么，这是什么引起的？ >
您不知道不需要什么
您不想浪费时间和膨胀代码

我们可以解决其中哪一项？好吧，看起来不想浪费时间和膨胀的代码是一个伟大的目标，而且很有意义。那第一个呢？我们能找出我们需要编写什么代码吗？没有任何东西，而且一切都只是在没有韵律或理由的情况下被黑了）[...]我退后一步，认为这违反了YAGNI，因为我非常确定地知道我们不需要扩展某些这些类。


让我们重新措辞所有这些


没有代码标准
没有正在进行的项目计划
哇，到处都是牛仔在做自己该死的事情（而你正试图在荒野的西部扮演警长）。软件设计，而不是过度设计解决方案？


您不需要妥协，您需要有人来管理有能力且对整个项目有远见的团队。您需要一个可以计划您需要的人，而不是每个人都投入您不需要的东西，因为您对未来如此不确定，因为……为什么？我告诉你为什么，这是因为在你们所有人中间没有人制定该死的计划。您正在尝试引入代码标准来解决一个完全独立的问题。您需要解决的主要问题是明确的路线图和项目。一旦有了这些，您就可以说“代码标准可以帮助我们更有效地实现团队目标”，这是绝对的事实，但不在此问题的范围之内。

获取项目/团队经理谁可以做这些事情。如果您有一个，则需要问他们一张地图，并解释YAGNI问题，即没有地图。如果他们严重不称职，请自己编写计划并说：“这是我为您提供的关于我们需要的报告，请仔细阅读并告知我们您的决定。”

#7 楼

YAGNI绝不会涉及允许使用单元测试扩展代码，因为您将需要它。但是，我不认为您对单一实现接口的设计更改实际上会提高代码的可测试性，因为CustomerFactory已经从接口继承，并且可以随时替换为MockCustomerFactory。

#8 楼

这个问题提出了一个错误的困境。正确应用YAGNI原则并非无关紧要。这是良好设计的一方面。 SOLID的每个原则也都是良好设计的方面。您不能总是在任何学科中都完全应用所有原则。现实中的问题对您的代码施加了很大的力量，其中一些力量朝相反的方向发展。设计原理必须解决所有这些问题，但是没有几个原理可以适合所有情况。

现在，让我们看一下每个原理，并理解它们有时可能会朝不同的方向发展，它们决不是天生就存在冲突。

YAGNI旨在帮助开发人员避免一种特殊的返工：这种返工是由错误的东西引起的。它通过指导我们避免基于对我们认为将来会发生变化或需要的假设或预测做出过早的错误决策来做到这一点。集体经验告诉我们，当我们这样做时，我们通常是错误的。例如，除非您立即知道需要多个实现者，否则YAGNI会告诉您不要为可重用性创建接口。同样，YAGNI会说不要创建“ ScreenManager”来管理应用程序中的单个表单，除非您现在知道将要拥有多个屏幕。

与许多人的看法相反，SOLID与可重用性，通用性甚至抽象无关。 SOLID旨在帮助您编写为更改做好准备的代码，而无需说明任何具体更改。 SOLID的五项原则创建了一种构建代码的策略，该策略既灵活又不会过于泛泛，而又简单又不会太幼稚。正确应用SOLID代码会产生具有明确定义的角色和边界的小型，专注的类。实际结果是，对于任何所需的需求更改，都需要触摸最少数量的类。同样，对于任何代码更改，到其他类的“涟漪图”的数量最少。

看看您遇到的示例情况，让我们看看YAGNI和SOLID可能要说些什么。由于所有存储库从外部看起来都相同，因此您正在考虑使用通用的存储库接口。但是，通用接口的价值在于可以使用任何实现程序，而无需知道具体是哪个接口。除非您的应用程序中有某个地方是必要或有用的，否则YAGNI表示不要这样做。

有5条SOLID原则需要考虑。 S是单一责任。这没有说明接口，但是可能说明了具体的类。可以争辩说，最好将数据访问本身作为处理一个或多个其他类的责任，而存储库的职责是从隐式上下文（CustomerRepository是对Customer实体隐式存储库）转换为对指定客户实体类型的通用数据访问API。

O是开闭的。这主要是关于继承。如果您尝试从实现通用功能的通用库中获取存储库，或者希望从其他存储库中进一步获取存储库，则适用此方法。但是您不是，所以不是。

L是Liskov可替换性。如果您打算通过公共存储库界面使用存储库，则适用此规则。它对接口和实现施加了限制，以确保一致性并避免对不同实现者进行特殊处理。原因是这种特殊处理破坏了接口的目的。考虑此原则可能很有用，因为它可能会警告您不要使用公共存储库界面。这与YAGNI的指导相吻合。

我是接口隔离。如果您开始向存储库添加其他查询操作，则可能适用。接口隔离适用于您可以将类的成员分为两个子集，其中一个将由某些使用者使用，另一个由其他使用者使用，但是没有使用者可能会同时使用两个子集的情况。指南是创建两个单独的接口，而不是一个通用的接口。在您的情况下，获取和保存单个实例的可能性不太可能被用于一般查询的同一代码占用，因此将它们分成两个接口可能会很有用。

D是依赖注入。在这里，我们回到与S相同的地方。如果您将对数据访问API的使用划分为一个单独的对象，则此原则表示，在创建对象时应将其传递给它，而不是仅更新该对象的实例。存储库。这样可以更轻松地控制数据访问组件的生存期，从而可以在存储库之间共享对它的引用，而不必走单例之路。需要注意的是，大多数SOLID原则不一定适用于应用程序开发的特定阶段。例如，是否应该中断数据访问取决于它的复杂程度，以及是否要在不访问数据库的情况下测试存储库逻辑。听起来这不太可能（不幸的是，在我看来），所以它可能没有必要。

因此，经过所有考虑，我们发现YAGNI和SOLID实际上确实可以立即提供一个通用的实体-相关建议：可能不必创建通用的通用存储库接口。

所有这些仔细的考虑对于学习都是非常有用的。随着学习的进行，这非常耗时，但是随着时间的推移，您会发​​展直觉并变得非常快。您会知道做对的事情，但是除非有人要求您解释原因，否则您无需考虑所有这些单词。

#9 楼

您似乎相信，“好的设计”意味着遵循某种思想和规则集，即使无用的情况也必须始终遵循。

IMO这是糟糕的设计。 YAGNI是优良设计的组成部分，从不与它矛盾。

#10 楼

在您的示例中，我想说YAGNI应该占上风。如果您以后需要添加接口，则不会花费那么多钱。顺便说一句，如果根本没有任何目标，按类提供一个接口真的是一种好的设计吗？以下是有关该主题的非常有趣的帖子序列：


足够的设计
足够的设计意味着好的设计
当足够的设计意味着差的设计

#11 楼

有人认为，接口名称不应以I开头。具体原因之一是，实际上是在泄漏对给定类型是类还是接口的依赖性。

是什么阻止了您首先成为CustomerFactory的类，然后又将其更改为将由DefaultCustormerFactory或UberMegaHappyCustomerPowerFactory3000实现的接口？您唯一需要更改的就是实现实例化的地方。而且，如果您的设计不太理想，那么最多就是几个地方。

重构是开发的一部分。与为每个单个类声明一个接口和一个类相比，最好使代码少一点，易于重构，这迫使您同时至少在两个位置更改每个方法名。

使用接口的真正目的是实现模块化，这可能是良好设计的最重要支柱。但是请注意，模块不仅由其与外界的去耦定义（即使这是我们从外部角度来看的方式），而且同样由其内部工作定义。
我要指出的是，去耦的事物，本质上属于在一起的事物，没有多大意义。从某种意义上来说，这就像一个橱柜，每个杯子都有一个单独的架子。

重要性在于将一个大而复杂的问题设计成更小，更简单的子问题。而且，您必须停下来，在它们变得足够简单而无需进一步细分的情况下，否则它们实际上将会变得更加复杂。这可以看作是YAGNI的必然结果。这绝对意味着好的设计。

目标不是要以某种方式通过单个存储库和一个工厂来解决本地问题。目的是，此决定对您的其余应用程序不起作用。这就是模块化的意义。
您希望您的同事看着您的模块，看到带有几个不言自明的调用的外观，并感到自信，他们可以使用它们，而不必担心所有潜在的复杂内部管道。

#12 楼

您将创建一个interface，以期将来实现多种实现。您可能还对代码库中的每个类都有一个I<class>。不要。

只使用根据YAGNI的单个具体类。如果发现需要用于测试的“模拟”对象，请将原始类转换为具有两个实现的抽象类，一个具有原始的具体类，另一个具有模拟的实现。

显然，您将不得不更新原始类的所有实例化以实例化新的具体类。您可以通过在前面使用静态构造函数来解决此问题。

YAGNI表示在需要编写代码之前不要编写代码。 br />
可以同时拥有。类是抽象。

#13 楼

为什么标记界面？令我惊讶的是，它所做的不过是“标记”。每个工厂类型都有不同的“标签”，这有什么用？说话。因此，如果您所有具体的存储库类型的行为都像相同的IRepository（它们都实现了IRepository），那么它们可以由其他代码以完全相同的代码以相同的方式处理。此时，您的设计是可扩展的。添加更多具体的存储库类型，所有类型都作为通用IRepository处理-相同的代码处理所有具体类型，与“通用”存储库相同。

接口用于基于通用性处理事物。但是自定义标记界面a）不添加任何行为。 b）强迫您处理它们的唯一性。

就您设计有用的接口而言，您将获得OO的好处，即无需编写专门的代码来处理具有以下特征的专用类，类型或自定义标记接口与具体类别的比例为1：1。那是毫无意义的冗余。

例如，如果您需要包含许多不同类的强类型集合，则可以看到标记接口。在集合中，它们都是“ ImarkerInterface”，但是当您将它们拉出时，必须将它们转换为适当的类型。

#14 楼

您现在可以写下一个合理的ICustomerRepository吗？例如，（过去确实到达这里，可能是一个不好的例子）您的客户过去一直使用PayPal吗？还是公司中的每个人都对与阿里巴巴建立联系充满了敬意？如果是这样，您可能现在想使用更复杂的设计，并且对老板来说是有远见的。 :-)

否则，请稍等。在拥有一个或两个实际实现之前，在接口上进行猜测通常会失败。换句话说，除非您有几个示例可以概括，否则不要概括/抽象/使用奇特的设计模式。