When we talk about a POJO, what we’re describing is a straightforward type with no references to any particular frameworks. A POJO has no naming convention for our properties and methods.
Below are some properties of the POJO class:
The POJO class must be public.
It must have a public default constructor.
It may have the arguments constructor.
All objects must have some public Getters and Setters to access the object values by other Java Programs.
The object in the POJO Class can have any access modifies such as private, public, protected. - But, all instance variables should be private for improved security of the project. A POJO class should not extend predefined classes.
It should not implement prespecified interfaces.
It should not have any prespecified annotation.
But, we aren’t following any real convention for constructing, accessing, or modifying the class’s state. This lack of convention causes two problems: First, it increases the learning curve for coders trying to understand how to use it. Second, it may limit a framework’s ability to favor convention over configuration, understand how to use the class, and augment its functionality. To explore this second point, let’s work with EmployeePojo using reflection. Thus, we’ll start to find some of its limitations.
A JavaBe
an is still a POJO but introduces a strict set of rules around how we implement it:
Access levels – our properties are private and we expose getters and setters
Method names – our getters and setters follow the getX and setX convention (in the case of a boolean, isX can be used for a getter)
Default Constructor – a no-argument constructor must be present so an instance can be created without providing arguments, for example during deserialization
Serializable – implementing the Serializable interface allows us to store the state
京公网安备 11010802041100号