对象,你可以理解成一种具有属性和行为的实体,它可向外部提供服务。而使用这个对象,可忽略其内部的细节,只需要知道使用这种服务时的“投入”、“产出”即可,因此,“高内聚、低耦合”是面向对象编程的基本思想。
略举一例,平时我们工作中要删除某条数据,一般不是真的delete掉,而是用一个status标识,status为-1表示删除,你写删除接口时完全可以这么写:
Class UserService{
private UserDao userDao;
public void deleteUser(User user){
user.setStatus(-1);
userDao.update(user);
}
}
这个逻辑其实执行的是更新操作,但接口名仍是deleteUser,因为它提供的确实是删除“服务”,调用接口时我只需要知道我调用这个接口时会删除对象,至于它怎么实现,我管不着。Java中到处是指针引用,习惯了使用c语言指针的程序员往往会乱用指针,而破坏了面向对象的思想,比如,我要查询某个用户的密码,有人可能会这么写:
Class UserService{
private UserDao userDao;
public void queryUserPasswd(int id,Useruser){
Stringpasswd=userdao.getUserPasswd(id)
User.setPasswd(passwd);
}
}
这种写法在语法上没什么问题,也能得到正确的值,但传个user对象进来就有些不妥了,我要得到密码,传个用户的密码,只要给个id就可以把密码返回给调用者了,干嘛要让人再传个对象进来?
作为一个项目经理,在工作过程中,确实会遇到令人哭笑不得的接口,就像上面那个删除接口吧,有人会这么写:
Class UserService{
publicvoid deleteUser(UserDao userDao ,User user){
user.setStatus(-1);
userDao.update(user);
}
}
这接口写得,让人摸不着头脑了,我删除一个user对象,还要传个userDao给你,意思是你为我提供服务,我还要给个工具给你,这说不通吧!
Java是纯粹的面向对象语言,写Java程序时要时刻记住,你在为别人提供服务,为别人提供服务就不应该提出过多的附加要求。这个问题在使用MVC模式分层思想的时候体现得更加严重。在使用MVC模式开发的时候,往往将整个项目分成几层:action层、service层、数据库处理层(dao层)等等,每一层往往由不同的程序员编写,这时候要格外提醒自己在为别人提供服务。在一个新项目开始的时候往往会出现一个问题:在增加某条数据时,要对这条数据的字段进行验证,不能为空或者长度过长等等,如果没有验证容易抛错,在分层编写接口时,开发人员经常想这个验证应该在上层或者下层做吧,我这边得到的数据是正确的,最后导致谁都没做验证。只要你记住了提供“服务”的思想,就不应该要求别人给你的数据是正确的,而是应该处理各种非正常问题,保证用户给你的任何数据你都能给出相应的返回,当然,在实际的项目中项目经理可能规定数据验证在service层做。