最近在學習《unix程式設計藝術》。第一章非常不錯，講了很多unix的歷史，哲學基礎，其中最重要的是提到的十七條設計原則。很多原則自己也知道，但是從來沒有總結的如此詳細深刻。
下面的內容大部分來自《unix程式設計藝術》這本書，少部分是我的一些理解。這是我讀書的乙個習慣，對於我認為重要的，我會把它打出來，在打字的過程中我會根據深入的思考理解。所以，筆記對我來說是乙個思考和記憶的輔助手段。
9、 表示原則：把知識疊入資料以求邏輯質樸而健壯
即使最簡單的程式邏輯讓人類來驗證也很困難，但是就算是很複雜的資料，對人類來說，還是相對容易地就能夠推導和建模的。
資料比程式設計邏輯更容易駕馭。在複雜資料和複雜**中選擇，寧可選擇前者。在設計中，你應該主動的將**的複雜度轉移到資料中去。
rob pick講到的第五個原則：
資料壓倒一切。如果你已經選擇了合適的資料結構並且把一切都組織得井井有條，正確的演算法也就不言自明。程式設計的核心是資料結構，而不是演算法。
10、 通俗原則：介面設計避免標新立異
也就是眾所周知的「最少驚奇原則」。
最易用的程式就是使用者學習新東西最少的程式。
另乙個方面是避免表象相同而實際卻略有不同，這會及其危險。最好讓不同事物有明顯區別，而不要看起來幾乎一模一樣。
11、 緘默原則：如果乙個程式沒有什麼好說的，就保持沉默
「簡潔是unix的核心風格。重要的資料不應該混雜在冗長的程式內部行為資訊中。」
12、 補救原則：出現異常時，馬上退出並給足異常資訊
軟體要盡可能從容的應付各種錯誤輸入和自身的執行錯誤。但是，如果做不到這一點，就讓程式盡可能以一種容易診斷錯誤的方式終止操作。
對於協議：要寬進嚴出。
13、 經濟原則：寧花機器一分，不花程式設計師一秒
應該採用更加高階的語言，讓程式設計師從自習管理記憶體的負擔重解放出來。
14、 生成原則：避免手工hack，盡量編寫程式去生成程式
也就是教會機器去做更多低層次的程式設計工作。
乙個方向就是dsl。
15、 優化原則：雕琢前先得有原型，跑前先學會走
過早優化時萬惡之源，他會損害設計。
先給你的設計做個未優化的，執行緩慢的，很耗記憶體但是正確的實現，然後向進行系統調整，尋找那些可以犧牲最小的區域性的簡潔性而獲得較大的效能提公升的地方。
16、 多樣原則：決不相信所謂的「不二法門」的斷言
即使最出色的軟體也常常會受限於設計者的想象力。
unix奉行的是廣泛採用多種語言、開發的可擴充套件機制和使用者定製機制。
17、 擴充套件原則：設計著眼未來，未來總比預想快
設計協議或者文字格式時，應使其具有充分的自描述性以便擴充套件。
設計**是，要有很好的組織，讓將來的開發者增加新功能時無需拆毀或重建整個架構。
unix哲學一言以蔽之：
kiss原則：keep it ******，stupid！
態度：如果不確定什麼是對的，那麼就只做最少量的工作，確保完成任務就行，直到明白什麼是對的。
軟體設計是一門技藝。
我們應該不斷追求卓越。
不要重複製造輪子。
善用工具，盡可能將一切都自動化。
以前粗略的翻過這本書，一位是介紹unix作業系統的。現在詳細看看，原來就是介紹unix設計思想的，而且緊緊的圍繞上面的原則。
這本書非常適合現在的我，因為我一看就愛不釋手。所以決定最近系統的學習一下。先從資料驅動程式設計開始，這一塊我有些經驗，正好可以系統整理一下。
設計模式 學習設計模式之二（原則1）
1.單一職責原則 定義 單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因！單一職責就是乙個類負責一種職責，比如，在物件導向的計算器中，每乙個計算的方式就有乙個對應的計算類。這個計算方式的業務都在這個類中，而其他的計算跟這個類無關。我的例子也許不是非常的恰當，再例如，三層架構，就是對各種邏輯的...
Unix網路程式設計伺服器設計方式之二
此方式首先伺服器端建立乙個監聽，並阻塞至accetp處，當乙個客戶端進行連線時，accept函式並啟用並返回，此時用fork函式建立乙個子程序，由子程序執行客戶請求處理程式，而父程序繼續監聽，等待其他的客戶端。此方式會建立很多的程序，程序個數受具體的作業系統的限制。這種併發伺服器的缺點在於建立乙個子...
（六）物件導向的設計原則之二
一 簡介 命令模式 命令模式分為 命令的請求者 和 命令的實現者 使得命令的請求和實現完成了解耦。二 示例 模擬服務員與廚師 class mealcommand implements command public function execute class drinkcommand impleme...