對OO,OOA,OOD,OOP的學習和理解

首先要明白每個簡寫的含義,

OO :Objec - Oriented ,面向?qū)ο?基于對象概念,以對象為中心,以類和繼承為構(gòu)造機制,來認識,理解,刻畫客觀世界和設計,構(gòu)建相應的軟件系統(tǒng)的一門方法;本意-- 模擬人類的思維方式,使開發(fā),維護,修改更加容易.

OOA:Object - Oriented Analysis, 面向?qū)ο蠓治?強調(diào)的是在系統(tǒng)調(diào)查資料的基礎上,針對OO方法所需要的素材進行的歸類分析和整理,而不是對管理業(yè)務現(xiàn)狀和方法的分析---其實就是進一步對OO進行細化,初步得出OO的方法(或者簡單的理解:在得出的文檔中對接口粗略定義)

OOD:Object - Oriented Design,面向?qū)ο笤O計,OO方法中一個中間過渡環(huán)節(jié),其主要作用是對OOA分析的結(jié)果進一步的規(guī)范和整理,以便能夠被OOP直接接受---整理和定義OO的屬性和方法

OOP:object - Oriented Programming,把組件的實現(xiàn)和接口分開,并且讓組件具有多態(tài)性---(抽象,封裝,繼承,多態(tài))面向接口編程.

OOA

Object-Oriented Analysis:面向?qū)ο蠓治龇椒ㄊ窃谝粋€系統(tǒng)的開發(fā)過程中進行了系統(tǒng)業(yè)務調(diào)查以后探遵,按照面向?qū)ο蟮乃枷雭矸治鰡栴}。OOA與結(jié)構(gòu)化分析有較大的區(qū)別裤纹。OOA所強調(diào)的是在系統(tǒng)調(diào)查資料的基礎上睁枕,針對OO方法所需要的素材進行的歸類分析和整理威根,而不是對管理業(yè)務現(xiàn)狀和方法的分析采缚。

OOA(面向?qū)ο蟮姆治觯┠P陀?個層次(主題層瓶竭、對象類層督勺、結(jié)構(gòu)層、屬性層和服務層)和5個活動(標識對象類斤贰、標識結(jié)構(gòu)智哀、定義主題、定義屬性和定義服務)組成荧恍。在這種方法中定義了兩種對象類之間的結(jié)構(gòu)瓷叫,一種稱為分類結(jié)構(gòu),一種稱為組裝結(jié)構(gòu)送巡。分類結(jié)構(gòu)就是所謂的一般與特殊的關系摹菠。組裝結(jié)構(gòu)則反映了對象之間的整體與部分的關系。

OOA在定義屬性的同時骗爆,要識別實例連接次氨。實例連接是一個實例與另一個實例的映射關系。

OOA在定義服務的同時要識別消息連接淮腾。當一個對象需要向另一對象發(fā)送消息時糟需,它們之間就存在消息連接。

OOA 中的5個層次和5個活動繼續(xù)貫穿在OOD(畫向?qū)ο蟮脑O計)過程中谷朝。OOD模型由4個部分組成洲押。它們分別是設計問題域部分、設計人機交互部分圆凰、設計任務管理部分和設計數(shù)據(jù)管理部分杈帐。

一、OOA的主要原則专钉。

(1)抽象:從許多事物中舍棄個別的挑童、非本質(zhì)的特征,抽取共同的跃须、本質(zhì)性的特征站叼,就叫作抽象。抽象是形成概念的必須手段菇民。

抽象原則有兩方面的意義:第一尽楔,盡管問題域中的事物是很復雜的投储,但是分析員并不需要了解和描述它們的一切,只需要分析研究其中與系統(tǒng)目標有關的事物及其本質(zhì)性特征阔馋。第二玛荞,通過舍棄個體事物在細節(jié)上的差異,抽取其共同特征而得到一批事物的抽象概念呕寝。

抽象是面向?qū)ο蠓椒ㄖ惺褂米顬閺V泛的原則勋眯。抽象原則包括過程抽象和數(shù)據(jù)抽象兩個方面。

過程抽象是指下梢,任何一個完成確定功能的操作序列客蹋,其使用者都可以把它看作一個單一的實體,盡管實際上它可能是由一系列更低級的操作完成的怔球。

