Skip to main content

Plain Old Java Object (POJO) Explained

Plain Old Java Object or POJO is just an ordinary Java object, The term was originally coined by Martin Fowler, Rebecca Parsons, and Josh Mackenzie in September 2000.

According to Martin Fowler

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. 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.

Generally, a POJO is not bound to any restriction and any Java object can be called a POJO but there are some directions. A well-defined POJO should follow below directions.
  1. Each variable in a POJO should be declared as private.
    2.     private long id;
        private String value = "";
        private Collection<Term> children = Collections.emptyList();

  2. Default constructor should be overridden with public accessibility.
    3.     public Term() {
        }

  3. Each variable should have its Setter-Getter method with public accessibility.
    4.     public long getId() {
            return id;
        }

        public void setId(long id) {
            this.id = id;
        }

        public String getValue() {
            return value;
        }

        public void setValue(String value) {
            this.value = value;
        }

        public Collection<Term> getChildren() {
            return children;
        }

        public void setChildren(Collection<Term> children) {
            this.children = children;
        }
  4. Generally POJO should override equals(), hashCode() and toString() methods of Object (but it's not mandatory).

    5. Overriding these methods will help us while using our POJO with different Java collection classes or writing it directly to console or inspecting it in debugger.

        @Override
        public int hashCode() {
            final int prime = 31;
            int result = 1;
            result = prime * result + ((value == null) ? 0 : value.hashCode());
            result = prime * result + ((children == null) ? 0 : children.hashCode());
            return result;
        }

        @Override
        public boolean equals(Object obj) {
            if (this == obj)
                return true;
            if (obj == null)
                return false;
            if (getClass() != obj.getClass())
                return false;
            Term other = (Term) obj;

            if (value == null) {
                if (other.value != null)
                    return false;
            } else if (!value.equals(other.value))
                return false;

            if (children == null) {
                if (other.children != null)
                    return false;
            } else if (!children.equals(other.children))
                return false;

            return true;
        }

        @Override
        public String toString() {
            return "Term [id=" + id + ", value=" + value + ", children=" + children + "]";
        }

  5. Overriding compare() method of Comparable interface used for sorting (Preferable but not mandatory).
    6.     @Override
        public int compareTo(Term term) {
            return (int) (this.id - term.id);
        }

And according to Java Language Specification, a POJO should not have to
  1. Extend prespecified classes, as in
    2.     public class Foo extends javax.servlet.http.HttpServlet {

        }

  2. Implement prespecified interfaces, as in
    3.     public class Bar implements javax.ejb.EntityBean {

        }

  3. Contain prespecified annotations, as in
    4.     @javax.persistence.Entity 
        public class Baz {

        }

However, developers and frameworks describe a POJO still requires the use prespecified annotations to implement features like persistence, declarative transaction management etc. So the idea is that if the object was a POJO before any annotations were added would return to POJO status if the annotations are removed then it can still be considered a POJO.
A JavaBean is a special kind of POJO that is Serializable, has a no-argument constructor, and allows access to properties using getter and setter methods that follow a simple naming convention.
Labels:

Comments

Post a Comment

Popular posts from this blog

How Does JVM Handle Method Overloading and Overriding Internally

In my previous article Everything About Method Overloading Vs Method Overriding , I have discussed method overloading and overriding, their rules and differences. In this article, we will see How Does JVM Handle Method Overloading And Overriding Internally, how JVM identifies which method should get called. Let’s take the example of parent class  Mammal and a child  Human classes from our previous blog to understand it more clearly. public class OverridingInternalExample { private static class Mammal { public void speak() { System.out.println("ohlllalalalalalaoaoaoa"); } } private static class Human extends Mammal { @Override public void speak() { System.out.println("Hello"); } // Valid overload of speak public void speak(String language) { if (language.equals("Hindi")) System.out.println("Namaste"); else System.out.println("Hello"); } @...
8 comments
Read more

AutoWiring Spring Beans Into Classes Not Managed By Spring Like JPA Entity Listeners

In my previous article JPA Auditing: Persisting Audit Logs Automatically using EntityListeners , I have discussed how we can use Spring Data JPA automate Auditing and automatically create audit logs or history records and update CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate properties. So in order to save history records for our File entity, we were trying to auto-wire EntityManager inside our FileEntityListener class and we have come to know that we can not do this. We can not inject any Spring-managed bean in the EntityListener because EntityListeners are instantiated by JPA before Spring inject anything into it. EntityListeners are not managed Spring so Spring cannot inject any Spring-managed bean e.g. EntityManager in the EntityListeners. And this case is not just with EntityListeners, you can not auto wire any Spring-managed bean into another class (i.e. utility classes) which is not managed by Spring. Because it is a very common problem and can also arise with other c...
7 comments
Read more

Why an outer Java class can’t be static

In a previous blog , I talked about why we can not define an outer class using private or protected keywords. If you have not read it, please go ahead and give it a look. I this article I will talk what is the use of the static keyword, why an outer Java class can’t be static, why it is not allowed in Java to define a static outer class. In order to understand that first, we need to understand what is the static keyword used for, what purpose it solves and how does it works. What does static keyword do Every Java programmer knows that if we need to define some behavior (method) or state (field) which will be common to all objects we define it as static. Because static content (behavior or state) does not belong to any particular instance or object, it will common to all objects and all objects are free to change any static field and every change will be visible to every object. We do not need to create any object of the class to access a static field or method, we can directly...
8 comments
Read more