from http://www.code365.com/web/122/Article/17927.Asp

Thomas Bayes，一位偉大的數學大師，他的理論照亮了今天的計算領域，和他的同事們不同：他認為上帝的存在可以通過方程式證明，他最重要的作品被別人發(fā)行，而他已經去世241年了。

18世紀牧師們關于概率的理論成為應用發(fā)展的數學基礎的一部分。

搜索巨人Google和Autonomy，一家出售信息恢復工具的公司，都使用了貝葉斯定理（Bayesian principles）為數據搜索提供近似的（但是技術上不確切）結果。研究人員還使用貝葉斯模型來判斷癥狀和疾病之間的相互關系，創(chuàng)建個人機器人，開發(fā) 能夠根據數據和經驗來決定行動的人工智能設備。

雖然聽起來很深奧，而這個原理的意思--大致說起來--卻很簡單：某件事情發(fā)生的概率大致可以由它過去發(fā)生的頻率近似地估計出來。研究人員把這個原理應用在每件事上，從基因研究到過濾電子郵件。

在明尼蘇達州大學的網站上能夠找到一份詳細的數學概要。而在Gametheory.net上的一個Bayes Rule Applet程序讓你能夠回答諸如“如果你測試某種疾病，有多大風險”之類的問題。

貝葉斯理論的一個出名的倡導者就是微軟。該公司把概率用于它的Notification Platform。該技術將會被內置到微軟未來的軟件中，而且讓計算機和蜂窩電話能夠自動地過濾信息，不需要用戶幫助，自動計劃會議并且和其他人聯(lián)系。

如果成功的話，該技術將會導致“context server”--一種電子管家的出現，它能夠解釋人的日常生活習慣并在不斷變換的環(huán)境中組織他們的生活。

“Bayes的研究被用于決定我應該怎樣最好地分配計算和帶寬，” Eric Horvitz表示，他是微軟研究部門Adaptive Systems & Interaction Group的高級研究員和分組管理者。“我個人相信在這個不確定的世界里，你不能夠知道每件事，而概率論是任何智能的基礎。”

到今年年底，Intel也將發(fā)布它自己的基于貝葉斯理論的工具包。一個關于照相機的實驗警告醫(yī)生說病人可能很快遭受痛苦。在本周晚些時候在該公司的Developer Forum（開發(fā)者論壇）上將討論這種發(fā)展。

雖然它在今天很流行，Bayes的理論并不是一直被廣泛接受的：就在10年前，Bayes研究人員還在他們的專業(yè)上躊躇不前。但是其后，改進的數學模型，更快的計算機和實驗的有效結果增加了這種學派新的可信程度。

“問題之一是它被過度宣傳了，” Intel微處理器實驗室的應用軟件和技術管理經理Omid Moghadam表示。“事實上，能夠處理任何事情的能力并不存在。真正的執(zhí)行在過去的10年里就發(fā)生了。”

Bayes啞元
Bayes的理論可以粗略地被簡述成一條原則：為了預見未來，必須要看看過去。Bayes的理論表示未來某件事情發(fā)生的概率可以通過計算它過去發(fā)生的頻率來估計。一個彈起的硬幣正面朝上的概率是多少？實驗數據表明這個值是50%。

“Bayes表示從本質上說，每件事都有不確定性，你有不同的概率類型，”斯坦佛的管理科學和工程系（Department of Management Science and Engineering at Stanford）的教授Ron Howard表示。

例如，假設不是硬幣，一名研究人員把塑料圖釘往上拋，想要看看它釘頭朝上落地的概率有多大，或者有多少可能性是側面著地，而釘子是指向什么方向的。形狀，成型過程中的誤差，重量分布和其他的因素都會影響該結果。

Bayes技術的吸引力在于它的簡單性。預測完全取決于收集到的數據--獲得的數據越多，結果就越好。另一個優(yōu)點在于Bayes模型能夠自我糾正，也就是說數據變化了，結果也就跟著變化。

概率論的思想改變了人們和計算機互動的方式。“這種想法是計算機能夠更象一個幫助者而不僅僅是一個終端設備，” Peter Norvig表示。他是Google的安全質量總監(jiān)。他說“你在尋找的是一些指導，而不是一個標準答案。”

