为什么对象的属性和操作用二个类进行分离，为什么对象的操作集合定义在接口中不定义在类中
0
悬赏园豆：10
[待解决问题]
在使用面向对象思想设计类和方法时，有二个问题我无法向同事说明其优点，希望有了解的博友能帮助指点一二。
1 一个对象的属性和操作用二个类进行分离（例如User对象，分离为UserBean.java和IUserService.java），能为项目带来实际优势么，比如提高开发效率还是方便后期维护，为什么会呢？
2 一个对象（User对象）的操作集合定义在 public interface IUserService{} 中，不是定义在 public class UserService{}中，这样能为项目带来实际优势么，比如提高开发效率还是方便后期维护，为什么会呢？
一共二个问题，每题5分，麻烦大家回答时，标注一下文本描述的是问题一或问题二。
我是认同这二种做法的，但是在项目开发过程中我不进行分离，把操作集中有方法定义在具体类中，也能达到复用，所以才有这样的疑问。
一个不使用分离，不把操作定义在接口中，实现个性化和复用的事例，它的优点是结构简单。
1 在单个项目时，我使用一个UserService.java（这个类包含了属性和方法）提供用户的操作。
2 项目扩展到三个时，我写了三个类（UserService1.java，UserService2.java,UserService3.java）做个性操作，一个父类(BaseUserService.java)用做公用操作。使用spring的依赖注入在配置文件中指定使用到的类。（有了spring的依赖注入是不是接口的优势就不存在了）
我相信数据和操作分离，操作定义在接口中有优点，但我不知道在怎么样的场景中能体现中来，并且我觉得这些场景需要足够的普遍。毕竟分离和使用接口使类的结构复杂了。
所有回答(3)
0
交流学习一下，个人想法
问题一：UserBean,IUserService，USerController(USerAction),使用的MVC的编程思想，每一层的职责可以理解成单一的，相当于把工作细化，从而达到解耦，不管是代码的开发和后期的维护都有比较清晰的思路，spring是bean编辑，通过对bean的管理，依赖注入等达到解耦和复用等。试想一下，一个人啥事情都做，大部分后果：1累死，2工作不专一
问题二：使用接口，在项目协同开发时，负责人定好接口，具体的实现由具体的人来做，对于你说的项目扩展到三个的时候个性化的时候，使用3个类，我有疑问，不可以用重载去解决吗？在你说的spring依赖注入的问题，首先你每次调用不同的userService,都要new一个出来，是不是很烦？还有spring的依赖注入是基于spring的ioc容器的，约定是一个接口只能有一个实现类，你有多个实现类的时候，如果使用spring注入，会报错的
0
spring的依赖注入和接口没有关系; 只不过原本需要自己new Service()的地方; 换成了spring帮你创建这个对象.
其实你的这些问题, 我觉得用java设计原则就可以解答你;
楼上说的一个接口多个实现类会报错, 因为那是没指定注入哪一个
0
一.实体类之存放访问实体类属性的方法，业务方法往往需要操作多个实体类，所以都放到service中
二.我平常使用接口的时候用的是，实现接口必须实现接口中的所以方法。
比如在游戏里面写活动，我们经常会有新的充值消费活动，我们每个活动都要继承抽象活动父类（抽象类的抽象方法也必须重写），每次写新活动只需要把重写父类的抽象方法并补充完毕就可以了，不会遗漏一些必须的东西。而且维护活动的时候就算不是自己写的方法，也能根据通用的方法名知道哪个方法是干嘛的
