What's the Advantage of Pojo

What's the advantage of POJO?

Taken from Wikipedia:

POJO is an acronym for Plain Old Java Object. The name is used to
emphasize that a given object is an ordinary Java Object, not a
special object.

A POJO is usually simple so won't depend on other libraries, interfaces or annotations. This increases the chance that this can be reused in multiple project types (web, desktop, console etc).

As someone has already pointed out in the comments, your object is technically a POJO already however you have specifically asked about getters and setters which are more akin to JavaBeans.

There are a number of reasons I can think of for using getters and setters:

2. You might only want to get some of the values (I.E. read only values). With fields, clients can both get and set the values directly. Fields can be made read-only if they are marked as final although this doesn't always guarantee that they are immutable (see point 9).
3. Getter & setter methods allow you to change the underlying data type without breaking the public interface of your class which makes it (and your application) more robust and resilient to changes.
4. You might want to call some other code such as raising a notification when the value is obtained or changed. This is not possible with your current class.
5. You are exposing the implementation of your class which could be a security risk in some cases.
6. Java beans are designed around POJO's which means that if your class is not implemented as one it can't be used by certain tools and libraries that expect your class to adhere to these well established principles.
7. You can expose values that are not backed by a field I.E. calculated values such as getFullName() which is a concatenation of getFirstName() and getLastName() which are backed by fields.
8. You can add validation to your setter methods to ensure that the values being passed are correct. This ensures that your class is always in a valid state.
9. You can set a breakpoint in your getters and setters so that you can debug your code when the values are obtained or changed.
10. If the field is an object (I.E. not a primitive type) then the internal state of your class can be modified by other objects which can lead to bugs or security risks. You can protect against this scenario in your POJO's getter by returning a copy of the object so that clients can work with the data without affecting the state of your object. Note that having a final field does not always protect you against this sort of attack as clients can still make changes to the object being referenced (providing that object is itself mutable) you just cannot point the field at a different reference once it has been set.

Yes, accessing or setting the values via method calls may be slower than direct field access but the difference is barely noticeable and it certainly won't be the bottleneck in your program.

Whilst the advantages are clear this does not mean that getters and setters are a silver bullet. There are a number of 'gotchas' to consider when designing real world, robust scalable classes.

This answer to a very similar question looks at some considerations in detail when designing a class that has getters and setters. Although the suggestions may be more relevant depending on the type of class you are designing E.G. a class that forms part of an API in a large system as opposed to a simple data transfer object.

Also note that there may be certain scenarios where a class with direct field may be advantageous such as when speed is essential or memory is limited although this should only be considered after profiling your code and finding that it is actually a bottleneck.

Also be careful that you are not just wrapping all of your fields in getters and setters as this is really missing the point of encapsulation.

This answer provides a good summary of the reasons for choosing a POJO over a JavaBean style object with getters and setters.

Java Spring: benefits of POJO objects

In the good old days when application servers only supported EJB 2 it was a nightmare to develop services using EJBs. Each service (e.g. a stateless session bean) required a bunch of interfaces and strange additional methods to work properly (home interface, remote interface, deployment descriptors etc).

In order to run EJBs you need an application server such as Jboss or Glassfish. In order to run servlets you simply need a servlet container such as Tomcat or Jetty which is way more lightweight than an application server.

Spring offers a way of creating simple services as plain POJOs (that can be exposed via servlets). Therefore, to be able to develop services as a POJO was simply a dream come true. Services did not need all the constraining dependencies to the EJB-interfaces and they could be deployed in a lightweight servlet container.

Then came EJB3 which greatly improved life for the Java EE developer. EJBs no longer needed the dependencies for home- and remote-interfaces (at least not via inheritence). A modern EJB 3 service is very similar to a POJO-based service. The main difference is that EJBs still require an application server to be deployed.

Spring Guru Rod Johnson released the book J2EE Development without EJBs which greatly explains how to replace your old J2EE components (such as EJBs) with more lightweight Spring Pojos - good reading!

Shall I use POJO or JSONObject for REST calls

I see the following advantages in having pojos

1) Readability - You will not really know the structure of a complex json. writing a simple get will require one to know the structure of the json. Please refer to the "POJOs over JSON Objects" section of my article here -> https://medium.com/tech-tablet/programming-went-wrong-oops-38d83058885

2) Offers Type Checks - We could easily assign a Cat to a Dog and not even know about it till runtime.

3) Feels more object-oriented with Composition & encapsulation - It's easy to understand the designer's perspective with a POJO. A Car which IS-A Vehicle that HAS-A Wheel.

4) You could choose what you wanna deserialize and keep only that in memory - When deserializing the object that we have just received over the network, with a JSON Object, there is no way to choose what has to be deserialized and stored into memory. If you have an object of 1 MB size where only 200 Bytes is your payload, we will end up holding the entire 1 MB object in memory if we don't use POJOs.

5) Allows collection to be used and stream operations on them in a legible way - There is no native support for stream operations in a JsonNode. We will need to use a StreamStupport object which could be avoided.

6) Allows cross framework referencing. With a few annotations, you can choose to map specific fields to a database client - When you use an ORM framework for you database, it's easy to annotate and map entities to the database schema.

7) Naturally supports design patterns

8) Minimalizing non-native dependencies - Why do you have to use a JsonNode or equivalent that does not come by itself in native Java? Especially if it has the above disadvantages.

If you are concerned about the rituals that come with a pojo like having getters, setters etc, take a look at "Lombok". This library will help you create your pojos in a concise way and still reap the above benefits.

On the other hand if you are are dealing with a hard to change legacy API that responds with a dynamically changing response, JsonNode is a quick win candidate.

Why should I use a POJO class in hibernate or spring?

Hibernate is basically used for mapping between Java application and database. Whatever is your pojo class name there will be table with the same name in database. Pojo's entity will be represented as column in database. Hibernate will do all these mappings using annotations. You have to use annotations in POJO to tell this class is hibernate entity so map this to db table with the same name or you can give name in annotation. there are many other hibernate annotations you can use e.g for Primary key, For one to many ,one to one relationships and many more. Please go through this link.

---

Related Topics