业务和数据库对象之间的继承答案

【问题标题】：Inheritance between business and database objects业务和数据库对象之间的继承
【发布时间】：2021-03-25 22:46:15
【问题描述】：

我正在重构 java 中的代码库。因为业务对象和数据库对象有不同的包。但是它们中的大多数属性是相同的，在声纳报告这一点后我注意到了。所以我正在考虑制作一个公共父类，然后所有 BO（业务对象）和 DO（对象）都可以扩展它吗？我的疑问是，为 BO 和 DO 对象拥有一个共同的父类是个好主意吗？如果是，那么我可以把这个共同的父类放在哪里？在BO包、DO包还是新建Commons包？

当前设计示例：

Package BO:
  Class B01
{

 int a 
 int b
 //getter setter for a and b;
}
 Class B02:
{

 int a 
 int b
 int c
 //getter setter for a,b and c;
}

Package DO:
  Class D01
{

 int a 
 int b
 int e
 int lastUpdated
 
 //getter setter 
}
 Class D02:
{

 int a 
 int b
 int g
 int h
 int lastUpdated
   
 //getter setter 
}

后续问题是，是否有可能在 BO 和 DO 中都有一个共同的祖父母，然后在 BO 和 DO 中都有一个父母，扩展共同父母，然后这些类扩展各自的父母？

【问题讨论】：

那你为什么要分离对象呢？如果这些只是没有业务逻辑的 POJO，那么您应该只拥有其中一个。如果有关联的业务逻辑，可以封装而不是继承。
这些只是 pojo，但它们共享一些（不是全部）属性相同。就像有 2 个业务 pojo 和两个数据库 pojo，但它们都有相同的公共属性和一些特定于该 pojo 的不同属性，所以这就是为什么有多个 pojo。业务 pojo 和数据库 pojo 有一些共同的属性

标签： java inheritance package sonarqube refactoring

【解决方案1】：

使用这样的继承虽然最初很有吸引力，但并不是一个好主意，因为它会导致代码非常不灵活。虽然在开发的早期阶段它看起来不错，因为它会减少代码，但业务需求总是会发生变化，并且业务对象可能会开始与数据库实体分道扬镳。

如果您熟悉 SOLID 设计原则，那么 S 代表 Single Responsibility，这意味着一个类应该有一个并且只有一个改变的理由。按照您的建议使用继承意味着父类可能有多种更改原因，即当数据库结构更改和/或业务域更改时。

业务对象应该为您的数据库实体提供不同的用途。在面向对象的开发中，业务类封装了数据和行为。数据库实体通常只包含数据。应用程序倾向于在各种不同风格的 POJO 之间进行映射 - DTO 业务对象 DAO。这可确保您的应用程序能够应对大多数项目在某个时间点必须处理的更改。

【讨论】：