數(shù)據(jù)抽象是根據(jù)施加于數(shù)據(jù)之上的操作來定義數(shù)據(jù)類型嚼酝,并限定數(shù)據(jù)的值只能由這些操作來修改和觀察。數(shù)據(jù)抽象是OOA的核心原則竟坛。它強調(diào)把數(shù)據(jù)(屬性)和操作(服務)結(jié)合為一個不可分的系統(tǒng)單位(即對象)闽巩,對象的外部只需要知道它做什么,而不必知道它如何做担汤。

(2)封裝就是把對象的屬性和服務結(jié)合為一個不可分的系統(tǒng)單位涎跨,并盡可能隱蔽對象的內(nèi)部細節(jié)。

(3)繼承:特殊類的對象擁有的其一般類的全部屬性與服務崭歧,稱作特殊類對一般類的繼承隅很。

在OOA中運用繼承原則,就是在每個由一般類和特殊類形成的一般—特殊結(jié)構(gòu)中率碾,把一般類的對象實例和所有特殊類的對象實例都共同具有的屬性和服務叔营,一次性地在一般類中進行顯式的定義。在特殊類中不再重復地定義一般類中已定義的東西所宰,但是在語義上绒尊,特殊類卻自動地、隱含地擁有它的一般類(以及所有更上層的一般類)中定義的全部屬性和服務仔粥。繼承原則的好處是:使系統(tǒng)模型比較簡練也比較清晰婴谱。

(4)分類:就是把具有相同屬性和服務的對象劃分為一類,用類作為這些對象的抽象描述躯泰。分類原則實際上是抽象原則運用于對象描述時的一種表現(xiàn)形式谭羔。

(5)聚合:又稱組裝,其原則是:把一個復雜的事物看成若干比較簡單的事物的組裝體麦向,從而簡化對復雜事物的描述瘟裸。

(6)關聯(lián):是人類思考問題時經(jīng)常運用的思想方法:通過一個事物聯(lián)想到另外的事物。能使人發(fā)生聯(lián)想的原因是事物之間確實存在著某些聯(lián)系诵竭。

(7)消息通信:這一原則要求對象之間只能通過消息進行通信话告,而不允許在對象之外直接地存取對象內(nèi)部的屬性十办。通過消息進行通信是由于封裝原則而引起的。在OOA中要求用消息連接表示出對象之間的動態(tài)聯(lián)系超棺。

(8)粒度控制:一般來講,人在面對一個復雜的問題域時呵燕,不可能在同一時刻既能縱觀全局棠绘,又能洞察秋毫。因此需要控制自己的視野:考慮全局時再扭,注意其大的組成部分氧苍,暫時不詳察每一部分的具體的細節(jié);考慮某部分的細節(jié)時則暫時撇開其余的部分泛范。這就是粒度控制原則让虐。

(9)行為分析:現(xiàn)實世界中事物的行為是復雜的。由大量的事物所構(gòu)成的問題域中各種行為往往相互依賴罢荡、相互交織赡突。

二、面向?qū)ο蠓治霎a(chǎn)生三種分析模型

1区赵、對象模型:對用例模型進行分析,把系統(tǒng)分解成互相協(xié)作的分析類,通過類圖/對象圖描述對象/對象的屬性/對象間的關系,是系統(tǒng)的靜態(tài)模型

2惭缰、動態(tài)模型:描述系統(tǒng)的動態(tài)行為,通過時序圖/協(xié)作圖描述對象的交互,以揭示對象間如何協(xié)作來完成每個具體的用例,單個對象的狀態(tài)變化/動態(tài)行為可以通過狀態(tài)圖來表達

3、功能模型(即用例模型à作為輸入)笼才。

三漱受、OOA的主要優(yōu)點

(1)加強了對問題域和系統(tǒng)責任的理解;

(2)改進與分析有關的各類人員之間的交流骡送;

(3)對需求的變化具有較強的適應性昂羡;

(4)支持軟件復用。

(5)貫穿軟件生命周期全過程的一致性摔踱。

(6)實用性虐先;

(7)有利于用戶參與。

四昌渤、OOA方法的基本步驟

在用OOA具體地分析一個事物時赴穗,大致上遵循如下五個基本步驟:

第一步,確定對象和類膀息。這里所說的對象是對數(shù)據(jù)及其處理方式的抽象般眉,它反映了系統(tǒng)保存和處理現(xiàn)實世界中某些事物的信息的能力。類是多個對象的共同屬性和方法集合的描述潜支,它包括如何在一個類中建立一個新對象的描述甸赃。

