Java Beans
JavaBeans are reusable software components for Java that can be manipulated visually in a
builder tool. Practically, they are classes written in the Java programming language
conforming to a particular convention. They are used to encapsulate many objects into a
single object (the bean), so that they can be passed around as a single bean object instead
of as multiple individual objects. A JavaBean is a Java Object that is serializable, has a
nullary constructor, and allows access to properties using getter and setter methods.
In order to function as a JavaBean class, an object class must obey certain conventions
about method naming, construction, and behavior. These conventions make it possible to have tools that can use, reuse, replace, and connect JavaBeans.
The required conventions are:
•The class must have a public default constructor. This allows easy instantiation within
editing and activation frameworks.
•The class properties must be accessible using get, set, and other methods (so-called
accessor methods and mutator methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties.
•The class should be serializable. This allows applications and frameworks to reliably save,
store, and restore the bean’s state in a fashion that is independent of the VM and platform.
Because these requirements are largely expressed as conventions rather than by implementing
interfaces, some developers view JavaBeans as Plain Old Java Objects that follow specific
naming conventions.
POJO
POJO is an acronym for Plain Old Java Object. The name is used to emphasize that the object
in question is an ordinary Java Object, not a special object, and in particular not an
Enterprise JavaBean (especially before EJB 3). The term was coined by Martin Fowler, Rebecca
Parsons and Josh MacKenzie in September 2000:
“We wondered why people were so against using regular objects in their systems and concluded
that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught
on very nicely.”
The term continues the pattern of older terms for technologies that do not use fancy new
features, such as POTS (Plain Old Telephone Service) in telephony, and PODS (Plain Old Data
Structures) that are defined in C++ but use only C language features, and POD (Plain Old
Documentation) in Perl.
The term has most likely gained widespread acceptance because of the need for a common and
easily understood term that contrasts with complicated object frameworks. A JavaBean is a
POJO that is serializable, has a no-argument constructor, and allows access to properties
using getter and setter methods. An Enterprise JavaBean is not a single class but an entire
component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans).
As designs using POJOs have become more commonly-used, systems have arisen that give POJOs
some of the functionality used in frameworks and more choice about which areas of
functionality are actually needed. Hibernate and Spring are examples.
Value Object
In P of EAA I described Value Object as a small object such as a Money or date range object.
Their key property is that they follow value semantics rather than reference semantics.
You can usually tell them because their notion of equality isn’t based on identity, instead
two value objects are equal if all their fields are equal. Although all fields are equal,
you don’t need to compare all fields if a subset is unique – for example currency codes for
currency objects are enough to test equality.
A general heuristic is that value objects should be entirely immutable. If you want to
change a value object you should replace the object with a new one and not be allowed to
update the values of the value object itself – updatable value objects lead to aliasing
problems.
Early J2EE literature used the term value object to describe a different notion, what I call
a Data Transfer Object. They have since changed their usage and use the term Transfer Object
instead.
Data Transfer Object
Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used
to transfer data between software application subsystems. DTOs are often used in conjunction
with data access objects to retrieve data from a database.
The difference between data transfer objects and business objects or data access objects is
that a DTO does not have any behaviour except for storage and retrieval of its own data
(accessors and mutators).
In a traditional EJB architecture, DTOs serve dual purposes: first, they work around the
problem that entity beans are not serializable; second, they implicitly define an assembly
phase where all data to be used by the view is fetched and marshalled into the DTOs before
returning control to the presentation tier
Bean, Pojo, VO and DTO: idiotjava.com/difference-bet…
— IdiotJava (@IdiotJava) March 8, 2012