隨便談談
學習設計模式的過程中，有一種感覺越來越強烈，就是抽象。就是把一些重複的經常出現的東西，整理出來放在一起，寫起來管理起來都方便。從最原始的迴圈，到後來的函式，甚至古老的代數，通過用可以代表任何數的字母抽象出一些數學公式，使得人們可以直接對公式進行研究，乙個公式就代表了無數個式子，最初提出這個東西的人真是了不起的。而迴圈和函式，使得只需要改變幾個引數值不同的其他完全相同的程式，通過把引數用變數表示，把他們放在一起，這樣 只需修改乙個地方的**，就等於是改了好多地方的**，好處是顯然的。
當然，然後出現了類和物件，其實也不過是抽象的繼續發展，不過這次更深刻，人們從機器裡面的按部就班的死板的程式流程中看出了結構，一種和現實世界很多關係相同的結構。人們發現，某些**和某些資料是為了完成相同的功能而存在的，於是把他們放在一起，叫做乙個類。還有等等一整套的結構。這是比函式更高一級的抽象。
談到設計模式的時候呢，物件導向的那一套什麼類，繼承，多型什麼的東西就只能說是元素了。人們使用這些元素，把他們按照一定的結構組裝起來，讓他們協同工作，實現我們想要的功能和擴充套件效能。而設計模式便是對這一結構的抽象，因為抽象就是從一些結構相同的東西裡面把那個結構拿出來，所以設計模式裡面只是一些物件之間的關係，與語言無關。
以後軟體會怎麼發展呢，下一代更高階的抽象是怎麼樣的呢，難道把設計模式當作元素，拿來構造，然後定義一種方法描述不同模式之間的關係和結構？就現在看來好象不太可能。更可能的倒是元件，只要對介面進行詳細的規定，大家遵守乙個標準，用元件來構造軟體應該是有可能的吧，也許再出來一種描述語言來描述元件之間的結構：） 。不過還是覺得太不現實，不太可能。算了 不想它了。
下次來談談具體的模式吧。
設計模式學習筆記（1）
概述部分 一 設計模式的概念 1 設計模式包括4個基本要素 模式名稱 問題 解決方案 效果。2 如何描述設計模式 模式名和分類 意圖 該設計模式是做什麼的，它的基本原理和意圖是什麼，它解決的是什麼樣的特定設計問題 別名 其它名稱 動機 提出乙個設計問題，並且用該模式中的類 物件來描述如何解決此問題 ...
設計模式學習筆記 1
針對介面程式設計，而不是針對實現程式設計 優先使用物件組合，而不是類繼承 分裝變化點 使用重構得到模式 不要把設計模式當成技巧 單一職責原則 乙個類應該僅有乙個引起它變化的原因。file fileinfo 開發封閉原則 類模組應該是可擴充套件的，但不可修改的 對擴充套件開放，對更改封閉 為什麼不可修...
設計模式學習筆記（1） 單利模式
1 package designpatterns 23 public class singleton 1213 建立乙個靜態的方法獲取例項物件 1415 public static singleton getsingletonobj 2223 return uniqueinstance 2425 2...