一般情况下,实体类的普通写法就是把所有字段都写成private的,然后为所有字段创建get/set方法。
但是我觉得既然读/写字段都要通过get/set方法,那就可以用它来做很多比较特别的事了。
================================
例一、某属性仅接受5~67范围的整数,那么在set方法里对小于5的赋值为5,对大于67的赋值为67
例二、某属性仅接受全大写的,那么在set方法里面将其变成大写
例三、某个作为查询条件的实体类,接受用户输入类似5-67之类的而生成where column1 between 5 and 67这样的查询,那么setColumn1方法中将其split成两段,赋值给column1Min属性和column1Max属性。
例四、分页查询对象里面有resultCount、pageSize、pageCount三个属性,那么在setResultCount中通过计算页数来给pageCount属性赋值,且将pageCount只读。
注:以上例子不代表它是正确的做法,而是作为探讨
================================
但是我听到有的说法说实体类里面不要写逻辑,只能用最普通的get/set方法,否则会导致一些问题。但是我又觉得像这样把实体自身的逻辑直接写到实体里面可以省很多事,等于把每次用到此属性时要做的判断集中进来,而且还避免了不一致的问题(如例四)。究竟实体类里面能不能写逻辑呢?如果不能写逻辑,像这样的逻辑放在哪里实现呢?再就是关于“伪属性”的问题:
这个“伪属性”是我自己起的名字,指的是这样的东西private int a;
private int b;
public setA(int a){
    this.a=a;
}
public setB(int b){
    this.b=b;
}
// 就是它
public getC(int c){
    return a+b;
}这样就有了一个名为c的属性,但是实际上却没有名为c的private字段。就省去了一些内存占用。
也许int占用的内存不是很大,但是如果是别的占用空间很大的类,或者对象的实例非常多的情况下,省下的空间就很可观了。
可是弊病就是每次调用伪字段的get方法时都要进行计算,也许a+b的计算量不是太大,但是如果是某个很复杂的计算呢?重复计算浪费的CPU也很可观。例如常见到这样的调用:if(x.getC()>0){
    i*=x.getC();
else if(x.getC()<0){
    i*=-(x.getC());
}
i+=x.getC();
System.out.println(x.getC());
System.out.println(i);
// 还可以继续写下去,整死你...如果采取以下“真属性”,就避免了反复计算,但是占用了空间。private int a;
private int b;
private int c;
public setA(int a){
    this.a=a;
    c=a+b;
}
public setB(int b){
    this.b=b;
    c=a+b;
}
// 就是它
public getC(int c){
    return c;
}究竟哪种方案更好呢?怎样处理这个矛盾?POJO实体类 逻辑POJO实体类逻辑

解决方案 »

  1.   

    有简单的逻辑计算是可以的,但是不能有业务方便的,不然就不叫POJO(Plain Ordinary Java Objects)简单的Java对象了。
      

  2.   

    具体问题具体分析:
    1,如果是数据库表的映射类,最好就是pojo,越简单越好
    2,如果是封装查询条件、查询结果这样的是可以加一些逻辑在里面的,没有问题的。
    最后一个问题,如果是计算时间较长的,我一般的写法:public class TestModel {
    private transient Integer _c;
    public int getC(int c){
    if(_c == null){
    _c = calculateC(c);
    }
    return _c;
    }

    private int calculateC(int c) {
    return c;
    }
    }
      

  3.   

    增强一个对象的方法通常有3种手段吧,这些都可以在service层实现
    从该对象继承,覆盖他的方法
    使用装饰者设计模式
    使用动态代理如果你把逻辑写在javabean里,当你要实现其他逻辑呢?
      

  4.   

    额  ,是听说过  ,不过是pojo不要涉及业务逻辑。简单的逻辑还可以省去写验证代码