包含java.util.Properties，sql.Date，util.Date等的不可修改扩展的库

Question

首先让我说，我相信不变性是人们可以做的最好的事情之一，可以提高可靠性，简单性和对系统的信心。不再担心防御性副本或价值观的变化等等，这对我来说是一件好事。

尽管如此简单，Collections库的unmodifiableXXX方法是一种简单的方式来呈现只读集合，这是一件好事并保证安全。它并不能解决宇宙中的所有问题，但它是一件好事。

毕竟我正在寻找一个试图解决其他一些瑕疵的图书馆。

只读属性

• r / o将包装另一个属性
• 扩展java.util.Properties
• mutator方法抛出UOE。
• keySet / valueSet视图等也应该是只读的

可变属性

• 地图（例如put）方法抛出UOE
• 只有像setProperty这样的正确属性方法才能正常工作。
• 扩展java.util.Properties

对于Stack也重复属性的练习。重复练习java.util.Date，java.sql.Date等。

请不要告诉我自己写，因为我可以，但我希望这些无聊的东西已经完成了：）

Answer 1

我不认为这样的图书馆存在。

但是，我不会告诉你自己编写，因为我认为这会浪费时间：

• 对于java.util.Date案例，请使用基本日期/时间对象不可变的Joda时间API。

• 对于不可变的Properties情况，请将Properties对象包装在不可修改的Map中。

• 对于可变Properties案例，请使用HashMap<String, String>代替Properties。

• 由于返回 java.sql.Date实例的JDBC方法，java.sql.Date案例无法解决。

---

考虑一下。数百万Java程序员已经多年来没有拥有这些util类的只读版本。显然没有人认为创建/发布这样的图书馆是值得的。这会告诉你什么吗？也许，这不是一个真正的问题？或者说有更好的解决方案（比如Joda时间）。

例如，当我编写一个将Properties对象传递给某个方法的方法时，我会看一下该方法的API。它是否暗示或暗示它修改/可能修改对象？我关心的？除非答案对这两者都是“肯定”，否则我不需要来制作防御性副本。如果两者的答案都是“是”，那么我确实需要制作防御性副本......并且不可变对象不是答案。

现在，如果从今天开始重新设计Java，那么处理可变对象和不可变对象的更好方法将在 my 议程中占据优势。但事实并非如此。

但是，嘿，你可以自由地反对我并实施你自己的图书馆。

Answer 2

当然，你总是可以在一个对象上调用clone。

但是，如果您确实需要只读属性，那么在使用像NetBeans这样的IDE时，扩展对象非常容易。我可以在10分钟内完成。迭代器和所有。如果您不使用IDE，我建议您学习NetBeans或Eclipse，它们是最常见的两种。我使用NetBeans。

如果你使用Eclipse，我唯一不知道的是你是否可以在Eclipse中创建委托方法。

以下是NetBeans的说明。

1. 创建一个类并扩展属性。创建一个名为private final Properties backend;
的私有变量
2. 制作构造函数public MyProperties(Properties backend){this.backend=backend;}
3. 将光标移动到构造函数后面的右侧，然后键入 Alt + Insert 。选择背景作为您委派的内容并检查所有方法并继续。
4. 对于您不想使用的方法，只需粘贴throw new UnsupportedOperationException("unmodifiable Properties");
即可
5. keySet和valueSet只需要返回它们现在返回的不可修改的包装器（从步骤4开始）。