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