What is the advantage of POJO?

Question

In my project, I have a small Key data structure.

 public class Key implements Serializable { private static final long serialVersionUID = 1L; public String db; public String ref; public Object id; protected Key() { } public Key(String db, String ref, Object id) { this.db = db; this.ref = ref; this.id = id; } } 

Yes, this class is simple, and each field is openly accessible.

But someone suggested using POJO style classes, but when I asked why they couldn’t tell me.

In my opinion, calling getters and setters is slower than direct access to the field.

So why should I use the POJO programming style?

Answer 1

Taken from Wikipedia:

POJO is an acronym for a regular Java object. The name is used to emphasize that this object is a regular Java object, not a special object.

POJO is usually simple, so it will not depend on other libraries, interfaces, or annotations. This increases the likelihood that it can be reused in several types of projects (web, desktop, console, etc.).

As noted in the comments, your object is technically a POJO, but you specifically asked about getters and setters that are more like JavaBeans.

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

2. You may only need to get some of the values ​​(IE read-only values). With fields, clients can receive and set values ​​directly. Fields can be made read-only if they are marked as final, although this does not always guarantee that they are immutable (see Clause 9).
3. The Getter and setter methods allow you to change the underlying data type without violating the general interface of your class, which makes it (and your application) more reliable and resistant to changes.
4. You might want to call another code, for example, raising a notification when a value is received or changed. This is not possible in your current class.
5. You reveal the implementation of your class, which may be a security risk in some cases.
6. Java beans are designed around POJO, which means that if your class is not implemented as one, it cannot be used by some tools and libraries that expect your class to adhere to these well-established principles.
7. You can set values ​​not supported by the IE calculated field, such as getFullName() , which is a concatenation of getFirstName() and getLastName() , which are supported by the fields.
8. You can add validation to your setter methods to ensure that the values ​​passed are correct. This ensures that your class is always in valid condition.
9. You can set a breakpoint in your receivers and setters so that you can debug your code when values ​​are received or changed.
10. If the field is an object (IE is not a primitive type), then the internal state of your class can be changed by other objects, which can lead to errors or security risks. You can protect this script from your POJO recipient by returning a copy of the object so that clients can work with the data without affecting the state of your object. Please note: the presence of a final field does not always protect you from such attacks, since clients can still make changes to the object referenced (provided that this object itself has been changed), you simply cannot specify a field with a different link after installing it.

Yes, accessing or setting values ​​through method calls may be slower than direct access to the field, but the difference is barely noticeable, and this, of course, will not be a bottleneck in your program.

Although the benefits are obvious, this does not mean that getters and setters are a silver bullet. There are a number of “errors” to consider when designing the real world, reliable scalable classes.

This answer to a very similar question details some considerations when designing a class that has getters and setters. Although the sentences may be more relevant depending on the type of class you are developing an EG class that is part of the API in a large system, rather than a simple data transfer object.

Also note that there may be certain scenarios in which a direct-field class can be useful, for example, when speed is important or memory is limited, although this should be considered only after profiling your code and determining that this is actually a bottleneck .

Also be careful that you do not just wrap all of your fields in getters and setters, as this really lacks an encapsulation point.

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

Answer 2

Use private class variables and public getters and setters that will provide you with encapsulation.

Answer 3

Getters and seters, especially the simplest forms, will simply be embedded by the JIT compiler, and thus, the method call overhead will be deleted. This is very similar to premature optimization. If you ever get a bottleneck, then profile and see where this happens. I am sure that this will not be access to resources.

Answer 4

Get yourself the book Effective Java.

• Clause 14, in public classes, uses access methods rather than public fields.

This Joshua Bloch says that there is nothing abnormal in public fields in package-private or nested classes, but he strongly advises using public classes.

He describes this topic in detail, this is a great book offering you a copy.

Answer 5

Imagine some other programmer using your code. If you do not provide the setter and getter methods, it can directly call your variable, and this will certainly affect your code. And that can lead to security issues. Thus, by providing a POJO class, you force it to access your methods, and not directly access your instance variables.