第二步,確定結(jié)構(gòu)(structure)冗酿。結(jié)構(gòu)是指問題域的復雜性和連接關系埠对。類成員結(jié)構(gòu)反映了泛化-特化關系络断,整體-部分結(jié)構(gòu)反映整體和局部之間的關系。

第三步项玛,確定主題(subject)貌笨。主題是指事物的總體概貌和總體分析模型。

第四步襟沮,確定屬性(attribute)锥惋。屬性就是數(shù)據(jù)元素,可用來描述對象或分類結(jié)構(gòu)的實例开伏,可在圖中給出膀跌,并在對象的存儲中指定。

第五步固灵,確定方法(method)捅伤。方法是在收到消息后必須進行的一些處理方法:方法要在圖中定義,并在對象的存儲中指定巫玻。對于每個對象和結(jié)構(gòu)來說丛忆,那些用來增加、修改仍秤、刪除和選擇一個方法本身都是隱含的(雖然它們是要在對象的存儲中定義的蘸际,但并不在圖上給出),而有些則是顯示的徒扶。

OOD

面向?qū)ο笤O計(Object-Oriented Design粮彤,OOD)方法是OO方法中一個中間過渡環(huán)節(jié)。其主要作用是對OOA分析的結(jié)果作進一步的規(guī)范化整理姜骡,以便能夠被OOP直接接受导坟。

面向?qū)ο笤O計(OOD)是一種軟件設計方法,是一種工程化規(guī)范圈澈。這是毫無疑問的惫周。按照Bjarne Stroustrup的說法,面向?qū)ο蟮木幊谭妒剑╬aradigm)是[Stroustrup, 97]:

l 決定你要的類康栈;

l 給每個類提供完整的一組操作递递;

l 明確地使用繼承來表現(xiàn)共同點。

由這個定義啥么,我們可以看出:OOD就是“根據(jù)需求決定所需的類登舞、類的操作以及類之間關聯(lián)的過程”。

OOD的目標是管理程序內(nèi)部各部分的相互依賴悬荣。為了達到這個目標菠秒,OOD要求將程序分成塊,每個塊的規(guī)模應該小到可以管理的程度氯迂,然后分別將各個塊隱藏在接口(interface)的后面践叠,讓它們只通過接口相互交流言缤。比如說,如果用OOD的方法來設計一個服務器-客戶端(client-server)應用禁灼,那么服務器和客戶端之間不應該有直接的依賴管挟,而是應該讓服務器的接口和客戶端的接口相互依賴。

這種依賴關系的轉(zhuǎn)換使得系統(tǒng)的各部分具有了可復用性弄捕。還是拿上面那個例子來說哮独,客戶端就不必依賴于特定的服務器,所以就可以復用到其他的環(huán)境下察藐。如果要復用某一個程序塊,只要實現(xiàn)必須的接口就行了舟扎。

OOD是一種解決軟件問題的設計范式(paradigm)分飞,一種抽象的范式。使用OOD這種設計范式睹限,我們可以用對象(object)來表現(xiàn)問題領域(problem domain)的實體譬猫,每個對象都有相應的狀態(tài)和行為。我們剛才說到:OOD是一種抽象的范式羡疗。抽象可以分成很多層次染服,從非常概括的到非常特殊的都有,而對象可能處于任何一個抽象層次上叨恨。另外柳刮,彼此不同但又互有關聯(lián)的對象可以共同構(gòu)成抽象:只要這些對象之間有相似性,就可以把它們當成同一類的對象來處理痒钝。

一秉颗、OOD背景知識

計算機硬件技術卻在飛速發(fā)展。從幾十年前神秘的龐然大物送矩,到現(xiàn)在隨身攜帶的移動芯片蚕甥;從每秒數(shù)千次運算到每秒上百億次運算。當軟件開發(fā)者們還在尋找能讓軟件開發(fā)生產(chǎn)力提高一個數(shù)量級的“銀彈”[Brooks, 95]時栋荸,硬件開發(fā)的生產(chǎn)力早已提升了百倍千倍菇怀。

硬件工程師們能夠如此高效,是因為他們都很懶惰晌块。他們永遠恪守“不要去重新發(fā)明輪子”的古訓爱沟。Grady Booch把這些黑箱稱為類屬(class category),現(xiàn)在我們則通常把它們稱為“組件(component)”匆背。

