这几天在做 Code Review 的时候，发现 Model 层内大量 Bean 写法不一。

有些类是属性凋谢一路 public，有些类则属性全副关闭 private。

大家针对这个问题探讨得还挺冲动，着实出其不意。

听他们的说辞，观点都挺有情理的。

关闭派支持者持以下观点。

Java 官网举荐针对实体类 Bean 进行封装，确保对外层调用者暗藏敏感数据。应该将类变量或属性申明为公有并提供公共获取及设置的办法，以便拜访和更新公有变量的值。

确实。假使一个属性是以 obj.field 的形式拜访或间接赋值更新，当 field 的拜访及更新逻辑须要调整时则得从新编写办法反对。

举个????。

一个蕴含间接拜访及更新变量的类如下。

Class Obj{  public int value;}Obj obj = new Obj();//应用属性间接拜访或更新obj.value = -1;int objValue = object.value;

而采纳关闭凋谢准则编写的类为：

Class Obj{  private int value;    public void setValue(int value){    this.value = value;  }    public int getValue(){    return value;  }}Obj obj = new Obj();//应用办法调用的形式拜访或更新obj.setValue(-1);int objValue = object.getValue();

当 Obj 心愿限定 value 的值在大于等于 0 的值区间时需调整 Obj 类的实现。

Class Obj{  private int value;    //限定逻辑  public void setValue(int value){    if(value < 0){      value = 0;    }    this.value = value;  }    public int getValue(){    return this.value;  }}

这样看起来，关闭派的写法确有前瞻性的。在将来，无论属性的拜访及更新值逻辑要做怎么的调整，对于内部调用者而言是齐全通明的。

凋谢派支持者其实并不拥护关闭派的说辞，但针对关闭派所有 Bean 实体都写成这种格局，且看提交记录这些类大部分都曾经两三年未修改的现状颇为不满。

有些用于形容 Android 设施信息，网络信息，App信息等固定内容的类，其属性并不会轻易进行批改。

想想也是，如AppInfo类用于形容 App 信息。

public class AppInfo{  public String appId;  public String versionName;  public String verionCode;  public String platform;  public String channel;  public String osVersion;  public String sdkVersion;  public String deviceId;  public String packageName;}

在没有 JIT 场景下，间接字段拜访要比调用 getter 办法快大概 3 倍；在有 JIT 场景下，间接字段拜访要比办法调用快大概 7 倍。

当然。凋谢派支持者也会思考该类的设计是否正当。

如上述变量 appId，心愿在测试环境下追加一个 test 的后缀标识。

比方正式环境下 appId 值为 com.android.demo，测试环境则为 com.android.demo.test。

可调整为：

public class AppInfo{  public String appId;    //新增办法用于返回兼容后的 appId  public String getCompatAppId(){    if(BuildConfig.TEST){       return appId + ".test";    }    return appId;  }}

又或者调整为：

public class AppInfoUtils{   //应用工具类对 appId 做二次转化   public getCompatAppId(String appId){      if(BuildConfig.TEST){         return appId + ".test";      }      return appId;   }}

这两种办法都可。

凋谢派认为

  1. appId 属性不应该被轻易改变，没有必要过渡设计；
  2. 哪怕真的须要改变，改变也没有毁坏属性的定义，可通过新增性能函数来解决这个问题即可。

一百个编程者心里有一百个哈姆雷特啊！

聊一聊我的认识。

在理论我的项目我的确也不会为所有 Bean 类编写 setter/getter 办法，因为会让代码变得冗余且调用绝对麻烦。

但在封装设计SDK上，思考到 SDK 保护及 API 更改的老本，还是遵循了凋谢关闭的设计准则，审慎为好。

但代码看起来就是顺当呀。

好在Koltin解决了我心田的纠结。

对于 var 关键字申明的属性，gettter/setter是可选的，得益于幕后字段的设计，属性的拜访及更新变为可干涉的。

最初分享下最近有感的一句话

Fucking code, just happy!

欢送关注 「Android之禅」公众号，和你分享有价值有思考的技术文章。
可增加微信 「Ming_Lyan」备注 “进群” 退出技术交换群，探讨技术问题严禁所有广告灌水。
如有 Android 畛域有遇到技术难题亦或对将来职业规划有纳闷，一起探讨交换。
欢送来扰。