不变性和可读性
因此，我一直在阅读 Joshua Bloch 的《Effective Java》，并注意到我在工作中实际遇到的两点。
第 1 点：制作 setter 方法以使代码更具可读性。 在他的例子中，我们有一个类，它有一个巨大的构造函数。当人们实例化该类时，很难判断所有参数发生了什么。因此，他建议创建一个简约的构造函数，并为所有其他选项提供 setter 方法，所以不要......
MyClass clazz = new MyClass(a, b, c, d、e、f、g)；
你会写....
MyClass clazz = new MyClass(a, b, c);
clazz.setDitto(d);
clazz.setEcho(e);
clazz.setFunzies(f);
clazz.setGumballs(g);
作为可读代码的巨大支持者，我非常喜欢它。
第 2 点：总的来说，他建议使用不可变的类。他深入探讨了为什么拥有不可变的类比拥有可能处于多个不同状态的类要好得多。我可以肯定地说，他把这个想法卖给了我，我迫不及待地想让我从现在开始编写的大多数类都是不可变的，除了……
当你有一个带有巨大构造函数的不可变类时会发生什么？你不能为它创建 setter 方法；这会破坏不变性。我尝试浏览本书的其余部分，但我认为他没有提供解决方案。
一次性使用 setter 方法是有可能的，但事实上，setter 方法可用于被认为是不变性的类，这一事实令人沮丧，即使如果您随后尝试它，它只会抛出异常。
有人对如何处理这个问题有什么好主意吗？我目前在工作中面临这个问题，我有一个带有巨大构造函数的 Immutable 类，我想将其重构为更具可读性而不破坏不变性的东西。
So I've been reading Effective Java by Joshua Bloch and noticed two points which I actually have encountered in my work.
Point 1: Making setter methods to make code more readable.
In his example, we have a class with a ridiculously huge constructor. When people instantiate the class, it's hard to tell what's going on with all the parameters. Thus, he suggested making a minimalistic constructor and have setter methods for all other options, so instead of...
MyClass clazz = new MyClass(a, b, c,
d, e, f, g);
you would write....
MyClass clazz = new MyClass(a, b,
c);
clazz.setDitto(d);
clazz.setEcho(e);
clazz.setFunzies(f);
clazz.setGumballs(g);
Which, as a huge supporter of readable code, I liked a lot.
Point 2: In general, he suggested having immutable classes. He goes into great depth on why having immutable classes is much better than having a class that could be in several different states. I can definitely say that he sold the idea to me, and I can't wait to make most classes I write from now on immutable, except....
What happens when you have an immutable class with a huge constructor? You can't make setter methods for it; that would break immutability. I tried skimming through the rest of the book, but I don't think he covers a solution for this.
There is the possibility of making one-time use setter methods, but just the fact that a setter method is available to a class that is supposedly immutability is disheartening, even if it does just throw an Exception if you try it subsequent times.
Does anyone have any good ideas on how to handle this problem? I'm currently facing this issue at work where I have an Immutable class with a huge constructor which I'd like to refactor to something that's more readable without breaking immutability.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一种选择是提供一个单独的构建器类，该构建器类提供 setter，负责构造实际对象。
在 Bloch 的“Effective Java”第二版中，第 2 项针对不可变类说明了这一点。关键思想是：
One option is to provide a separate builder class that provides the setters, which is responsible for constructing the actual object.
In the second edition of Bloch's "Effective Java", item 2 illustrates this for an immutable class. The key ideas are:
引入参数对象，也许吧？它某种程度上解决了问题，但也许是以有用的方式。您的参数对象不需要任何方法；它只是保存数据，然后你设置它，而不是你真正的类。然后你的真实类通过参数对象在构造函数中初始化自身。
Introduce Parameter Object, maybe? It kind of moves the problem around, but maybe in useful ways. Your parameter object needs no methods; it just holds the data, and you set it up, instead of your real class. Then your real class initializes itself in the constructor via the parameter object.
您可以使用流畅的界面： 构建大型、不可变的对象不使用具有长参数列表的构造函数
另请参阅：
构造函数参数 - 规则拇指
将一个请求对象作为Method Signature参数，构成所有必需参数
You can go with fluent interfaces: Building big, immutable objects without using constructors having long parameter lists
See also:
Constructor Parameters - Rule of Thumb
Having one request object as a Method Signature parameter, which constitute all the required parameters
拥有一个支持 getter 但不支持该类所有属性的 setter 的抽象基类、一个其构造函数接受基类对象的派生密封“不可变”类以及一个包含所有属性的 setter 的派生可变类怎么样？
How about having an abstract base class which supports getters but no setters for all the attributes of the class, a derived sealed "immutable" class whose constructor accepts a base-class object, and a derived mutable class which includes setters for all the properties?