類屬是由被稱為類(class)的實體組成的钥顽,類與類之間通過關聯(lián)(relationship)結(jié)合在一起。一個類可以把大量的細節(jié)隱藏起來靠汁,只露出一個簡單的接口蜂大,這正好符合人們喜歡抽象的心理闽铐。所以,這是一個非常偉大的概念奶浦,因為它給我們提供了封裝和復用的基礎兄墅,讓我們可以從問題的角度來看問題,而不是從機器的角度來看問題澳叉。

軟件的復用最初是從函數(shù)庫和類庫開始的隙咸,這兩種復用形式實際上都是白箱復用。到90年代成洗,開始有人開發(fā)并出售真正的黑箱軟件模塊:框架(framework)和控件(control)五督。框架和控件往往還受平臺和語言的限制瓶殃,現(xiàn)在軟件技術的新潮流是用SOAP作為傳輸介質(zhì)的Web Service充包,它可以使軟件模塊脫離平臺和語言的束縛,實現(xiàn)更高程度的復用遥椿。但是想一想基矮,其實Web Service也是面向?qū)ο螅徊贿^是把類與類之間的關聯(lián)用XML來描述而已[Li, 02]冠场。

在過去的十多年里家浇,面向?qū)ο蠹夹g對軟件行業(yè)起到了極大的推動作用。在可以預測的將來碴裙,它仍將是軟件設計的主要技術——至少我看不到有什么技術可以取代它的钢悲。

二、OOD到底從哪兒來舔株?

有很多人都認為:OOD是對結(jié)構(gòu)化設計(Structured Design譬巫,SD)的擴展,其實這是不對的督笆。OOD的軟件設計觀念和SD完全不同芦昔。SD注重的是數(shù)據(jù)結(jié)構(gòu)和處理數(shù)據(jù)結(jié)構(gòu)的過程。而在OOD中娃肿,過程和數(shù)據(jù)結(jié)構(gòu)都被對象隱藏起來咕缎,兩者幾乎是互不相關的。不過料扰,追根溯源凭豪,OOD和SD有著非常深的淵源。

1967年前后晒杈,OOD和SD 的概念幾乎同時誕生嫂伞,它們分別以不同的方式來表現(xiàn)數(shù)據(jù)結(jié)構(gòu)和算法。當時,圍繞著這兩個概念帖努,很多科學家寫了大量的論文撰豺。其中,由Dijkstra和 Hoare兩人所寫的一些論文講到了“恰當?shù)某绦蚩刂平Y(jié)構(gòu)”這個話題拼余,聲稱goto語句是有害的污桦,應該用順序、循環(huán)匙监、分支這三種控制結(jié)構(gòu)來構(gòu)成整個程序流程凡橱。這些概念發(fā)展構(gòu)成了結(jié)構(gòu)化程序設計方法;而由Ole-Johan Dahl所寫的另一些論文則主要討論編程語言中的單位劃分亭姥,其中的一種程序單位就是類稼钩,它已經(jīng)擁有了面向?qū)ο蟪绦蛟O計的主要特征。

這兩種概念立刻就分道揚鑣了达罗。在結(jié)構(gòu)化這邊的歷史大家都很熟悉:NATO會議采納了Dijkstra的思想坝撑,整個軟件產(chǎn)業(yè)都同意goto語句的確是有害的,結(jié)構(gòu)化方法氮块、瀑布模型從70年代開始大行其道。同時诡宗,無數(shù)的科學家和軟件工程師也幫助結(jié)構(gòu)化方法不斷發(fā)展完善滔蝉,其中有很多今天足以使我們振聾發(fā)聵的名字,例如Constantine塔沃、Yourdon蝠引、DeMarco和Dijkstra。有很長一段時間蛀柴,整個世界都相信:結(jié)構(gòu)化方法就是拯救軟件工業(yè)的 “銀彈”螃概。當然,時間最后證明了一切鸽疾。