從這種轉變中，研究獲益非淺。幾年前，所謂的Boolean搜索引擎的一般使用需要把搜索按照“if, and, or but”的語法進行提交，然后去尋找匹配的詞。現在的搜索引擎采用了復雜的運算法則來搜索數據庫，并找出可能的匹配。

如同圖釘的那個例子顯示的那樣，復雜性和對于更多數據的需要可能很快增長。由于功能強大的計算機的出現，對于把好的猜測轉變成近似的輸出所必須的結果進行控制成為可能。

更重要的是，UCLA的Judea Pearl這樣的研究人員研究出如何讓Bayes模型能夠更好地追蹤不同的現象之間條件關系的方法，這樣能夠極大地減少計算量。

例如，對于人口進行大規(guī)模的關于肺癌成因的調查可能會發(fā)現它是一種不太廣泛的疾病，但是如果局限在吸煙者范圍內進行調查就可能會發(fā)現一些關聯(lián)性。對于肺癌患者進行檢查能夠幫助調查清楚習慣和這種疾病之間的關系。

“每一個單獨的屬性或者征兆都可能取決于很多不同的事情，但是直接決定它的卻是為數不多的事情，”斯坦佛計算機科學系（computer science department at Stanford）的助理教授Daphne Koller表示。“在過去的15年左右的時間里，人們在工具方面進行了改革，這讓你能夠描繪出大量人群的情況。”

和其他一些項目一樣，Koller是使用概率論技術來更好地把病癥和疾病聯(lián)系起來，并把遺傳基因和特定的細胞現象聯(lián)系起來。

記錄演講
一項相關的技術，名為Hidden Markov模型，讓概率能夠預測次序。例如，一個演講識別應用知道經常在“q”之后的字母是“u”。除了這些，該軟件還能夠計算“Qagga”（一種滅絕了的斑馬的名稱）一詞出現的概率。

概率技術已經內置在微軟的產品中了。Outlook Mobile Manage是一個能夠決定什么時候往移動設備上發(fā)出一封內勤的電子郵的軟件。它是從Priorities發(fā)展而來的，Priorities是微軟在 1998年公布的一個實驗系統(tǒng)。Windows XP的故障檢修引擎也依賴于概率計算。

隨著該公司的Notification Platform開始內置在產品中，在未來的一年中會有更多的應用軟件發(fā)布，微軟的Horvitz這樣表示。

Notification Platform的一個重要組成部分名為Coordinate，它從個人日歷，鍵盤，傳感器照相機以及其他來源收集數據，來了解某個人生活和習慣。收集的 數據可能包括到達的時間，工作時間和午餐的時間長度，哪種類型的電話或電子郵件被保存，而哪些信息被刪除，在某天的特定時間里鍵盤被使用的頻率，等等。

這些數據可以被用來管理信息流和使用者收到的其他信息。例如，如果一位經理在下午2：40發(fā)送了一封電子郵件給一名員工， Coordinate可以檢查該員工的日歷程序，然后發(fā)現他在下午2：00有一個會議。該程序還可以掃描關于該員工習慣的數據，然后發(fā)現該員工通常會在有 會議之后大約一個小時才重新使用鍵盤。該程序可能還能夠發(fā)現該名員工通常會在5分鐘之內回復該經理的電子郵件。根據上面這些數據，該軟件能夠估計出該員工 可能至少在20分鐘之內不可能回復該電子郵件，該軟件可能會把這條信息發(fā)送到該員工的手提電話上。同時，該軟件可能會決定不把別人的電子郵件也轉發(fā)出去。

“我們正在平衡以打攪你為代價所獲得信息的價值，” Horvitz表示。使用這個軟件，他堅持道，“能夠讓更多的人跟上事情的發(fā)展，而不被大量的信息所淹沒。”

Horvitz補充道，隱私和對于這些功能的用戶控制是確定的。呼叫者并不知道為什么一條信息可能會被優(yōu)先或推遲處理。

