前段時間對乙個部落格進行設計，在關於封裝查詢語句的函式上面做乙個錯誤的決定，那就是過度設計，原因是這樣滴：
因為需求沒有完全弄明白，也不知道以後會不會新增別的查詢判斷語句，所以在函式的引數，返回值等方面抉擇的型別為不定型inte***ce{}也就是c的（void*），當時是這樣想滴：以後就算修改了，或新增了查詢條件語句也沒關係，因為引數為不定型，所以函式呼叫的時候沒有任何的影響，只在函式內部進行修改就可以了。
但是但是，，，，，，，
事實證明決策是錯誤的。
分為四種情況：
1. 以後確定不會改變。
2. 以後應該不會改變。
3.以後 不確定會不會改變。
4.以後應該會改變。
第一種情況下，不用多說，**硬寫就可以了，不用考慮靈活性（擴充套件性？）。
第二，三種情況下，比較難把握，以前有個誤區也在這裡，也是大部分人經常的錯誤所在：選擇為以後的擴充套件做努力。可以展現技術水平嘛，但事實正確的做法是：在這種情況下應該去假設以後不會改變去做設計，為什麼吶？原因在於，未來的可變性太多，就算是現在去做了很複雜的去適應未來，到未來到來的時候，大部分設計都會失敗的。二點是：簡單的實現，會節省時間，減少bug，**清晰等各種好處。但是為什麼好多人大部分都會選擇過度設計吶：因為可以滿足技術慾望，程式設計師的通病啊。
第三種情況下，毋庸置疑要選擇考慮擴充套件性的設計啦。
關於業務主鍵和邏輯主鍵
關於這個問題網上已經有很多的討論，現在綜合這些討論在加上自己眾多建模及資料倉儲工作中的經驗給出以下分析及取捨建議，供各位同行參考 一 業務的東西，是每乙個做軟體的最薄弱的，並且是最有可能受到客戶影響的，也是最會引起問題的。比如身份證，如果有系統的錶用此做主鍵，其他眾多表以此為外來鍵，當身份證從15位...
關於架構 框架 業務邏輯的理解
最近在回顧和總結上乙個五年的工作成長歷程，其中加入了個人對架構 框架 業務邏輯的理解，順便摘抄下來分享到部落格。由於個人認知有限，難免存在紕漏。1 架構 按照我的理解，架構有廣義和狹義的解釋。從廣義角度來說，它是人類進行社會化生產的組織形式，以及為保證組織形式能夠正常開展的方方面面。乙個典型的案例就...
J2EE DAO層和業務邏輯層的設計
舉個例子,比如要做乙個學生選課管理系統，資料庫中有三張表，分別是students,teacher,course dao層介面設計 inte ce studentdao inte ce teacherdao inte ce coursedao 業務層介面設計 inte ce studentservic...