“避免溜溜球问题”是允许“原始痴迷”的正当理由吗？

根据什么时候原始的迷恋不是代码气味？，我应该创建一个ZipCode对象来代表一个邮政编码而不是一个String对象。

但是，根据我的经验，我更喜欢看到

public class Address{
    public String zipCode;
}

代替

public class Address{
    public ZipCode zipCode;
}

因为我认为后者需要我转到ZipCode类才能理解该程序。

而且我相信如果每个原始数据字段都被一个类替换，那么我需要在许多类之间移动以查看定义，这感觉就像是在遭受溜溜球问题（一种反模式）。

因此，我想将ZipCode方法移到新类中，例如：

旧：

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

新：

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

因此只有需要验证邮政编码的人才能依赖ZipCodeHelper类。而且我发现保持原始痴迷的另一个“好处”是：它使类看起来像其序列化形式（如果有），例如：带有字符串列zipCode的地址表。

我的问题是，“避免溜溜球问题”（在类定义之间移动）是否是允许“原始痴迷”的有效理由？

其假设是，你并不需要溜溜球的邮编类来了解Address类。如果ZipCode设计合理，那么只需阅读Address类，就可以清楚地知道它的作用。

程序不是端到端读取的-通常，程序太复杂而无法实现。您不能同时将所有代码保存在一个程序中。因此，我们使用抽象和封装将程序“分块”为有意义的单元，因此您可以查看程序的一部分（例如Address类），而不必阅读其依赖的所有代码。

例如，我确定您每次在代码中遇到String时，都不会溜溜地阅读String的源代码。

将类从ZipCode重命名为ZipCodeHelper意味着现在有两个独立的概念：邮政编码和邮政编码帮助器。所以复杂了两倍。现在，类型系统无法帮助您区分任意字符串和有效的邮政编码，因为它们具有相同的类型。这是适合“迷恋”的地方：您只是想避免在原语周围使用简单的包装类型，所以建议使用更复杂，更不安全的替代方法。

在没有验证或其他依赖于此特定类型的逻辑的情况下，恕我直言，使用原语是合理的。但是，一旦添加任何逻辑，将这种逻辑与类型封装在一起就容易得多。

至于序列化，我认为这听起来像是您所使用框架的限制。当然，您应该能够将ZipCode序列化为字符串或将其映射到数据库中的列。

如果可以做：

new ZipCode("totally invalid zip code");

ZipCode的构造函数执行以下操作：

ZipCodeHelper.validate("totally invalid zip code");

然后，您破坏了封装，并向ZipCode类添加了一个非常愚蠢的依赖项。如果构造函数没有调用，ZipCodeHelper.validate(...)那么您将在自己的孤岛中隔离逻辑，而无需实际执行。您可以创建无效的邮政编码。

该validate方法应该是ZipCode类上的静态方法。现在，将“有效”邮政编码的知识与ZipCode类捆绑在一起。鉴于您的代码示例看起来像Java，如果给出了错误的格式，则ZipCode的构造函数应引发异常：

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

构造函数检查格式并引发异常，从而防止创建无效的邮政编码，并且静态validate方法可用于其他代码，因此将格式检查的逻辑封装在ZipCode类中。

ZipCode类的此变体中没有“溜溜球”。这就是所谓的适当的面向对象编程。

在这里，我们也将忽略国际化，这可能需要另一个名为ZipCodeFormat或PostalService的类（例如，PostalService.isValidPostalCode（...），PostalService.parsePostalCode（...）等）。

如果您在这个问题上花了很多力气，也许您使用的语言不是适合该工作的工具？这种“域类型基元”很容易用例如F＃表示。

例如，您可以在其中编写：

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

这对于避免常见错误（例如比较不同实体的ID）非常有用。而且由于这些类型化的原语比C＃或Java类轻得多，因此最终您将真正使用它们。

答案完全取决于您实际上要对邮政编码执行的操作。这有两种极端的可能性：

（1）保证所有地址都在一个国家中。完全没有例外。（例如，没有外国客户，或者没有为外国客户工作时其私人地址在国外的雇员。）该国家/地区具有邮政编码，可以期望他们永远不会出现严重问题（即，他们不需要格式自由的输入例如“当前为D4B 6N2，但每2周更改一次”）。邮政编码不仅用于寻址，还用于验证付款信息或类似目的。-在这种情况下，邮政编码类非常有意义。

（2）地址几乎可以在每个国家/地区使用，因此数十个或数百个具有或不具有邮政编码（以及成千上万的怪异异常和特殊情况）的寻址方案都是相关的。实际上，仅要求使用“邮政编码”来提醒那些使用邮政编码的国家/地区的人们不要忘记提供他们的密码。仅使用地址，以便如果某人失去了对其帐户的访问权限，并且可以证明其姓名和地址，则将恢复访问权限。-在这种情况下，所有相关国家/地区的邮政编码类别将是一项巨大的努力。幸运的是根本不需要它们。

其他答案涉及OO域建模以及使用更丰富的类型来表示您的价值。

我没有不同意，尤其是考虑到您发布的示例代码。

但是我也想知道这是否真的回答了您的问题的标题。

考虑以下情形（从我正在从事的实际项目中提取）：

