目前我注意到裸露对象在博客中越来越受欢迎。每次我都想知道为什么（很多人）觉得它如此引人入胜 - 我经常想写一篇关于裸露对象优缺点的博客；但始终没有找到时间。
我仍然没有时间详细写关于它的博客，但只是陈述一些关于裸露对象实现的事实和/或批评，这些我之前没有看到被列出。
A. 所有对象都必须实现NakedObject或扩展AbstractNakedObject（实际上框架中的某些代码假设每个对象都是AbstractNakedObject...但我猜他们会在某个时候修复这个）。
B. 所有希望框架知道的字段都需要是NakedValue，因此String必须是TextString，float是FloatingPointNumber等。这一切基本上都是为了使值可变，并为它们的自动GUI添加所有语言需求（所有这些都非常容易批评，所以我不说了）。
C. 所有关联对象的集合都需要是NakedCollection，这绝对不是任何意义上的java.util.Collection（因为它们也不使用jdk 1.2中的任何内容，只是为了能够在.NET上运行！
）。
A、B和C中的每一个都让我不喜欢裸露对象框架（至少是它的实现）！为什么？因为我的对象不再会是POJO了 - 尤其是C项，使得使用Hibernate（或许多其他基于反射的ORM）来持久化这些非裸露对象变得非常困难。至少需要一些非常特定的裸露对象代码才能使其工作。
当我们谈论持久化时，整个框架确实有一个内置的持久化引擎，它是可插拔
的 - 但它非常简单，事务边界看起来很难控制，如果目前有可能的话。
但批评到此为止；（），好的东西是它们关于行为完整的对象（BCO）的想法。从书中：一个对象应该完全模拟它所代表的实体的行为。 ...大多数人继续设计将过程与数据分开的业务系统，尽管它们用面向对象的语言和技术包装起来。
我确实同意这个观点——人们有时会变得过于程序化，包括我自己，如果裸对象（Naked Objects）能让我们在这方面做得少一点，我会非常感激。
他们的自动（他们称之为“赋予用户权力”）的用户界面（UI）有些有趣——但是，哎呀，他们真的应该更深入地研究UI设计；（是的，我知道他们确实考虑过UI设计来赋予用户权力，但我觉得他们的UI除了具有挑衅性和与众不同之外，在其他领域并没有价值；）
根据我理解作者的说法，他们的重点是BCO和自动创建的UI，但我不明白为什么他们没有利用现有的技术，这些技术几乎可以做同样的事情……比如JavaBeans API？JavaBeans不仅仅是属性的命名标准！它是为了允许IDE检查对象并构建智能UI而构建的！
它有一个内省API，可以用来发现对象的全部细节，API的扩展方式比裸对象更少侵入性。
关于使用标准的属性监听器呢？为什么限制自己只使用JDK 1.1？谁只想使用Vector，为什么不利用Collections API接口使他们的对象结构更符合标准规范呢？
最后，我鼓励作者们专注于他们的核心概念：BCO和自动UI（即使我不认为它将覆盖超过几个有用的应用）。但他们真的应该考虑使用更多的JDK API，这样框架在现实生活中的应用中就会更有用。
附言：为什么他们的系统源代码中有多个捕获所有异常的块和printStackTrace()？这样的系统是用于原型系统之外的。
