没有吸气剂，您就无法编写好的代码。
原因不是因为吸气剂不会破坏封装，而是这样做。这并不是因为吸气剂不会诱使人们不去遵循OOP，否则OOP会让他们将所处理的数据放入方法中。他们是这样。不，由于边界，您需要吸气剂。
当您遇到无法移动方法并迫使您移动数据的边界时，封装和保留方法以及它们所作用的数据的想法根本行不通。
真的就是这么简单。如果在没有边界的情况下使用吸气剂，则最终将没有真实对象。一切开始趋于程序化。哪个工作得比以往更好。
真正的OOP并不是随处可见的。它仅在这些边界内起作用。
那些边界并不可怕。他们里面有代码。该代码不能是OOP。它也不起作用。没有任何代码会破坏我们的理想，因此它可以应对严峻的现实。
迈克尔·费特斯（Michael Fetters）用白色的结缔组织将橙子的各个部分连在一起后，称其为筋膜编码。
这是一种思考的绝妙方法。它解释了为什么可以在同一代码库中同时包含两种代码。没有这种观点，许多新程序员会坚守自己的理想，然后心碎，在达到自己的第一个界限时就放弃这些理想。
理想只在适当的地方起作用。不要仅仅因为它们在任何地方都不工作而放弃它们。在他们工作的地方使用它们。那个地方是面板保护的多汁部分。
边界的一个简单示例是集合。这拥有某些东西，却不知道它是什么。当集合设计者不知道将要持有什么对象时，他们如何将其行为功能转移到集合中？你不能 您有一个界限。这就是为什么集合有吸气剂的原因。
现在，如果您知道，则可以移动该行为，并避免移动状态。当您知道时，您应该。您只是不总是知道。
有人称这是务实的。是的。但是很高兴知道我们为什么要务实。
您已经表示不想听语义上的争论，而似乎是在提倡“明智的获取者”。您正在要求挑战这个想法。我想我可以证明您的构想方式存在问题。但是它也认为我知道你来自哪里，因为我去过那里。
如果您想在任何地方使用吸气剂，请查看Python。没有私人关键字。但是Python确实可以OOP。怎么样？他们使用语义技巧。他们用下划线标出了任何私人的名称。只要您对此负责，您甚至可以阅读它。他们经常说：“我们都是成年人。”
那么，将吸气剂放在Java或C＃的所有内容之间有什么区别？抱歉，这是语义。Python下划线约定清楚地向您发出信号，表明您正在四处寻找员工的唯一门。对所有事物都使用吸气剂，您就会松开该信号。通过反射，您仍然可以剥离私有，但仍然不会丢失语义信号。这里根本没有结构性论点。
因此，剩下的工作就是决定在哪里悬挂“仅限员工”标志。什么应该被视为私人？您称其为“明智的吸气剂”。正如我已经说过的，获取吸气剂的最佳理由是迫使我们背离理想的界限。那不应该导致所有事情的失败。当确实导致吸气时，您应该考虑将行为进一步转移到可以保护它的多汁位中。
这种分离产生了一些条件。数据传输对象或DTO，不保留任何行为。唯一的方法是getters，有时是setter，有时是构造函数。这个名字很不幸，因为它根本不是一个真正的对象。getter和setter实际上只是调试代码，可为您提供一个设置断点的地方。如果不是那样的话，那将是一堆公共场所。在C ++中，我们曾经称它们为结构。他们与C ++类的唯一区别是它们默认为public。
DTO很不错，因为您可以将它们放在边界墙上，并将其他方法安全地保存在一个多汁的行为对象中。一个真实的对象。没有吸气剂违反它的封装。我的行为对象可以通过将它们用作参数对象来吃掉DTO 。有时我必须制作一份防御性副本以防止共享的可变状态。我不会在边界内多汁的部分内散布可变的DTO。我封装它们。我藏起来了 当我终于遇到一个新的边界时，我会旋转一个新的DTO并将其扔在墙上，从而使它成为其他人的问题。
但是，您想提供表达身份的吸气剂。恭喜，您发现了边界。实体的身份超出其参考范围。也就是说，超出了他们的内存地址。因此，它必须存储在某个地方。而且某些东西必须能够通过其身份来引用这个东西。表达身份的吸气剂是完全合理的。一堆使用该吸气剂来做出实体可能自己做出的决定的代码不是。
最后，错误的不是吸气剂的存在。它们远胜于公共领域。不好的是，当您习惯使用它们假装您是面向对象的时候。吸气剂很好。面向对象是好的。吸气剂不是面向对象的。使用吸气剂开辟出一个面向对象的安全场所。