微軟還把Bayes模型使用在其他的一些產品上，包括DeepListener 以及Quartet （語音激活），SmartOOF 以及TimeWave （聯(lián)系控制）。消費者多媒體軟件也獲益非淺，Horvitz表示。

Bayes技術不僅僅被應用在PC領域。在University of Rochester，研究人員發(fā)現一個人的步伐可以在一步前發(fā)生改變。雖然這種改變對于人類來說太過于細微，一臺和電腦連接在一起的照相機可以捕捉并跟蹤 這種動作。如果行走異常出現，計算機就能夠發(fā)出警報。

一個實驗用的安全照相機采用了同樣的原理：大部分到達機場的人都會在停車以后直接走向目的地，所以如果有人停了車，然后走向另一輛車就不太正常，因此就可能引發(fā)警報。今年秋天一個創(chuàng)建Bayes模型和技術信息的基本引擎將會公布在Intel的開發(fā)者網站上。

理論沖突
雖然該技術聽起來簡單易懂，關于它的計算可能卻比較慢。Horvitz回憶說他是斯坦佛20世紀80年代僅有的兩個概率和人工智能的畢業(yè)生之一。其他所有的人學習的是邏輯系統(tǒng)，采用的是“if and then”的模式和世界互動。

“概率論那時候不流行，” Horvitz表示。但是當邏輯系統(tǒng)不能夠預測所有的意外情況時，潮流發(fā)生了轉變。

很多研究人員開始承認人類的決策過程比原來想象的要神秘的多。“在人工智能領域存在著文化偏見，” Koller表示。“人們現在承認他們并不知道他們的腦子是如何工作的。”

即便在他的時代，Bayes發(fā)現他自己置身于主流之外。他于1702年出生于倫敦，后來他成為了一名Presbyterian minister。雖然他看到了自己的兩篇論文被發(fā)表了，他的理論很有效，但是《Essay Toward Solving a Problem in the Doctrine of Chances》卻一直到他死后的第三年，也就是1764年才被發(fā)表。

他的王室成員身份一直是個謎，直到最近幾年，新發(fā)現的一些信件表明他私下和英格蘭其他一些思想家看法一致。

“就我所知，他從來沒有寫下貝葉斯定理，” Howard表示。

神學家Richard Price和法國的數學家Pierre Simon LaPlace成為了早期的支持者。該理論和后來George Boole，布爾數學之父，的理論背道而馳。George Boole的理論是基于代數邏輯的，并最終導致了二進制系統(tǒng)的誕生。也是皇室成員之一的Boole死于1864年。

雖然概率的重要性不容置疑，可是關于它的應用的爭論卻沒有停止過。批評者周期性地聲稱Bayes模型依賴于主觀的數據，而讓人類去判斷答案是否正確。而概率論模型沒有完全解決在人類思維過程中存在的細微差別的問題。

“兒童如何學習現在還不是很清楚，”IBM研究部門的科學和軟件副總裁 Alfred Spector這樣表示。他計劃把統(tǒng)計學方法和邏輯系統(tǒng)在他的Combination Hypothesis之中結合起來。“我最初相信是統(tǒng)計學的范疇，但是從某方面說，你將會發(fā)現不僅僅是統(tǒng)計學的問題。”

但是，很有可能概率論是基礎。

“這是個基礎，” Horvitz表示。“它被忽略了一段時間，但是它是推理的基礎。”

最近在看< 敏捷軟件開發(fā)：原則、模式與實踐 >在網上找了一些資料,就把他們集合到了一起,便于自己學習

此篇內容來自一下兩處

http://blog.joycode.com/microhelper/archive/2004/11/30/40013.aspx

http://www.tkk7.com/ghawk/

另:關于面向對象設計的原則比較權威的是Uncle Bob-- Robert C. Martin的

Principles Of Object Oriented Design

http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign


單一職責原則——SRP
就一個類而言，應該僅有一個引起它的變化的原因

開放封閉原則——OCP
軟件實體（類，模塊，函數）應該是可以擴展的，但是不可修改的

