显然，这种设计把持久功能放在PersistentObject 基接口中，并且要求想要拥有持久状态的对象继承PersistentObject。表面上，这是合理的：毕竟，这样使用继承是一种沿用已久的设计模式，那么，它可能有什么问题？我们发现，这种设计有这样一些问题：
• 上面的继承层次用来给 Thing1 和Thing2 增加行为。但在严格的OO 模型中，行为只能通过发送消息来调用。这引发了这样一个问题：PersistentObject 实际上该怎样着手完成它的工作；推测起来，它对Thing1 and Thing2 的实现（也就是，内部状态）有所了解，所以它可以把该状态写入数据库。但如果是这样， PersistentObject、Thing1，以及Thing2 就不能再在不同的地址空间中实现了，因为如果是那样， PersistentObject 就不再能知道Thing1 和Thing2 的状态。
换一种做法， Thing1 和Thing2 可以使用PersistentObject 提供的某种功能， 使它们的内部状态持久。但PersistentObject 没有任何操作，那么Thing1 和Thing2 实际上又该怎样去完成这件事情呢？再一次，唯一可行的做法是，在同一个地址空间中实现PersistentObject、Thing1，以及Thing2，并让它们在幕后共享实现状态，也就是说，它们不能在不同的地址空间中实现。
• 上面的继承层次把世界分成两半，一个含有持久对象，另一个含有非持久对象。这种做法有着深远的影响：