在最近的几篇文章中，包括“ Getters / Setters。 邪恶。 期。” ， “对象应该是不可变的”和“依赖注入容器是代码污染者” ，我普遍将所有可变对象标记为“ setter”（以set开头的对象方法）。 我的论证主要基于隐喻和抽象实例。 显然，这对你们中的许多人来说还不够令人信服-我收到了一些要求提供更具体和实际示例的请求。
因此，为了说明我对“通过setter进行可变性”的强烈否定态度，我从Apache那里获取了一个现有的commons-email Java库，并以不使用setter和“对象思考”的方式重新设计了它。 我作为jcabi家族的一部分— jcabi-email发布了我的库。 让我们看看从没有吸气剂的“纯”面向对象，不变的方法中获得的好处。
如果您使用commons-email发送电子邮件，则代码如下所示：
Email email = new SimpleEmail();email.setHostName("");email.setSmtpPort(465);email.setAuthenticator(new DefaultAuthenticator("user", "pwd"));email.setFrom("yegor@teamed.io", "Yegor Bugayenko");email.addTo("dude@");email.setSubject("how are you?");email.setMsg("Dude, how are you?");email.send();
这是使用jcabi-email的相同方法：
Postman postman = new Postman.Default(new SMTP("", 465, "user", "pwd"));Envelope envelope = new Envelope.MIME(new Array<Stamp>(new StSender("Yegor Bugayenko <yegor@teamed.io>"),new StRecipient("dude@"),new StSubject("how are you?")),new Array<Enclosure>(new EnPlain("Dude, how are you?")));postman.send(envelope);
我认为区别很明显。
在第一个示例中，您正在处理一个怪物类，该类可以为您做所有事情，包括通过SMTP发送MIME消息，创建消息，配置其参数，向其中添加MIME部分，等等。commons的Email类电子邮件确实是一个巨大的类-33个私有属性，一百多种方法，大约两千行代码。 首先，通过一堆设置器配置类，然后要求它为您send()电子邮件。
在第二个示例中，我们通过七个new调用实例化了七个对象。Postman负责打包MIME邮件；SMTP负责通过SMTP发送邮件； 标记（StSender，StRecipient和StSubject）负责在传递之前配置MIME消息；EnPlain附件负责为我们要发送的消息创建MIME部分。 我们构造了这七个对象，将它们封装在一起，然后让邮递员为我们send()信封。
可变电子邮件有什么问题？
从用户的角度来看，几乎没有错。Email是一门功能强大的类，具有多个控件-只需单击正确的控件即可完成工作。 但是，从开发人员的角度来看，Email类是一场噩梦。 主要是因为该课程非常大且难以维护。
因为该类非常大，所以每次您想通过引入新方法来对其进行扩展时，您都会面临一个事实，那就是使该类变得更糟—更长，更缺乏凝聚力，可读性更差，更难以维护，等等。感觉到您正在挖掘肮脏的东西，没有希望使其变得更清洁。 我敢肯定，您对这种感觉很熟悉-大多数旧版应用程序都是这样的。 它们具有巨大的多行“类”（实际上是用Java编写的COBOL程序），这些类是从您之前的几代程序员那里继承而来的。 开始时，您精力充沛，但是在滚动了这样的“课堂”几分钟后，您会说-“拧紧，几乎是星期六了”。
由于该类非常大，因此不再有数据隐藏或封装-可以通过100多种方法访问33个变量。 隐藏了什么？ 实际上，此Email.java文件是一个大型的程序化2000行脚本，被误称为“类”。 一旦通过调用类的方法之一跨越了类的边界，任何东西都不会被隐藏。 之后，您就可以完全访问可能需要的所有数据。 为什么这样不好？ 那么，为什么我们首先需要封装？ 为了保护一个程序员免受另一种程序员的攻击，又称为防御性编程 。 当我忙于更改MIME消息的主题时，我想确保自己不会被其他方法的活动所干扰，即正在更改发件人并误触了我的主题。 封装可帮助我们缩小问题的范围，而此Email类的作用恰恰相反。
由于类太大，因此其单元测试比类本身还要复杂。 为什么？ 由于其方法和属性之间存在多个相互依赖关系。 为了测试setCharset()您必须通过调用其他一些方法来准备整个对象，然后必须调用send()以确保要发送的消息实际上使用了您指定的编码。 因此，为了测试单行方法setCharset()您运行了整个集成测试方案，即通过SMTP发送完整的MIME消息。 显然，如果其中一种方法发生更改，几乎每种测试方法都会受到影响。 换句话说，测试非常脆弱，不可靠且过于复杂。
我可以继续讲这个“因为班级太多了”，但是很明显，一个小的，具有凝聚力的班级总是比大班级更好。 对于我，您和任何面向对象的程序员而言，这都是显而易见的。 但是，为什么对于Apache Commons Email的开发人员来说并不那么明显？ 我不认为他们是愚蠢或没有受过教育的人。 之后怎么样了？
它是如何发生的以及为什么发生的？
这就是它总是发生的方式。 您开始将一门课程设计为具有凝聚力，坚实和小巧的东西。 您的意图非常积极。 很快，您意识到该类还有其他事情要做。 然后，还有其他事情。 然后，甚至更多。
使您的类越来越强大的最好方法是添加将设置参数注入到类中的setter，以便它可以在内部处理它们，不是吗？
这是问题的根本原因！ 根本原因是我们能够通过配置方法（也称为“设置程序”）将数据插入可变对象中。 当一个对象是可变的，并允许我们在需要时添加setter时，我们将无限制地进行操作。
让我这样说吧–可变的类倾向于增加规模并失去凝聚力。
如果commons-email作者在开始时就将此Email类设为不可变的，那么他们将无法向其中添加太多方法并封装太多属性。 他们将无法将其变成怪物。 为什么？ 因为不可变对象仅通过构造函数接受状态。 您能想象一个33参数的构造函数吗？ 当然不是。
首先，当您使类不可变时，您必须保持其凝聚力，小巧，牢固和强大。 因为不能封装太多，也不能修改封装的内容。 只需一个构造函数的两个或三个参数就可以了。
我如何设计不可变的电子邮件？
在设计jcabi-email时，我从一个小而简单的类开始：Postman。 好吧，这是一个接口，因为我从来没有做无接口类。 因此，Postman是……Postman。 他正在向其他人传递消息。 首先，我创建了它的默认版本（为简洁起见，我省略了ctor）：
import javax.mail.Message;@Immutableclass Postman.Default implements Postman {private final String host;private final int port;private final String user;private final String password;@Overridevoid send(Message msg) {// create SMTP session// create transport// transport.connect(this.host, this.port, etc.)// transport.send(msg)// transport.close();}}
良好的开端，它有效。 现在怎么办？ 好吧，Message很难构造。 它是JDK中的一个复杂类，需要进行一些操作才能成为HTML电子邮件。 因此，我创建了一个信封，它将为我构建这个复杂的对象（请注意，Postman和Envelope都是不可变的，并在jcabi-aspects中使用@Immutable进行了注释）：
@Immutableinterface Envelope {Message unwrap();}
我还重构Postman以接受信封，而不是消息：
@Immutableinterface Postman {void send(Envelope env);}
到目前为止，一切都很好。 现在，让我们尝试创建一个简单的Envelope实现：
@Immutableclass MIME implements Envelope {@Overridepublic Message unwrap() {return new MimeMessage(Session.getDefaultInstance(new Properties()));}}
它可以工作，但是没有任何用处。 它只会创建一个绝对为空的MIME消息并返回。 如何为其添加一个主题以及“To:和“From:地址（请注意，MIME类也是不可变的）：
@Immutableclass Envelope.MIME implements Envelope {private final String subject;private final String from;private final Array<String> to;public MIME(String subj, String sender, Iterable<String> rcpts) {this.subject = subj;this.from = sender;this.to = new Array<String>(rcpts);}@Overridepublic Message unwrap() {Message msg = new MimeMessage(Session.getDefaultInstance(new Properties()));msg.setSubject(this.subject);msg.setFrom(new InternetAddress(this.from));for (String email : this.to) {msg.setRecipient(Message.RecipientType.TO,new InternetAddress(email));}return msg;}}
看起来正确且有效。 但这仍然太原始了。CC:和BCC:如何？ 电子邮件文字呢？ PDF附件怎么样？ 如果我想指定消息的编码怎么办？ 那Reply-To呢？
我可以将所有这些参数添加到构造函数中吗？ 请记住，该类是不可变的，因此我无法介绍setReplyTo()方法。 我必须将replyTo参数传递给它的构造函数。 这是不可能的，因为构造函数将有太多的参数，并且没有人可以使用它。
那么，我该怎么办？
好吧，我开始思考：我们如何将“信封”的概念分解为较小的概念，而这正是我所发明的。 就像现实的信封一样，我的MIME对象将带有图章。Stamp将负责配置对象Message（同样，Stamp及其所有实现者都是不可变的）：
@Immutableinterface Stamp {void attach(Message message);}
现在，我可以将我的MIME类简化为以下内容：
@Immutableclass Envelope.MIME implements Envelope {private final Array<Stamp> stamps;public MIME(Iterable<Stamp> stmps) {this.stamps = new Array<Stamp>(stmps);}@Overridepublic Message unwrap() {Message msg = new MimeMessage(Session.getDefaultInstance(new Properties()));for (Stamp stamp : this.stamps) {stamp.attach(msg);}return msg;}}
现在，我将为该主题创建图章，例如To:，From:，CC:，BCC:等等。MIME类将保持不变-小，内聚，可读，固定等。
这里重要的是为什么我决定在班级相对较小的时候决定进行重构。 确实，当我的MIME类只有25行时，我开始担心这些标记类。
这正是本文的重点-不变性迫使您设计小型且具有凝聚力的对象。
没有不变性，我本来会和commons-email往同一方向发展。 我的MIME类的大小会增加，迟早会变得与commons-email中的Email一样大。 阻止我的唯一原因是必须对其进行重构，因为我无法通过构造函数传递所有参数。
没有不变性，我就不会有那种动力，我会做Apache开发人员使用commons-email所做的事情—使类膨胀，并将其变成无法维护的怪物。
那是jcabi-email 。 我希望这个例子足以说明问题，并且您将开始使用不可变的对象编写更简洁的代码。
相关文章
您可能还会发现以下有趣的帖子：
配对支架 避免字符串串联 Java代码中的典型错误 DI容器是代码污染者 吸气剂/设定者。 邪恶。 期。
翻译自: //11/how-immutability-helps.html