開閉原則很簡單，一句話：“Closed for Modification; Open for Extension”——“對變更關閉；對擴展開放”。開閉原則其實沒什么好講的，我將其歸結為一個高層次的設計總則。就這一點來講，OCP的地位應該比SRP優(yōu)先。

OCP的動機很簡單：軟件是變化的。不論是優(yōu)質的設計還是低劣的設計都無法回避這一問題。OCP說明了軟件設計應該盡可能地使架構穩(wěn)定而又容易滿足不同的需求。

為什么要OCP？答案也很簡單——重用。

“重用”，并不是什么軟件工程的專業(yè)詞匯，它是工程界所共用的詞匯。早在軟件出現前，工程師們就在實踐“重用”了。比如機械產品，通過零部 件的組裝得到最終的能夠使用的工具。由于機械部件的設計和制造過程是極其復雜的，所以互換性是一個重要的特性。一輛車可以用不同的發(fā)動機、不同的變速箱、 不同的輪胎……很多東西我們直接買來裝上就可以了。這也是一個OCP的例子。（可能是由于我是搞機械出身的吧，所以就舉些機械方面的例子^_^）。

如何在OO中引入OCP原則？把對實體的依賴改為對抽象的依賴就行了。下面的例子說明了這個過程：

05賽季的時候，一輛F1賽車有一臺V10引擎。但是到了06賽季，國際汽聯(lián)修改了規(guī)則，一輛F1賽車只能安裝一臺V8引擎。車隊很快投入了新賽車 的研發(fā)，不幸的是，從工程師那里得到消息，舊車身的設計不能夠裝進新研發(fā)的引擎。我們不得不為新的引擎重新打造車身，于是一輛新的賽車誕生了。但是，麻煩 的事接踵而來，國際汽聯(lián)頻頻修改規(guī)則，搞得設計師在“賽車”上改了又改，最終變得不成樣子，只能把它廢棄。

為了能夠重用這輛昂貴的賽車，工程師們提出了解決方案：首先，在車身的設計上預留出安裝引擎的位置和管線。然后，根據這些設計好的規(guī)范設計引擎（或是引擎的適配器）。于是，新的賽車設計方案就這樣誕生了。

?

顯然，通過重構，這里應用的是一個典型的Bridge模式。這個實現的關鍵之處在于我們預先給引擎留出了位置！我們不必因為對引擎的規(guī)則的頻頻變更而制造相當多的車身，而是盡可能地沿用和改良現有的車身。
說到這里，想說一說OO設計的一個誤區(qū)。
學 習OO語言的時候，為了能夠說明“繼承”（或者說“is-a”）這個概念，教科書上經常用實際生活中的例子來解釋。比如汽車是車，電車是車，F1賽車是汽 車，所以車是汽車、電車、F1賽車的上層抽象。這個例子并沒有錯。問題是，這樣的例子過于“形象”了！如果OO設計直接就可以將現實生活中的概念引用過 來，那也就不需要什么軟件工程師了！OO設計的關鍵概念是抽象。如果沒有抽象，那所有的軟件工程師的努力都是徒勞的。因為如果沒有抽象，我們只能去構造世 界中每一個對象。上面這個例子中，我們應該看到“引擎”這個抽象的存在，因為車隊的工程師們?yōu)樗A留了位置，為它制定了設計規(guī)范。
上面這個設計也 實現了后面要說的DIP（依賴倒置原則）。但是請記住，OCP是OO設計原則中高層次的原則，其余的原則對OCP提供了不同程度的支持。為了實現OCP， 我們會自覺或者不自覺地用到其它原則或是諸如Bridge、Decorator等設計模式。然而，對于一個應用系統(tǒng)而言，實現OCP并不是設計目的，我們 所希望的只是一個穩(wěn)定的架構。所以對OCP的追求也應該適可而止，不要陷入過渡設計。正如Martin本人所說：“No significant program can be 100% closed.”“Closure not complete but strategic”

Liskov替換原則—— LSP?

子類型必須能夠替換它的基類型

依賴倒置原則—— DIP?

a：高層模塊不應依賴于底層模塊，兩者都應該依賴于抽象
b：抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象

接口隔離原則—— ISP?

使用多個專門的接口比使用單一的總接口總要好。換而言之，從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小接口上的。

