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();

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

  5. Each variable should have its Setter-Getter method with public accessibility.
  6.     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;
    }
  7. Generally POJO should override equals(), hashCode() and toString() methods of Object (but it's not mandatory).

  8. 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 + "]";
    }

  9. Overriding compare() method of Comparable interface used for sorting (Preferable but not mandatory).
  10.     @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 {

    }

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

    }

  5. Contain prespecified annotations, as in
  6.     @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.

Comments

Post a Comment

Popular posts from this blog

Why Single Java Source File Can Not Have More Than One public class

According to Java standards and common practices we should declare every class in its own source file. And even if we declare multiple classes in the single source file (.java) still each class will have its own class file after compilation. But the fact is that we can declare more than one class in a single source file with below constraints, Each source file should contain only one public class and the name of that public class should be similar to the name of the source file. If you are declaring the main method in your source file then main should lie in that public class If there is no public class in the source file then main method can lie in any class and we can give any name to the source file. If you are not following 1st constraint then you will receive a compilation error saying “ The public type A must be defined in its own file ”.  While if you are not following the second constraint you will receive an error “ Error: Could not find or load main class User ” after ...

Java Cloning - Copy Constructor versus Cloning

In my previous article Java Cloning and Types of Cloning (Shallow and Deep) in Details with Example , I have discussed Java Cloning in details and answered questions about how we can use cloning to copy objects in Java, what are two different types of cloning (Shallow & Deep) and how we can implement both of them, if you haven’t read it please go ahead. In order to implement cloning, we need configure our classes to follow below steps Implement Cloneable interface in our class or its superclass or interface, Define clone() method which should handle CloneNotSupportedException (either throw or log), And in most cases from our clone() method we call the clone() method of the superclass. And super.clone() will call its super.clone() and chain will continue until call will reach to clone() method of the Object class which will create a field by field mem copy of our object and return it back. Like everything Cloning also comes with its advantages and disadvantages. However, Java c...

Spring Data JPA Auditing: Saving CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate automatically

In any business application auditing simply means tracking and logging every change we do in the persisted records which simply means tracking every insert, update and delete operation and storing it. Auditing helps us in maintaining history records which can later help us in tracking user activities. If implemented properly auditing can also provide us similar functionality like version control systems. I have seen projects storing these things manually and doing so become very complex because you will need to write it completely by your own which will definitely require lots of code and lots of code means less maintainability and less focus on writing business logic. But why should someone need to go to this path when both JPA and Hibernate provides Automatic Auditing which we can be easily configured in your project. And here in this article, I will discuss how we can configure JPA to persist CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate columns automatically for any ...