而此時吊洼,面向?qū)ο髣t在研究和教育領域緩慢發(fā)展。結(jié)構(gòu)化程序設計幾乎可以應用于任何編程語言之上制肮,而面向?qū)ο蟪绦蛟O計則需要語言的支持[1]冒窍,這也妨礙了面向?qū)ο蠹夹g的發(fā)展。實際上豺鼻,在60年代后期综液,支持面向?qū)ο筇匦缘恼Z言只有Simula-67這一種。到70年代儒飒,施樂帕洛阿爾托研究中心(PARC)的 Alan Key等人又發(fā)明了另一種基于面向?qū)ο蠓椒ǖ恼Z言谬莹,那就是大名鼎鼎的Smalltalk。但是,直到80年代中期附帽,Smalltalk和另外幾種面向?qū)ο笳Z言仍然只停留在實驗室里埠戳。

到90年代,OOD突然就風靡了整個軟件行業(yè)士葫,這絕對是軟件開發(fā)史上的一次革命乞而。不過,登高才能望遠慢显,新事物總是站在舊事物的基礎之上的爪模。70年代和80年代的設計方法揭示出許多有價值的概念,誰都不能也不敢忽視它們荚藻,OOD也一樣屋灌。

三、OOD和傳統(tǒng)方法有什么區(qū)別应狱?

還記得結(jié)構(gòu)化設計方法嗎共郭?程序被劃分成許多個模塊,這些模塊被組織成一個樹型結(jié)構(gòu)疾呻。這棵樹的根就是主模塊除嘹,葉子就是工具模塊和最低級的功能模塊。同時岸蜗,這棵樹也表示調(diào)用結(jié)構(gòu):每個模塊都調(diào)用自己的直接下級模塊尉咕,并被自己的直接上級模塊調(diào)用。

那么璃岳,哪個模塊負責收集應用程序最重要的那些策略年缎?當然是最頂端的那些。在底下的那些模塊只管實現(xiàn)最小的細節(jié)铃慷,最頂端的模塊關心規(guī)模最大的問題单芜。所以,在這個體系結(jié)構(gòu)中越靠上犁柜,概念的抽象層次就越高洲鸠,也越接近問題領域;體系結(jié)構(gòu)中位置越低馋缅,概念就越接近細節(jié)坛怪,與問題領域的關系就越少,而與解決方案領域的關系就越多股囊。

但是袜匿,由于上方的模塊需要調(diào)用下方的模塊,所以這些上方的模塊就依賴于下方的細節(jié)稚疹。換句話說居灯,與問題領域相關的抽象要依賴于與問題領域無關的細節(jié)祭务!這也就是說,當實現(xiàn)細節(jié)發(fā)生變化時怪嫌,抽象也會受到影響义锥。而且,如果我們想復用某一個抽象的話岩灭,就必須把它依賴的細節(jié)都一起拖過去拌倍。

而在OOD中,我們希望倒轉(zhuǎn)這種依賴關系:我們創(chuàng)建的抽象不依賴于任何細節(jié)噪径,而細節(jié)則高度依賴于上面的抽象柱恤。這種依賴關系的倒轉(zhuǎn)正是OOD和傳統(tǒng)技術之間根本的差異,也正是OOD思想的精華所在找爱。

四梗顺、OOD步驟

細化重組類

細化和實現(xiàn)類間關系,明確其可見性

增加屬性,指定屬性的類型與可見性

分配職責,定義執(zhí)行每個職責的方法

對消息驅(qū)動的系統(tǒng),明確消息傳遞方式

利用設計模式進行局部設計

畫出詳細的類圖與時序圖

五、OOD設計過程中要展開的主要幾項工作

(一)對象定義規(guī)格的求精過程

對于OOA所抽象出來的對象-&-類以及匯集的分析文檔车摄,OOD需要有一個根據(jù)設計要求整理和求精的過程寺谤,使之更能符合OOP的需要。這個整理和求精過程主要有兩個方面:一是要根據(jù)面向?qū)ο蟮母拍?/p>

模型整理分析所確定的對象結(jié)構(gòu)吮播、屬性变屁、方法等內(nèi)容,改正錯誤的內(nèi)容意狠,刪去不必要和重復的內(nèi)容等粟关。二是進行分類整理,以便于下一步數(shù)據(jù)庫設計和程序處理模塊設計的需要摄职。整理的方法主要是進行歸

類誊役,對類一&一對象获列、屬性谷市、方法和結(jié)構(gòu)、主題進行歸類击孩。

(二)數(shù)據(jù)模型和數(shù)據(jù)庫設計

數(shù)據(jù)模型的設計需要確定類-&-對象屬性的內(nèi)容迫悠、消息連接的方式、系統(tǒng)訪問巩梢、數(shù)據(jù)模型的方法等创泄。最后每個對象實例的數(shù)據(jù)都必須落實到面向?qū)ο蟮膸旖Y(jié)構(gòu)模型中。