原則

過于臃腫的接口是對接口的污染。不應該強迫客戶依賴于它們不用的方法。

My object-oriented umbrella（摘自Design Patterns Explained）

Let me tell you about my great umbrella. It is large enough to get into! In fact, three or four other people can get in it with me. While we are in it, staying out of the rain, I can move it from one place to another. It has a stereo system to keep me entertained while I stay dry. Amazingly enough, it can also condition the air to make it warmer or colder. It is one cool umbrella.

My umbrella is convenient. It sits there waiting for me. It has wheels on it so that I do not have to carry it around. I don't even have to push it because it can propel itself. Sometimes, I will open the top of my umbrella to let in the sun. (Why I am using my umbrella when it is sunny outside is beyond me!)

In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors. Most people call them cars.

實現方法：
1、?使用委托分離接口
2、?使用多重繼承分離接口

想到一個朋友說的話：所有的接口都只有一個方法，具體的類根據自己需要什么方法去實現接口

工作了幾年,在不同的公司進入了幾個不同的團隊.感覺團隊之間的差異很大.

1.一個好的團隊,是需要時間來培養(yǎng)的.團隊中的成員需要時間來互相熟悉,這個熟悉不單是平常說的認識,還要包括熟悉其他的編程方式設計傾向,工作習慣.只有這樣以后,在討論問題討論方案的時候,可以形成默契,基本簡單幾句就會明白在說什么問題.團隊也需要時間來形成團隊的風格,一個有團隊所有成員的風格組合在一起形成的風格.包括文檔,編碼,設計,溝通等方面上的一致風格.中間需要不斷進行review,按照review的結果,對所有成果物進行修改.

2.一個好的團隊的人員流動應該是良性的.這個良性流動指的是有人員的變化,但是變化的數量和范圍不會使得團隊的風格發(fā)生大的變化,如果一個10人的團隊,突然發(fā)生的5人的變化,就是說調整到其他團隊5個人,又調整進來5個人,那對于這個團隊基本可以算是重新形成一個新的團隊了.

3.一個好的團隊,不單需要團隊內部成員的努力,同時也需要SPEG和QA在團隊之外對團隊的開發(fā)流程的監(jiān)督和規(guī)范.如果沒有了解開發(fā)流程和開發(fā)規(guī)范的SPEG對流程進行監(jiān)督,即使團隊形成了風格,那這個風格很有可能不是健康的風格,可能會導致團隊在以后的開發(fā)的過程中產生問題.

4.一個好的團隊,需要比較有控制力的PM,能力強的PSM,設計能力優(yōu)秀的SA.正因為有這樣的人,才能快速的將加入團隊的新成員,融入團隊.

好像具備了上面這些條件想不形成一個好的團隊也是很不容易的事情了:)
最近一直在想這個事情，從近幾年的web application的發(fā)展情況和工作項目的用戶需求來看，rich client應該又要成為一個潮流了。

主要原因有兩點：
一是網速的提高，過去使用browser是因為過去的網絡速度比較慢，所以只能給客戶端傳送很少的信息量，讓客戶通過網絡傳輸的信息盡可能少的完成操作。而現在網絡速度的提高，讓這樣的要求變少了，網速慢的這個瓶頸也不再存在了。
二是用戶的要求，用戶實際上不在意什么client還是brower，用戶在意的是使用是否方便，響應是否迅速,能否滿足業(yè)務需要。如果網速慢,機器配置差的瓶頸在今天的技術條件下不存在了，用戶對于易用性和快速響應的要求就要提高了。這個快速響應不是指那種客戶端<----->服務器的響應，而已一個操作之后快速的出現結果，這個就要求有一部分在C/S模式下在客戶端實現的功能但是在B/S情況下被轉移到服務器上的一些功能需要在客戶端實現。

但是這個rich client不是幾年前的那種臃腫的不行的方式了，應該是比現在的應用的client包含的內容多，但是比以前的client的內容要少。主要解決的問題是，快速響應用戶的操作，讓用戶的操作更簡單。


（思路不是很清晰，暫時是這樣，之后再修改）