Java 中 在项目里 给枚举中定义 abstract 方法 是否破坏了层级结构？
yuhuan66666 · 2019-01-07 15:43:24 +08:00 · 3146 次点击这是一个创建于 2147 天前的主题，其中的信息可能已经有所发展或是发生改变。
model 中定义的枚举，由于 switch 不方便维护 ，所以我在枚举上写了 abstract 方法 来进行不同的业务实现
但是感觉在 model 中写了业务逻辑，回破坏现有的分层结构？
求问大神们 有什么好的办法
因为这个枚举 代码里很多地方都用到，做了很多不同的判断， 写了 很多的 switch 现在我想都替换成 abstract 方法 实现多个 abstract 方法来解决
第 1 条附言 · 2019-01-08 10:28:41 +08:00
按照switch的写法
switch (某快递) {
case 待发快递:
action1(); //待发快递定向操作1
break;
case 代收快递:
action2(); //代收快递定向操作2
break;
}
按照我想使用的写法
enum 快递类型 {
待发快递(0, "待发快递") {
@Override
public void action() {
//定向操作
}
},
代收快递(1, "代收快递") {
@Override
public void action() {
//定向操作
}
},
;
private Integer type;
private String desc;
public abstract void action();
}
使用时：
待发快递.action();
快速写个demo 大家别吐槽我
 |
1
swim2sun 2019-01-07 20:06:59 +08:00
你的做法是正确的
|
 |
2
evanJa 2019-01-07 21:03:48 +08:00
用 abstract 方法没问题啊，这样还可以防止添加新的 enum 类型时忘了添加逻辑的问题
|
 |
3
yuhuan66666 OP @evanJa #2 但是 把业务逻辑 引入到 model 层了呀
|
 |
4
nl101531 2019-01-07 21:12:53 +08:00 via Android
做法很正确，策略枚举，switch case+枚举的缺点就是增加或者减少对应的枚举实例时要到处找之前的。。。
|
 |
5
xuanbg 2019-01-07 21:13:18 +08:00
model 层这个概念真真害人。。。你想一下包路径的逻辑是什么。难道不是 com.企业.产品.模块.功能.类这个样子？那有什么 model 层
|
|
6
xuanbg 2019-01-07 21:18:17 +08:00
在项目的代码结构里面，分层是逻辑上的而非物理上的。物理上进行分层，只会造成代码结构的混乱。代码结构在物理上应该按产品-模块-功能这个结构进行规划。
|
 |
8
lhx2008 2019-01-07 21:50:41 +08:00 via Android
@xuanbg model 还是 model 文件夹，功能应该分去 service 文件夹下面的功能文件夹，数据库是数据库文件夹，这样有什么问题吗？如果先垂直切分，那分层还有什么意义呢。
|
 |
9
grantonzhuang 2019-01-07 21:53:59 +08:00 via Android
@xuanbg 同意你的看法，代码是为业务逻辑服务的，和实现无关
|
 |
10
Kaiv2 2019-01-07 22:11:14 +08:00 via Android
最好不要在 model 添加太多逻辑(model 如果是对应数据库，一般不会进入版本管理)，枚举可放在另外的包目录。给枚举中定义 abstract 方法，是想实现不同值有不同的逻辑处理? 跟破坏层次结构应该没有关系
|
 |
11
sagaxu 2019-01-07 22:14:31 +08:00 via Android
@lhx2008 分层本身就不是绝对必要的，简单的业务可以不分那么多层，大概只有 JAVA 有这么多繁文缛节了
|
 |
13
Belmode 2019-01-08 00:26:40 +08:00 via Android
完全可以的，定义业务的实体就是 BO 业务逻辑对象，也是 POJO 的一种，也是 Model 啊。
|
|
15
lhx2008 2019-01-08 00:51:15 +08:00 via Android
|
 |
16
yanaraika 2019-01-08 01:00:48 +08:00 via Android
厚 controller 是邪路
正确的是把业务逻辑尽可能放 model 里，把 controller 做薄 |
|
17
sagaxu 2019-01-08 01:10:11 +08:00 via Android
@lhx2008 都是异构的 service，php，java，go，cpp 各种语言都有，单个服务都不大，最大的不到一万行代码。服务只对暴露的接口负责，内部爱咋样就咋样，全放一个文件里也是有的。
|
 |
18
passerbytiny 2019-01-08 08:58:40 +08:00
model 的翻译是模型，模型就是现实事务的模拟，就是类，为什么不能有业务逻辑。楼上的几位，贫血模型的毒，中的不轻。
楼主能否上些代码例子，目前我不明白你说的情况具体是啥样。 |
 |
19
Lighfer 2019-01-08 09:27:00 +08:00
这么做完全没问题啊，既然枚举不同值需要实现不同的业务，那么本身就应该将其关联起来，代码实现非常清晰，也很好理解。分层什么的，本质上不就是为了业务逻辑更清晰、代码更易懂易维护？如果它成了束缚，那就应该及时打破。
|
 |
20
thinkmore 2019-01-10 09:38:23 +08:00
这样做完全没问题,但是我看起来有点别扭.
这样行不行? ```java public class Action1 implements Action { public void action() { } public boolen canHandle() { } } public class Action2 implements Action { public void action() { } public boolen canHandle() { } } ``` |
|
21
yuhuan66666 OP @thinkmore #20 这种写法的话 如何做到 新添加枚举的时候 不忘记对新的枚举状态实现新的 Action ？
|
 |
22
PoetAndPoem 2019-01-11 10:58:32 +08:00
@yuhuan66666 不太懂你的意思，怎么实现没关系吧。如果只是忘记添加代码，即使是枚举类，也会存在忘记在枚举类添加枚举的情况啊
|
Select Language