對象，你可以理解成一種具有屬性和行為的實體，它可向外部提供服務。而使用這個對象，可忽略其內部的細節，只需要知道使用這種服務時的“投入”、“產出”即可，因此，“高內聚、低耦合”是面向對象編程的基本思想。
略舉一例，平時我們工作中要刪除某條數據，一般不是真的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層做。