您在与中央服务器对话的现场设备上有一个远程应用程序。设备条目的数据库字段之一是该现场设备所在地址的邮政编码。您不必担心邮政编码（或与此有关的地址的其余部分）。所有关心它的人都在HTTP边界的另一端：您恰好是数据真相的唯一来源。它在您的域建模中没有位置。您只需记录，验证，存储它，然后根据要求将其在JSON Blob中拖移到其他位置。

在这种情况下，除了使用SQL regex约束（或其ORM等效项）验证插入之外，做很多事情都可能对YAGNI品种造成过大杀伤力。

ZipCode仅当您的Address类也没有TownName属性时，抽象才有意义。否则，您将获得一半的抽象：邮政编码指定城镇，但是这两个相关的信息位在不同的类别中。这没有任何意义。

但是，即使那样，它仍然不是原始痴迷的正确应用（或者是解决方案）。据我了解，这主要集中在两件事上：

1. 使用基元作为方法的输入（甚至输出）值，尤其是在需要基元集合时。
2. 这些类会随着时间的推移而增加额外的属性，而无需重新考虑其中的某些属性是否应分组为自己的子类。

你的情况都不是。地址是一个定义明确的概念，具有明显必要的属性（街道，数字，邮政编码，城镇，州，国家/地区...）。还有一点要没有理由打破这种数据，因为它有一个单一的责任：指定地球上的位置。地址需要所有这些字段才能有意义。半个地址毫无意义。

这就是您知道不需要进一步细分的原因：进一步细分会降低Address该类的功能意图。同样，您不需要Name在Person该类中使用子类，除非Name（在没有人陪伴的情况下）在您的域中是有意义的概念。（通常）不是。名称是用来识别人的，它们通常没有价值。

从文章：

更一般而言，溜溜球问题也可以指任何人为了理解一个概念而必须在不同信息源之间不断翻转的任何情况。

读取源代码的频率远远超过写入源代码的频率。因此，必须在许多文件之间切换的溜溜球问题是一个问题。

但是，不，在处理高度相互依赖的模块或类（彼此之间来回调用）时，溜溜球问题显得更为重要。这些是一种特殊的噩梦，很可能是溜溜球问题的创造者想到的。

但是- 是的，避免过多的抽象层很重要！

在某种程度上，所有非平凡的抽象都是泄漏的。-泄漏抽象定律。

例如，我不同意mmmaaa的回答中的假设，即“您不需要溜溜[（访问）] ZipCode类就可以了解Address类”。我的经验是，您至少在阅读代码的前几次就这样做了。然而，正如其他人所指出的，是时候一ZipCode类是合适的。

YAGNI（雅是不会需要它）是一个更好的模式来遵循，以避免烤宽面条代码（代码太多层） -抽象，比如类型和类是有帮助的程序员，并且不应该被使用，除非它们是一种帮助。

我个人的目标是“保存代码行”（当然还有相关的“保存文件/模块/类”等）。我相信有些人会对我适用“原始痴迷”的表述-我发现拥有易于推理的代码比担心标签，样式和反样式更为重要。何时创建函数，模块/文件/类或将函数放置在公共位置的正确选择非常有根据。我的目标大致是3-100行函数，80-500行文件，以及“ 1、2，n”用于可重用的库代码（SLOC-不包括注释或样板；我通常希望强制性每行至少至少增加1个SLOC样板）。

大多数积极的模式来自于开发人员在需要它们时正是这样做的。学习如何编写可读代码比尝试应用没有解决相同问题的模式更为重要。任何优秀的开发人员都可以在很少见的情况下实现工厂模式，而在这种情况下最适合他们的问题的情况很少见。我已经使用了工厂模式，观察者模式，甚至还有数百个模式，却不知道它们的名称（即，是否有“可变分配模式”？）。为了进行有趣的实验-看看JS 语言中内置了多少个GoF模式-我在2009年大约12-15以后就停止了计数。例如，Factory模式非常简单，例如从JS构造函数返回一个对象-无需一个WidgetFactory。

所以- 是的，有时候 ZipCode是一门好课。但是，不，溜溜球问题并不严格相关。

溜溜球问题仅在您必须来回翻转时才有意义。这是由一两件事（有时两者）引起的：

1. 命名错误。ZipCode看起来不错，ZoneImprovementPlanCode将要求大多数人（以及少数不会被打动的人）外观。
2. 耦合不当。假设您的ZipCode类具有区号查询。您可能会认为这很有意义，因为它很方便，但是它与ZipCode并没有真正的联系，将它嵌入其中意味着现在人们不知道该去哪里找东西了。

如果您可以查看名称并对其名称有一个合理的了解，并且方法和属性可以做一些明显的事情，则无需查看代码，只需使用它即可。首先，这就是类的全部要点-它们是可以单独使用和开发的模块化代码段。如果您必须查看该类的API以外的其他内容以查看其功能，那么这充其量是部分失败的。

记住，没有银弹。如果您要编写一个非常简单的应用程序，需要快速进行爬网，那么一个简单的字符串就可以完成任务。但是，在98％的时间内，Eric Evans在DDD中描述的值对象将是完美的选择。通过阅读，您可以轻松地看到Value对象提供的所有好处。