(三)優(yōu)化

OOD的優(yōu)化設計過程是從另一個角度對分析結(jié)果和處理業(yè)務過程的整理歸納括蝠,優(yōu)化包括對象和結(jié)構(gòu)的優(yōu)化鞠抑、抽象、集成忌警。

對象和結(jié)構(gòu)的模塊化表示OOD提供了一種范式搁拙,這種范式支持對類和結(jié)構(gòu)的模塊化。這種模塊符合一般模塊化所要求的所有特點,如信息隱蔽性好箕速,內(nèi)部聚合度強和模塊之間耦合度弱等酪碘。

集成化使得單個構(gòu)件有機地結(jié)合在一起,相互支持盐茎。

六兴垦、OO方法的特點和面臨的問題

OO方法以對象為基礎,利用特定的軟件工具直接完成從對象客體的描述到軟件結(jié)構(gòu)之間的轉(zhuǎn)換字柠。這是OO方法最主要的特點和成就探越。OO方法的應用解決了傳統(tǒng)結(jié)構(gòu)化開發(fā)方法中客觀世界描述工具與軟

件結(jié)構(gòu)的不一致性問題,縮短了開發(fā)周期募谎,解決了從分析和設計到軟件模塊結(jié)構(gòu)之間多次轉(zhuǎn)換映射的繁雜過程扶关,是一種很有發(fā)展前途的系統(tǒng)開發(fā)方法。

但是同原型方法一樣,OO方法需要一定的軟件基礎支持才可以應用数冬,另外在大型的MIS開發(fā)中如果不經(jīng)自頂向下的整體劃分节槐,而是一開始就自底向上的采用OO 方法開發(fā)系統(tǒng),同樣也會造成系統(tǒng)結(jié)構(gòu)不合理拐纱、各部分關系失調(diào)等問題铜异。所以OO方法和結(jié)構(gòu)化方法目前仍是兩種在系統(tǒng)開發(fā)領域相互依存的、不可替代的方法秸架。

七揍庄、OOD能給我?guī)硎裁矗?/p>

問這個問題的人,腦子里通常是在想“OOD能解決所有的設計問題嗎东抹?”沒有銀彈蚂子。OOD也不是解決一切設計問題、避免軟件危機缭黔、捍衛(wèi)世界和平……的銀彈食茎。OOD只是一種技術。但是馏谨,它是一種優(yōu)秀的技術别渔,它可以很好地解決目前的大多數(shù)軟件設計問題——當然,這要求設計者有足夠的能力惧互。

OOD可能會讓你頭疼哎媚,因為要學會它、掌握它是很困難的喊儡;OOD甚至會讓你失望拨与,因為它也并不成熟、并不完美艾猜。OOD也會給你帶來欣喜买喧,它讓你可以專注于設計攀甚,而不必操心那些細枝末節(jié);OOD也會使你成為一個更好的設計師岗喉,它能提供給你很好的工具秋度,讓你能開發(fā)出更堅固、更可維護钱床、更可復用的軟件荚斯。

OOP

面向?qū)ο缶幊蹋∣bject Oriented Programming,OOP查牌,面向?qū)ο蟪绦蛟O計)是一種計算機編程架構(gòu)事期。OOP 的一條基本原則是計算機程序是由單個能夠起到子程序作用的單元或?qū)ο蠼M合而成。OOP 達到了軟件工程的三個主要目標:重用性纸颜、靈活性和擴展性兽泣。為了實現(xiàn)整體運算,每個對象都能夠接收信息胁孙、處理數(shù)據(jù)和向其它對象發(fā)送信息唠倦。OOP 主要有以下的概念和組件:

組件 - 數(shù)據(jù)和功能一起在運行著的計算機程序中形成的單元,組件在 OOP 計算機程序中是模塊和結(jié)構(gòu)化的基礎涮较。

抽象性 - 程序有能力忽略正在處理中信息的某些方面稠鼻,即對信息主要方面關注的能力。

封裝 - 也叫做信息封裝:確保組件不會以不可預期的方式改變其它組件的內(nèi)部狀態(tài)狂票;只有在那些提供了內(nèi)部狀態(tài)改變方法的組件中候齿,才可以訪問其內(nèi)部狀態(tài)。每類組件都提供了一個與其它組件聯(lián)系的接口闺属,并規(guī)定了其它組件進行調(diào)用的方法慌盯。

