POJO的Java设计理念 [英] Java Design Concept of POJOs

问题描述

我正在试图了解一个java POJO的最佳设计理念。如果我有一个 car 对象，如下所示：

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;
    }
}

如果这辆汽车pojo有更多的方法，像 getGasMileage 或 getTirePressure 或者应该将这些方法放在一个实用程序/接口中，其中包含一个 Car 对象？

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?

这是一个基于使用域驱动设计（DDD）的当前代码库的设计问题，实体对象包含诸如 getGasMileage 。 pojo / entity是否只包含getter / setter代码，还是包含其他方法的好习惯？

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?

推荐答案

根据 Martin Fowler ，发明了该术语，以包含业务逻辑。

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

这个词是创造的，而Rebecca Parsons，Josh MacKenzie和我正在准备在2000年9月的会议上进行一次演讲。在谈话中，我们指出将业务逻辑编码为常规java对象而不是使用实体Bean的许多好处。我们想知道为什么人们在系统中使用常规对象是如此反对，并得出结论认为这是因为简单的对象缺少一个奇怪的名字。所以我们给了他们一个，它被抓住了非常好。

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.

发生混淆是因为POJO经常与Java Bean混合。请参阅： JavaBean和POJO之间有什么区别？ ？

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

这篇关于POJO的Java设计理念的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！