我的问题陈述是:
我想编写设计文件管理(添加,复制,删除等操作)。有两种方法:
写入仅包含文件属性的文件VO。例如,
public Class File {
private boolean hidden;
private boolean read;
private boolean write;
public boolean isHidden() {
return hidden;
}
public void setHidden(boolean hidden) {
this.hidden = hidden;
}
public boolean isRead() {
return read;
}
public void setRead(boolean read) {
this.read = read;
}
public boolean isWrite() {
return write;
}
public void setWrite(boolean write) {
this.write = write;
}
}
并为文件相关操作分离服务。对于例如:
public Class FileService {
public boolean deleteFile(File file) {
//Add delete logic.
}
//Same way you can add methods for Add and copy file.
}
文件VO包含所有属性和所需操作:
public class File {
private boolean hidden;
private boolean read;
private boolean write;
public boolean isHidden() {
return hidden;
}
public void setHidden(boolean hidden) {
this.hidden = hidden;
}
public boolean isRead() {
return read;
}
public void setRead(boolean read) {
this.read = read;
}
public boolean isWrite() {
return write;
}
public void setWrite(boolean write) {
this.write = write;
}
public boolean deleteFile() {
//Add delete logic.
}
//Same way you can add methods for Add and copy file.
}
那么这种方法的优点和缺点是什么?
答案 0 :(得分:6)
在面向对象的语言中,将逻辑放在类本身而不是服务类中是典型的方法(以及更好的IMO)。它遵循“告诉,不要问”原则,例如,通过告诉文件删除自己,而不是要求某些服务删除它。这背后的主要原因之一是允许继承。例如,如果你有一个File的子类,并希望在删除它之前让它写一条日志消息,那么对服务类来说就很难了,因为你需要为每个子类使用不同的服务类。
就面向服务的方法而言,这通常被认为是更高层次的(即面向服务的架构)。考虑一个金融股票系统,您可能有“买入股票”服务和“卖出股票”服务。拥有一个与个别类别相对应的服务类(即一个知道如何买卖股票的股票服务)不会非常面向对象。
您的系统中也可能有一个服务层,它提供与其他外部服务(即数据库)的集成点,但同样,我不认为这就是您在这里所说的。所以,我可以坚持在File类本身中封装逻辑的方法。
答案 1 :(得分:4)
如果没有太多关于您正在设计的系统的信息,那么很难发音。对我而言,选择取决于系统边界。
如果您需要提供作为服务公开且外部消费者可访问的API,请转到解决方案1,这是唯一的方法。如果你的系统是一个库,其API将由其他应用程序在内部使用,那么在解决方案2中寻找一个丰富的域模型,它就是更多的OO。您不希望使用没有真正原因的服务,管理器和实用程序类来扩展您的API。
但是,再一次,在不知道你的最终目标的情况下,很难说。