【轉載】自動化測試體系整體解決方案探討
摘要: 一個完整的自動化測試框架體系包含以下幾個部分:1、自動化測試框架;2、測試腳本以及測試數據管理;3、測試腳本的執行管理系統;4、測試結果的顯示與分析系統。其中最重要的是自動化測試框架部分。 閱讀全文posted @ 2011-08-30 18:59 XXXXXX 閱讀(349) | 評論 (0) | 編輯 收藏
2011年2月13日 #
posted @ 2011-08-30 18:59 XXXXXX 閱讀(349) | 評論 (0) | 編輯 收藏
posted @ 2011-08-30 17:29 XXXXXX 閱讀(349) | 評論 (0) | 編輯 收藏
posted @ 2011-08-29 11:41 XXXXXX 閱讀(1846) | 評論 (1) | 編輯 收藏
posted @ 2011-08-28 23:47 XXXXXX 閱讀(330) | 評論 (0) | 編輯 收藏
posted @ 2011-08-23 13:25 XXXXXX 閱讀(391) | 評論 (0) | 編輯 收藏
posted @ 2011-08-23 09:25 XXXXXX 閱讀(358) | 評論 (0) | 編輯 收藏
posted @ 2011-08-19 23:24 XXXXXX 閱讀(1391) | 評論 (0) | 編輯 收藏
posted @ 2011-08-16 23:12 XXXXXX 閱讀(286) | 評論 (0) | 編輯 收藏
posted @ 2011-08-13 10:14 XXXXXX 閱讀(506) | 評論 (0) | 編輯 收藏
posted @ 2011-08-12 14:49 XXXXXX 閱讀(1213) | 評論 (0) | 編輯 收藏
posted @ 2011-07-31 08:53 XXXXXX 閱讀(246) | 評論 (0) | 編輯 收藏
posted @ 2011-07-29 11:53 XXXXXX 閱讀(259) | 評論 (0) | 編輯 收藏
posted @ 2011-07-25 11:42 XXXXXX 閱讀(310) | 評論 (0) | 編輯 收藏
posted @ 2011-07-21 23:25 XXXXXX 閱讀(251) | 評論 (0) | 編輯 收藏
posted @ 2011-07-21 09:21 XXXXXX 閱讀(214) | 評論 (0) | 編輯 收藏
posted @ 2011-07-15 22:30 XXXXXX 閱讀(313) | 評論 (0) | 編輯 收藏
posted @ 2011-07-10 10:08 XXXXXX 閱讀(2612) | 評論 (0) | 編輯 收藏
posted @ 2011-07-09 09:38 XXXXXX 閱讀(240) | 評論 (0) | 編輯 收藏
posted @ 2011-07-08 09:37 XXXXXX 閱讀(1573) | 評論 (0) | 編輯 收藏
posted @ 2011-06-18 15:25 XXXXXX 閱讀(688) | 評論 (1) | 編輯 收藏
看看 project euler 的第一道題:
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.
用 python 語言寫出來是:
posted @ 2011-06-17 20:26 XXXXXX 閱讀(4384) | 評論 (2) | 編輯 收藏
This is the first edition of what is expected to become a recurring series on InfoQ. The idea behind this minibook is that a number of InfoQ articles and interviews which deal with a particular topic (in this case, REpresentational State Transfer, or REST) are combined together to provide a detailed exploration suitable for both beginners and advanced practitioners.
Read More: http://www.infoq.com/minibooks/emag-03-2010-rest;jsessionid=1E2375E822D980824403DAD46588FAFE
posted @ 2011-06-15 12:39 XXXXXX 閱讀(247) | 評論 (0) | 編輯 收藏
#定義:如果在一個內部函數里,對在外部作用域(但不是在全局作用域)的變量進行引用,那么內部函數就被認為是閉包(closure)
分解來說,包含下面3個條件:
1) 需要函數嵌套, 就是一個函數里面再寫一個函數.
2) 外部函數需要返回一個內部函數的引
3) 外部函數中有一些局部變量, 并且, 這些局部變量在內部函數中有使用
一些概念:
1)自由變量: 外部函數中定義的局部變量, 并且在內部函數中被使用
2) 閉包: 那個使用了自由變量并被返回的內部函數就稱為閉包
#支持閉包的語言有這樣的特性:
1)函數是一階值(First-class value),即函數可以作為另一個函數的返回值或參數,還可以作為一個變量的值
2)函數可以嵌套定義,即在一個函數內部可以定義另一個函數
#代碼示例
posted @ 2011-06-15 07:31 XXXXXX 閱讀(1307) | 評論 (0) | 編輯 收藏
posted @ 2011-06-14 16:57 XXXXXX 閱讀(1083) | 評論 (0) | 編輯 收藏
posted @ 2011-06-12 23:58 XXXXXX 閱讀(299) | 評論 (0) | 編輯 收藏
posted @ 2011-06-06 16:03 XXXXXX 閱讀(337) | 評論 (0) | 編輯 收藏
posted @ 2011-06-04 16:08 XXXXXX 閱讀(243) | 評論 (0) | 編輯 收藏
posted @ 2011-06-04 16:08 XXXXXX 閱讀(262) | 評論 (0) | 編輯 收藏
posted @ 2011-06-04 15:54 XXXXXX 閱讀(290) | 評論 (0) | 編輯 收藏
posted @ 2011-06-04 15:43 XXXXXX 閱讀(260) | 評論 (0) | 編輯 收藏
posted @ 2011-06-04 10:44 XXXXXX 閱讀(289) | 評論 (0) | 編輯 收藏
posted @ 2011-06-02 11:00 XXXXXX 閱讀(272) | 評論 (0) | 編輯 收藏
posted @ 2011-06-01 14:52 XXXXXX 閱讀(339) | 評論 (0) | 編輯 收藏
posted @ 2011-05-31 11:06 XXXXXX 閱讀(547) | 評論 (0) | 編輯 收藏
posted @ 2011-05-31 09:31 XXXXXX 閱讀(289) | 評論 (0) | 編輯 收藏
posted @ 2011-05-30 08:10 XXXXXX 閱讀(701) | 評論 (0) | 編輯 收藏
posted @ 2011-05-29 10:20 XXXXXX 閱讀(261) | 評論 (1) | 編輯 收藏
posted @ 2011-05-29 09:48 XXXXXX 閱讀(284) | 評論 (1) | 編輯 收藏
By James Whittaker
I’ve had a number of questions about the SET role and it seems I have confused folks when I say that the SWE is a tester and the SET is a tester and at the same time the SWE is a developer and the SET is a developer. What could possibly be confusing about that?
Oh, yeah. Right.
My next series of posts are going to detail the role of the SET and all will eventually be clear but some clarification on career path seems worthwhile.
SETs are developers who write test code and automation as their primary task. They are in every sense of the word a developer. When we interview SETs, SWEs are on the interview loop and SWE questions are asked. They are not all of the interview, but they are part of it.
This means that the skill set that our SETs possess makes them perfect candidates for switching to the SWE role. There is neither incentive nor deterrent to do so. SETs and SWEs are on the same pay scale and bonus structure (I have both roles reporting to me so I have real visibility into salary data) and their promotion velocity (again based on actual data) is roughly equivalent. This means that SETs have no outside influences to prompt them one way or the other.
The key factor is really the type of work you are doing. SETs who find themselves involved in SWE work usually convert to SWE. SWEs are also drawn in the opposite direction. Much of this happens through our 20% time work. Any SET interested in SWE work can take on a 20% task doing feature development. Any SWE interested in automation can find a group and sign up for a 20%. Right now I have both SWEs and SETs involved in such cross pollination.
The ideal situation is that the title reflects the actual work that you are involved in. So if an SET starts doing more feature dev work than automation, he or she should convert, same for SWEs doing automation work. In my time here, conversions in both directions have happened, but it is not all that common. The work of both roles is engaging, interesting and intense. Few Googlers are walking around bored.
Bottom line: do the work you are passionate about and capable of and the right job title will find you.
posted @ 2011-05-25 00:04 XXXXXX 閱讀(280) | 評論 (0) | 編輯 收藏
posted @ 2011-05-24 16:54 XXXXXX 閱讀(1625) | 評論 (1) | 編輯 收藏
記錄關于REST的一些技術:
1、REST簡介:http://zh.wikipedia.org/zh/REST
2、InfoQ 深入淺出REST: http://www.infoq.com/cn/articles/rest-introduction
posted @ 2011-05-10 22:07 XXXXXX 閱讀(319) | 評論 (0) | 編輯 收藏
posted @ 2011-05-10 22:02 XXXXXX 閱讀(425) | 評論 (0) | 編輯 收藏
posted @ 2011-05-07 15:35 XXXXXX 閱讀(645) | 評論 (0) | 編輯 收藏
posted @ 2011-05-07 15:10 XXXXXX 閱讀(256) | 評論 (0) | 編輯 收藏
posted @ 2011-05-07 09:58 XXXXXX 閱讀(181) | 評論 (0) | 編輯 收藏
posted @ 2011-04-29 22:36 XXXXXX 閱讀(365) | 評論 (0) | 編輯 收藏
posted @ 2011-04-28 11:59 XXXXXX 閱讀(225) | 評論 (0) | 編輯 收藏
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
posted @ 2011-04-18 09:10 XXXXXX 閱讀(351) | 評論 (0) | 編輯 收藏
posted @ 2011-04-05 10:34 XXXXXX 閱讀(431) | 評論 (0) | 編輯 收藏
posted @ 2011-04-04 00:08 XXXXXX 閱讀(1147) | 評論 (0) | 編輯 收藏
posted @ 2011-03-22 20:23 XXXXXX 閱讀(473) | 評論 (3) | 編輯 收藏
dstat -ta --output osstat.csv
posted @ 2011-03-17 00:19 XXXXXX 閱讀(798) | 評論 (0) | 編輯 收藏
1. 安裝JDK
http://wiki.ubuntu.org.cn/Java%E5%AE%89%E8%A3%85%E9%85%8D%E7%BD%AE
2. 安裝Python
1). apt-get install python
2). PyDev for eclipse:
Name:PyDev,Location:http://pydev.org/updates
Ref:http://www.cnblogs.com/Realh/archive/2010/10/10/1847251.html
3. 安裝dstat--性能監測工具
apt-get install dstat
posted @ 2011-03-16 19:46 XXXXXX 閱讀(218) | 評論 (0) | 編輯 收藏
下面是來自 Taobao QA Team中的安全測試方面的文章,對初學者很有指導意義
安全測試學習筆記系列:
1. http://qa.taobao.com/?p=11352
2.http://qa.taobao.com/?p=11363
3.http://qa.taobao.com/?p=11472
4.http://qa.taobao.com/?p=11479
5.http://qa.taobao.com/?p=11484
------
WEB漏洞攻擊之SQL注入:http://qa.taobao.com/?p=11403
posted @ 2011-03-15 15:54 XXXXXX 閱讀(383) | 評論 (0) | 編輯 收藏
posted @ 2011-03-09 15:59 XXXXXX 閱讀(214) | 評論 (0) | 編輯 收藏
數組類Array是Java中最基本的一個存儲結構。它用于存儲一組連續的對象或基本類型的數據。其中的元素的類型必須相同。
Array是最有效率的一 種:
1、效率高,但容量固定且無法動態改變。 Array還有一個缺點是,無法判斷其中實際存有多少元素,length只是告訴我們Array的容量。
2、Java中有一個Arrays類,專門用來操作Array,提供搜索、排序、復制等靜態方法。 equals():比較兩個Array是否相等,Array擁有相同元素個數,且所有對應元素兩兩相等。 fill():將值填入Array中。 sort():用來對Array進行排序。 binarySearch():在排好序的Array中尋找元素。 System.arraycopy():Array的復制。
Java Collections Framework成員主要包括兩種類型,即:Collection和Map類型。 在Java中提供了Collection和Map接口。其中List和Set繼承了Collection接口;Vector、ArrayList、 LinkedList三個類實現List接口,HashSet、TreeSet實現Set接口,HashTable、HashMap、 TreeMap實現Map接口。由此可見,Java中用8種類型的基本數據結構來實現其Collections Framework;下面分別進行介紹。
Vector:基于Array的List,性能也就不可能超越Array,并且Vector是"sychronized"的,這個也是Vector和ArrayList的唯一的區別。
ArrayList:同Vector一樣是一個基于Array的,但是不同的是ArrayList不是同步的。所以在性能上要比Vector優越一些,但 是當運行到多線程環境中時,可需要自己在管理線程的同步問題。從其命名中可以看出它是一種類似數組的形式進行存儲,因此它的隨機訪問速度極快。
LinkedList:LinkedList不同于前面兩種List,它不是基于Array的,所以不受Array性能的限制。它每一個節點(Node) 都包含兩方面的內容:
1、節點本身的數據(data);
2、下一個節點的信息(nextNode)。所以當對LinkedList做添加,刪除動作的時候 就不用像基于Array的List一樣,必須進行大量的數據移動。只要更改nextNode的相關信息就可以實現了所以它適合于進行頻繁進行插入和刪除操 作。這就是LinkedList的優勢。Iterator只能對容器進行向前遍歷,而 ListIterator則繼承了Iterator的思想,并提供了對List進行雙向遍歷的方法。
List總結:
1、所有的List中只能容納單個不同類型的對象組成的表,而不是Key-Value鍵值對。例如:[ tom,1,c ];
2、所有的List中可以有相同的元素,例如Vector中可以有 [ tom,koo,too,koo ];
3、所有的List中可以有null元素,例如[ tom,null,1 ];
4、基于Array的List(Vector,ArrayList)適合查詢,而LinkedList(鏈表)適合添加,刪除操作。
HashSet:雖然Set同List都實現了Collection接口,但是他們的實現方式卻大不一樣。List基本上都是以Array為基礎。但是 Set則是在HashMap的基礎上來實現的,這個就是Set和List的根本區別。HashSet的存儲方式是把HashMap中的Key作為Set的 對應存儲項,這也是為什么在Set中不能像在List中一樣有重復的項的根本原因,因為HashMap的key是不能有重復的。HashSet能快速定位 一個元素,但是放到HashSet中的對象需要實現hashCode()方法0。
TreeSet則將放入其中的元素按序存放,這就要求你放入其中的對象是可排序的,這就用到了集合框架提供的另外兩個實用類Comparable和 Comparator。一個類是可排序的,它就應該實現Comparable接口。有時多個類具有相同的排序算法,那就不需要重復定義相同的排序算法,只要實現Comparator接口即可。TreeSet是SortedSet的子類,它不同于HashSet的根本就是TreeSet是有序的。它是通過SortedMap來實現的。
Set總結:
1、Set實現的基礎是Map(HashMap);
2、Set中的元素是不能重復的,如果使用add(Object obj)方法添加已經存在的對象,則會覆蓋前面的對象; Set里的元素是不能重復的,那么用什么方法來區分重復與否呢? 是用==還是equals()? 它們有何區別? Set里的元素是不能重復的,即不能包含兩個元素e1、e2(e1.equals(e2))。那么用iterator()方法來區分重復與否。 equals()是判讀兩個Set是否相等。==方法決定引用值(句柄)是否指向同一對象。
HashMap、TreeMap、Hashtable:
1、HashMap也用到了哈希碼的算法,以便快速查找一個鍵,TreeMap則是對鍵按序存放,因此它有一些擴展的方法,比如 firstKey(),lastKey()等。
2、Hashtable:不允許空(null)鍵(key)或值(value),Hashtable的方法是Synchronize的,在多個線程訪問 Hashtable時,不需要自己為它的方法實現同步,而HashMap 就必須為之提供外同步。 Hashtable和HashMap采用的hash/rehash算法都大概一樣,所以性能不會有很大的差異。
3、HashMap和Hashtable的區別:HashMap是Hashtable(線程案例的)的輕量級實現(非線程安全的實現),他們都完成了Map接口。主要區別在于HashMap允許空(null)鍵(key)或值(value),非同步,由于非線程安全,效率上可能高于Hashtable。
Map總結:
是一種把鍵對象和值對象進行關聯的容器,Map有兩種比較常用的實現: HashTable、HashMap和TreeMap。
posted @ 2011-03-07 14:25 XXXXXX 閱讀(1582) | 評論 (0) | 編輯 收藏
posted @ 2011-03-05 20:40 XXXXXX 閱讀(14553) | 評論 (0) | 編輯 收藏
posted @ 2011-03-05 15:37 XXXXXX 閱讀(983) | 評論 (1) | 編輯 收藏
BJ Rolison (I.M.Testy) http://blogs.msdn.com/imtesty
BJ是微軟負責EE工作的Test Architecture,也是HWTSaM的作者。他的文章非常有條理,看起來也比較容易,其中的數據也非常豐富,是我喜歡的風格。
Alan Page http://blogs.msdn.com/alanpa/ Google Test Blog http://googletesting.blogspot.com Adam Goucher的博客 http://adam.goucher.ca/
Alan是微軟負責EE工作的Director,是HWTSaM的主要作者,他的博客是了解微軟測試非常好的一個窗口。最近幾年,他不限于測試技術的推廣,他更多的考慮是測試管理,以及測試氛圍/文化的形成,以及對于測試的影響。我很同意他的一句話“95%的UI自動化測試都是浪費時間”詳情。他的博客文章比較隨意,有時也不知道他在嘮叨些什么,但不時卻有很多精彩的觀點。
這是Google官方的測試博客,信息量很少,除了每年一次的Google Automation Test Conference之外,文章較少。今年6月,James Whittaker離開微軟,加入Google后,才到這里增加不少好文章。
James Bach的博客 http://www.satisfice.com/blog/
James是一個軟件測試的資深人士,90年代曾在Apple和Boland公司???過測試管理工作,后來在其他一些公司負責測試流程和質量管理,2000年自己創辦了satisfice測試咨詢公司,提供軟件質量保證相關的咨詢和培訓. 他和Cem Kaner撰寫了很多Explorary Testing相關的文章和書籍,并且提出了Context-Driven-Testing,這些方法論很適合現在的Agile Testing的特點。
一個多產高質的測試寫作專家,基本上每個月都有10多篇關于測試的文章,有時候一天寫了多篇,真是非常佩服他的寫作能力。他的思想很有深度,對軟件測試各個方面都有全面的理解,他閱讀了幾乎所有新出的測試書籍,并且些了與其相關的評論。這些評論通常非常尖銳。比如說,HWTSaM的評論,他的評論就比較中肯。對James Whittalkes的 Exploratory Testing評論 卻是嗤之以鼻。
軟件測試雜文集:http://blogs.msdn.com/b/cheno/
文章轉自:http://www.cesoo.com/
posted @ 2011-03-05 12:16 XXXXXX 閱讀(206) | 評論 (0) | 編輯 收藏
一、寫在前面 創建模式 結構模式 行為模式 簡單工廠模式 適配器模式 不變模式 工廠方法模式 缺省適配模式 策略模式 抽象工廠模式 合成模式 模版方法模式 單例模式 裝飾模式 觀察者模式 多例模式 代理模式 迭代子模式 建造模式 享元模式 責任鏈模式 原始模型模式 門面模式 命令模式 橋梁模式 備忘錄模式 狀態模式 訪問者模式 解釋器模式 調停者模式 模式 定義 描述 裝飾者 動態地將責任附加到對象上。若要擴展功能,裝飾者提供了比繼承更有彈性的替代方案 包裝一個對象,以提供新的行為 狀態 允許對象在內部狀態改變時改變它的行為,對象看起來好像修改了它的類 封裝了基本狀態的行為,并使用委托在行為之間切換 迭代器 提供一種方法順序訪問一個聚合對象中的各個元素,而又不暴露其內部的表示 在對象的集合之中游走,而不暴露集合的實現 外觀(門面) 提供一個統一的接口,用來訪問子系統中的一群接口。外觀定義了一個高層接口,讓子系統更多容易使用 簡化一群類的接口 策略 定義算法族,分別封裝起來,讓它們之間可以互相替換,此模式讓算法的變化獨立于使用算法的客戶 封裝可以互換的行為,并使用委托來決定使用那一種 代理 為另一個對象提供一個替身或點位符以訪問這個對象 包裝對象,以控制對此對象的訪問 工廠方法 定義了一個創建對象的接口,但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類 由子類決定要創建是具體類是哪一個 抽象工廠 提供一個接口,用于創建相關或依賴對象的家族,而不需要明確指定具體類 允許客戶創建對象的家族,而無需指定他們的具體類 適配器 將一個類的接口,轉換成客戶期望另一個接口。適配器讓原來不兼容的類可以合作無間 封裝對象,并提供不同的接口 觀察者 在對象之間定義一對多的依賴,這樣一來,當一個對象改變時,依賴它的對象都會收到通知并自動更新 讓對象能夠在狀態改變時被通知 模板方法 在一個方法中定義一個算法的骨架,而將一些步驟延遲到子類中。模板方法使得子類可以在不改變算法結構的情況下,重新定義算法中的某些步驟 由子類決定如何實現一個算法中的步驟 組合 允許你將對象組成樹結構來表現“整體/部分”的層次結構。組合能讓客戶以一致的方式處理個別對象和對象組合 客戶用一致的方式處理對象集合和單個對象 單件(單體) 確保一個類只有一個實例,并提供全局訪問點 確保只有一個對象被創建 命令 將請求封裝成對象,這可以讓你使用不同的請求、隊列,或者日志請求來參數化其它對象。命令模式也可以支持撤銷操作 封裝請求為對象
剛開學,趁著有時間把設計模式重新整理一次。學好設計模式是走向架構的第一步,系統架構應該朝著可維護,可擴展,強壯性好的方向去發展。大學的最后一個學期了,時間不多了,3月初就要去騰訊實習了,還有畢設。加油 :)
二、常見的模式分類
三、主要模式的定義和描述
以下內容來自《head first 設計模式》一書
四、參考資料
IBM社區設計模式方面資料: http://www.ibm.com/developerworks/cn/java/design/
常見OO原則:http://m.tkk7.com/jicheng687/archive/2011/02/13/344174.html
posted @ 2011-02-21 23:40 XXXXXX 閱讀(3156) | 評論 (0) | 編輯 收藏
今天無意中看到InfoQ(http://www.infoq.com/cn/architect)這個網站,里面的內容很不錯,介紹的內容算是國內最先進的的,有興趣的朋友可以看看
posted @ 2011-02-15 17:16 XXXXXX 閱讀(232) | 評論 (0) | 編輯 收藏
posted @ 2011-02-15 10:33 XXXXXX 閱讀(226) | 評論 (0) | 編輯 收藏
一、在單元測試領域里,JUnit可以說是王者,它不但精致,而且使用方便。最后有些時間,把JUnit源碼讀讀,順便復習下設計模式 :)
二、參考文章
在深入看代碼之前,先看下面的文章,對JUnit有一個基本的了解后,看代碼會更有目的性。
JUnit官方網站:http://www.junit.org/
分析 JUnit 框架源代碼: http://www.ibm.com/developerworks/cn/java/j-lo-junit-src/
JUnit A cook's tour: http://junit.sourceforge.net/doc/cookstour/cookstour.htm
三、核心架構
我分析的源碼的版本是JUnit 3.8.2,這個版本相對簡略,把核心思想表現出來了,沒有4.X版本那么多附加的功能
JUnit是一個模式密集型的框架,主要用組合模式、模樣方法、觀察者模式、參數收集方法、命令模式、裝飾者模式和適配器模式。其中核心是 前三種
核心類之間的關系
Test、TestCase和TestSuit構成了測試框架的基礎,它們用composite模式組合在一起,使得客戶端可以將對象的集合以及個別的對象(TestCase)一視同仁.TestRusult用來保存測試結果,和TestListner組成observer模式,支持文本界面、圖形界面和 Eclipse 集成組件三種監聽器
和JUnit A cook's tour中提到的模式圖很相似
類與類之間的關系在此就不作解釋了,可以看看參考文章。有興趣的朋友,歡迎一起討論 :)
posted @ 2011-02-13 17:09 XXXXXX 閱讀(382) | 評論 (0) | 編輯 收藏
封裝變化
多用組合,少用繼承
針對接口編程,不針對實現編程
為交互對象之間的松耦合設計而努力
類應該對擴展開放,對修改關閉
只和朋友交談
別找我,我會找你
類應該只有一個改變的理由
posted @ 2011-02-13 10:23 XXXXXX 閱讀(501) | 評論 (0) | 編輯 收藏