對象，你可以理解成一種具有屬性和行為的實體，它可向外部提供服務(wù)。而使用這個對象，可忽略其內(nèi)部的細(xì)節(jié)，只需要知道使用這種服務(wù)時的“投入”、“產(chǎn)出”即可，因此，“高內(nèi)聚、低耦合”是面向?qū)ο缶幊痰幕舅枷搿?/span>

略舉一例，平時我們工作中要刪除某條數(shù)據(jù)，一般不是真的delete掉，而是用一個status標(biāo)識，status為-1表示刪除，你寫刪除接口時完全可以這么寫：

Class UserService{

       private UserDao userDao;

              public void deleteUser(User user){

                     user.setStatus(-1);

                     userDao.update(user);

}

}

       這個邏輯其實執(zhí)行的是更新操作，但接口名仍是deleteUser，因為它提供的確實是刪除“服務(wù)”，調(diào)用接口時我只需要知道我調(diào)用這個接口時會刪除對象，至于它怎么實現(xiàn)，我管不著。

       Java中到處是指針引用，習(xí)慣了使用c語言指針的程序員往往會亂用指針，而破壞了面向?qū)ο蟮乃枷耄热纾乙樵兡硞€用戶的密碼，有人可能會這么寫：

       Class UserService{

              private UserDao userDao;

                     public void queryUserPasswd(int id,User user){

                            String passwd=userdao.getUserPasswd(id)

User.setPasswd(passwd);

}

}

       這種寫法在語法上沒什么問題，也能得到正確的值，但傳個user對象進來就有些不妥了，我要得到密碼，傳個用戶的密碼，只要給個id就可以把密碼返回給調(diào)用者了，干嘛要讓人再傳個對象進來？

       作為一個項目經(jīng)理，在工作過程中，確實會遇到令人哭笑不得的接口，就像上面那個刪除接口吧，有人會這么寫：

Class UserService{

              public void deleteUser(UserDao userDao ,User user){

                     user.setStatus(-1);

                     userDao.update(user);

}

}

這接口寫得，讓人摸不著頭腦了，我刪除一個user對象，還要傳個userDao給你，意思是你為我提供服務(wù)，我還要給個工具給你，這說不通吧！

Java是純粹的面向?qū)ο笳Z言，寫Java程序時要時刻記住，你在為別人提供服務(wù)，為別人提供服務(wù)就不應(yīng)該提出過多的附加要求。這個問題在使用MVC模式分層思想的時候體現(xiàn)得更加嚴(yán)重。在使用MVC模式開發(fā)的時候，往往將整個項目分成幾層：action層、service層、數(shù)據(jù)庫處理層（dao層）等等，每一層往往由不同的程序員編寫，這時候要格外提醒自己在為別人提供服務(wù)。在一個新項目開始的時候往往會出現(xiàn)一個問題：在增加某條數(shù)據(jù)時，要對這條數(shù)據(jù)的字段進行驗證，不能為空或者長度過長等等，如果沒有驗證容易拋錯，在分層編寫接口時，開發(fā)人員經(jīng)常想這個驗證應(yīng)該在上層或者下層做吧，我這邊得到的數(shù)據(jù)是正確的，最后導(dǎo)致誰都沒做驗證。只要你記住了提供“服務(wù)”的思想，就不應(yīng)該要求別人給你的數(shù)據(jù)是正確的，而是應(yīng)該處理各種非正常問題，保證用戶給你的任何數(shù)據(jù)你都能給出相應(yīng)的返回，當(dāng)然，在實際的項目中項目經(jīng)理可能規(guī)定數(shù)據(jù)驗證在service層做。