Java 中 在项目里 给枚举中定义 abstract 方法 是否破坏了层级结构？

[yuhuan66666]

model 中定义的枚举，由于 switch 不方便维护 ，所以我在枚举上写了 abstract 方法 来进行不同的业务实现

但是感觉在 model 中写了业务逻辑，回破坏现有的分层结构？

求问大神们 有什么好的办法

因为这个枚举 代码里很多地方都用到，做了很多不同的判断， 写了 很多的 switch 现在我想都替换成 abstract 方法 实现多个 abstract 方法来解决

[swim2sun]

你的做法是正确的

[evanJa]

用 abstract 方法没问题啊，这样还可以防止添加新的 enum 类型时忘了添加逻辑的问题

[yuhuan66666]

@evanJa #2 但是 把业务逻辑 引入到 model 层了呀

[nl101531]

做法很正确，策略枚举，switch case+枚举的缺点就是增加或者减少对应的枚举实例时要到处找之前的。。。

[xuanbg]

model 层这个概念真真害人。。。你想一下包路径的逻辑是什么。难道不是 com.企业.产品.模块.功能.类这个样子？那有什么 model 层

[xuanbg]

在项目的代码结构里面，分层是逻辑上的而非物理上的。物理上进行分层，只会造成代码结构的混乱。代码结构在物理上应该按产品-模块-功能这个结构进行规划。

[lhx2008]

@xuanbg 那功能文件夹内部怎么把数据库，模型分开呢，模型不会在功能之间共用吗？

[lhx2008]

@xuanbg model 还是 model 文件夹，功能应该分去 service 文件夹下面的功能文件夹，数据库是数据库文件夹，这样有什么问题吗？如果先垂直切分，那分层还有什么意义呢。

[grantonzhuang]

@xuanbg 同意你的看法，代码是为业务逻辑服务的，和实现无关

[Kaiv2]

最好不要在 model 添加太多逻辑(model 如果是对应数据库，一般不会进入版本管理)，枚举可放在另外的包目录。给枚举中定义 abstract 方法，是想实现不同值有不同的逻辑处理? 跟破坏层次结构应该没有关系

[sagaxu]

@lhx2008 分层本身就不是绝对必要的，简单的业务可以不分那么多层，大概只有 JAVA 有这么多繁文缛节了

[xuanbg]

@lhx2008 放到公共模块里面就好了呀

[Belmode]

完全可以的，定义业务的实体就是 BO 业务逻辑对象，也是 POJO 的一种，也是 Model 啊。

[Belmode]

@xuanbg 为什么说是害人？

[lhx2008]

@xuanbg
@sagaxu
能给一个你觉得文件夹规划合适的较大的项目或者你现在的项目的目录结构发上来看看么，我学习学习

[yanaraika]

厚 controller 是邪路

正确的是把业务逻辑尽可能放 model 里，把 controller 做薄

[sagaxu]

@lhx2008 都是异构的 service，php，java，go，cpp 各种语言都有，单个服务都不大，最大的不到一万行代码。服务只对暴露的接口负责，内部爱咋样就咋样，全放一个文件里也是有的。

[passerbytiny]

model 的翻译是模型，模型就是现实事务的模拟，就是类，为什么不能有业务逻辑。楼上的几位，贫血模型的毒，中的不轻。

楼主能否上些代码例子，目前我不明白你说的情况具体是啥样。

[Lighfer]

这么做完全没问题啊，既然枚举不同值需要实现不同的业务，那么本身就应该将其关联起来，代码实现非常清晰，也很好理解。分层什么的，本质上不就是为了业务逻辑更清晰、代码更易懂易维护？如果它成了束缚，那就应该及时打破。

[thinkmore]

这样做完全没问题,但是我看起来有点别扭.
这样行不行?
```java
public class Action1 implements Action {
public void action() {
}
public boolen canHandle() {

}
}

public class Action2 implements Action {
public void action() {
}
public boolen canHandle() {

}
}


```