不变性如何提供帮助

在最近的几篇文章中，包括“ Getters / Setters。邪恶。期。” ， “对象应该是不可变的”和“依赖注入容器是代码污染者” ，我普遍将所有可变对象标记为“ setter”（以set开头的对象方法）。我的论证主要基于隐喻和抽象实例。显然，这对你们中的许多人来说还不够令人信服-我收到了一些要求提供更具体和实际示例的请求。

因此，为了说明我对“通过setter进行可变性”的强烈否定态度，我从Apache那里获取了一个现有的commons-email Java库，并以不使用setter和“对象思考”的方式重新设计了它。我作为jcabi家族的一部分— jcabi-email发布了我的库。让我们看看从没有吸气剂的“纯”面向对象，不变的方法中获得的好处。

如果您使用commons-email发送电子邮件，则代码如下所示：

Email email = new SimpleEmail();
email.setHostName("smtp.googlemail.com");
email.setSmtpPort(465);
email.setAuthenticator(new DefaultAuthenticator("user", "pwd"));
email.setFrom("yegor@teamed.io", "Yegor Bugayenko");
email.addTo("dude@jcabi.com");
email.setSubject("how are you?");
email.setMsg("Dude, how are you?");
email.send();

这是使用jcabi-email的相同方法：

Postman postman = new Postman.Default(new SMTP("smtp.googlemail.com", 465, "user", "pwd")
);
Envelope envelope = new Envelope.MIME(new Array<Stamp>(new StSender("Yegor Bugayenko <yegor@teamed.io>"),new StRecipient("dude@jcabi.com"),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;
@Immutable
class 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进行了注释）：

@Immutable
interface Envelope {Message unwrap();
}

我还重构Postman以接受信封，而不是消息：

@Immutable
interface Postman {void send(Envelope env);
}

到目前为止，一切都很好。现在，让我们尝试创建一个简单的Envelope实现：

@Immutable
class MIME implements Envelope {@Overridepublic Message unwrap() {return new MimeMessage(Session.getDefaultInstance(new Properties()));}
}

它可以工作，但是没有任何用处。它只会创建一个绝对为空的MIME消息并返回。如何为其添加一个主题以及“ To:和“ From:地址（请注意， MIME类也是不可变的）：

@Immutable
class 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及其所有实现者都是不可变的）：

@Immutable
interface Stamp {void attach(Message message);
}

现在，我可以将我的MIME类简化为以下内容：

@Immutable
class 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 。我希望这个例子足以说明问题，并且您将开始使用不可变的对象编写更简洁的代码。

您可能还会发现以下有趣的帖子：