Java Design Concept of POJOs

Question

I'm trying to understand the best design concept for a java POJO. If I had a car object like so:

public class Car {
    private String color;
    private String make;
    private String model;
    private int year;

    public Car(String color, String make, String model, int year) {
        this.color = color;
        this.make = make;
        this.model = model;
        this.year = year;
    }

    public String getColor() {
        return color;
    }

    public void setColor(String color) {
        this.color = color;
    }

    public String getMake() {
        return make;
    }

    public void setMake(String make) {
        this.make = make;
    }

    public String getModel() {
        return model;
    }

    public void setModel(String model) {
        this.model = model;
    }

    public int getYear() {
        return year;
    }

    public void setYear(int year) {
        this.year = year;
    }
}

Should this car pojo have more methods in it like getGasMileage or getTirePressure or should those methods be put inside of a utility/interface that takes in a Car object?

This is a design question based around a current code base using Domain Driven Design (DDD) with Entity objects that contain methods like getGasMileage. Should a pojo/entity contain only getter/setter code or is it good practice to also contain other methods?

POJO's contain only fields and getters / setters for them. Any logic that processes `Car` objects should be extracted to separate classes — Ivan Pronin, May 11 '17 at 20:23
This is a matter of opinion and heated debate, use your best judgement. — fps, May 11 '17 at 22:09

score 6 · Accepted Answer · edited May 23 '17 at 10:31

POJOs are intended to contain business logic, according to Martin Fowler, who invented the term.

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.

Confusion occurs because POJOs are often conflated with Java Beans. See: What is the difference between a JavaBean and a POJO?

Java Design Concept of POJOs

1 Answers1