多態(tài)性 - 組件的引用和類集會涉及到其它許多不同類型的組件,而且引用組件所產(chǎn)生的結(jié)果得依據(jù)實際調(diào)用的類型掂器。

繼承性 - 允許在現(xiàn)存的組件基礎上創(chuàng)建子類組件亚皂,這統(tǒng)一并增強了多態(tài)性和封裝性。典型地來說就是用類來對組件進行分組唉匾,而且還可以定義新類為現(xiàn)存的類的擴展孕讳,這樣就可以將類組織成樹形或網(wǎng)狀結(jié)構(gòu)匠楚,這體現(xiàn)了動作的通用性巍膘。

由于抽象性、封裝性芋簿、重用性以及便于使用等方面的原因峡懈,以組件為基礎的編程在腳本語言中已經(jīng)變得特別流行。Python 和 Ruby 是最近才出現(xiàn)的語言与斤,在開發(fā)時完全采用了 OOP 的思想肪康,而流行的 Perl 腳本語言從版本5開始也慢慢地加入了新的面向?qū)ο蟮墓δ芙M件荚恶。用組件代替“現(xiàn)實”上的實體成為 JavaScript(ECMAScript) 得以流行的原因,有論證表明對組件進行適當?shù)慕M合就可以在英特網(wǎng)上代替 HTML 和 XML 的文檔對象模型(DOM)磷支。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末谒撼,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子雾狈,更是在濱河造成了極大的恐慌廓潜,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,839評論 6 482
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件善榛,死亡現(xiàn)場離奇詭異辩蛋,居然都是意外死亡,警方通過查閱死者的電腦和手機移盆,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,543評論 2 382
  • 文/潘曉璐 我一進店門悼院,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人咒循,你說我怎么就攤上這事据途。” “怎么了叙甸?”我有些...
    開封第一講書人閱讀 153,116評論 0 344
  • 文/不壞的土叔 我叫張陵昨凡,是天一觀的道長。 經(jīng)常有香客問我蚁署,道長便脊,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,371評論 1 279
  • 正文 為了忘掉前任光戈,我火速辦了婚禮哪痰,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘久妆。我一直安慰自己晌杰,他們只是感情好,可當我...
    茶點故事閱讀 64,384評論 5 374
  • 文/花漫 我一把揭開白布筷弦。 她就那樣靜靜地躺著肋演,像睡著了一般。 火紅的嫁衣襯著肌膚如雪烂琴。 梳的紋絲不亂的頭發(fā)上爹殊,一...
    開封第一講書人閱讀 49,111評論 1 285
  • 那天,我揣著相機與錄音奸绷,去河邊找鬼梗夸。 笑死,一個胖子當著我的面吹牛号醉,可吹牛的內(nèi)容都是我干的反症。 我是一名探鬼主播辛块,決...
    沈念sama閱讀 38,416評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼铅碍!你這毒婦竟也來了镰绎?” 一聲冷哼從身側(cè)響起育韩,我...
    開封第一講書人閱讀 37,053評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后薛耻,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體篱竭,經(jīng)...
    沈念sama閱讀 43,558評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡昼接,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,007評論 2 325
  • 正文 我和宋清朗相戀三年构韵,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片爵嗅。...
    茶點故事閱讀 38,117評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡娇澎,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出睹晒,到底是詐尸還是另有隱情趟庄,我是刑警寧澤,帶...
    沈念sama閱讀 33,756評論 4 324
  • 正文 年R本政府宣布伪很,位于F島的核電站戚啥,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏锉试。R本人自食惡果不足惜猫十,卻給世界環(huán)境...
    茶點故事閱讀 39,324評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望呆盖。 院中可真熱鬧拖云,春花似錦、人聲如沸应又。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,315評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽株扛。三九已至尤筐,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間洞就,已是汗流浹背盆繁。 一陣腳步聲響...
    開封第一講書人閱讀 31,539評論 1 262
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留奖磁,地道東北人改基。 一個月前我還...
    沈念sama閱讀 45,578評論 2 355
  • 正文 我出身青樓繁疤,卻偏偏與公主長得像咖为,于是被迫代替她去往敵國和親秕狰。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 42,877評論 2 345

推薦閱讀更多精彩內(nèi)容