Fake Objects: objects in appearance, but which don’t exhibit some of the characteristics of objects: identity, state, and behavior。
Let’s look at some common fake objects and why to avoid them if possible:
❑ Transfer objects, often referred to as Data Transfer Objects (DTOs) or Value Objects. Transfer
objects are not true objects because they contain only state, without behavior. Transfer objects
are a necessary evil in distributed applications (although there’s an argument that this kind of
data should really be included in an XML structure rather than Java objects). But if we don’t
want a distributed architecture, they’re redundant and harmful, creating an unwelcome
impedance mismatch between business services and callers.
❑ Entity beans or other persistent objects generated from RDBMS tables. These reflect a relational,
rather than OO, model. They have a harmful effect on code that works with them, which
is forced to navigate relationships and cannot benefit from OO concepts such as polymorphism.
There’s also inadequate decoupling between business logic and persistent data representation.
❑ Persistent objects in general that contain only getters and setters, without behavior. Such fake
objects force behavior that they should encapsulate to be moved into control classes such as session
beans. Not only is encapsulation violated, but the result tends to be verbose code in control