你的面向對象技術在哪個級別?

怎樣才算掌握OOP
服務器君一共花費了222.809 ms進行了7次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

1. 能把面向對象和具體語言的對象抽象聯系起來

在面向對象剛剛入門的時候,一大頓理論加上解釋又是只言片語,什么原則,方法等根本好像是沒有用的嘛。唯一看明白的就是對象,類就是Class。在編程的時候,碰到一個名詞就把它寫成class,以為這就是面向對象編程。拿圖書館案例來講,初步分析后可能就把我們的學生Student作為我們的Class來編程,并設計了它的屬性,方法和操作,具體來說就是給Student加上了name屬性,借書方法等。

仿佛面向對象技術就是這么簡單,這時候就會懷疑面向對象語言書本上開頭講的什么封裝,多態,繼承等到底有什么作用,簡直就是一大堆廢話!?

這個時候如果去看Javascript那種面向對象技術的實現,簡直由于地獄一般,忽然就有上當受騙的感覺,原來對象不止可以用Class來表示啊,還有其他的實現表示方法。

2. 能把面向對象的方法運用到編程中

經過不斷編程實踐,武功已經從亂招到有招了。還是以圖書館為例,發現學生Student具有借書方法,Teacher也有借書方法。于是就想著能不只寫一個借書方法,而Student和Teacher都有借書功能。這個時候我們的面向對象的方法包括封裝,多態,繼承等就派上用場了。我們可以簡單吧Teacher和Student都可以從Reader這個類來繼承,而Reader設計借書方法。

在這個階段才發現原來面向對象的方法封裝,繼承,多態等還是有用的。不過封裝,繼承,多態這幾個名詞太抽象,要是有個具體的使用指南或者說能不能有個歸納這些方法的武功心法?

3. 能使用設計模式

武功心法有沒有呢,還真有。前人為我們準備上等的武功秘籍-設計模式。設計模式,這個堪比使用刀、槍、劍的武功秘笈,加以勤練必能武功大進。設計模式這種武功套路能靈活運用對象技術,把對象之間的關系,結構,行為和協作搞得一清二楚。

這個時候疑問有上來了,設計模式大師還給了一句金玉良言“優先使用組合,不要動不動就使用繼承”。心里不僅就會寒蟬,大師給我武功心法,到頭來還給我留了一招。

4. 能搞懂本質是什么

我們在運用面向對象技術的時候,是用類概念從內部結構,行為來運用,來設計實現計算邏輯。

有很多的時候我們不能準確把握一個事物的本質,可能就是光從一個角度來看問題。既然從內部看了也實踐了,那么現在就可以從外部角度來觀察事物。對象有它的環境,在環境中分工合作,這個就像我們的現實社會,人與人之間,人和大自然都是分工協作,和諧共處的。

話題扯遠了,再回到我們的程序世界中,假如有一天我們要去社區辦個什么事情,去影院看個什么電影等等這些都可以抽象,建立一個模型,我們去社區辦事,電影院看電影都是去享受服務的,把這些服務的提供者都抽象到程序世界中,就可以用類來表示同時提供辦事、看電影等行為。社區辦事,影院看電影這兩個風馬牛不相及的事情,在程序世界可以抽象成兩個提供不同服務的對象。從契約的角度,任何實現了這些服務的對象,都需要履行服務契約,從對象外部來講我們是不需要知道這些對象內部的,也就是我去辦事情,看電影,關鍵不是在什么地方能夠把握解決這些問題,而是什么服務能提供給我以完成目的。

試想有一天去看電影的同時也能把社區辦事的給解決了。那么就不能光光用類這個抽象事物來表示和思考,另外還有一個東西在設計模式中沒有明顯提到的,就是幾乎每種模式里面都有兩個層次,一個就是Abstract層次,一個就是Concrete層次。說白了就是對象的上面還有一個接口的東西,這里暫且不論Interface和Abstract Class的區別。這個時候想想那句“優先使用組合”的錦囊妙計,那么既能辦事又能看電影的超級英雄便能應運而生,當然在分析的時候我們不需要具體知道這個到底是什么地方來提供這些服務的,只需要設計辦事和看電影兩個接口就可以了,至于誰來實現這個服務,I don’t care.

5. 能靈活運用面向對象技術在編碼,設計,分析等領域中

我們在使用面向對象技術去解決具體問題的時候,不及不覺就把這個武功練得如火純清。面向對象技術已經從起步階段把面向對象理解為就是把名詞轉化成類Class這種基礎的理解,上升到能夠從現實社會體驗面向對象的真正含義。每個人都有分工,我們也是社會系統的一個對象,我們也需要對外提供一個服務。比如我可以是一個編碼對象,我專門負責把程序的設計轉化成編碼,這個就是我提供的服務。可是光光有編碼對象還不行,還需要有設計對象提供設計服務,分析對象提供分析服務。術業有專攻,編碼對象可以不斷學習,可以往深度方面發展,也可以往橫向發展。

小結

面向對象技術,最外面的一層是技術在編碼,設計,分析等領域的具體運用,然后是面向對象語言層次,初學者在學習的時候往往從這個層次進入,而且極容易造成理解片面。然后是設計模式這種武功套路,雖然套路只是形式,但是對于剛剛面向對象需要提升的時候,還是很有用處的,可以作為行動指南。接下來的層次就是面向對象本質的理解,SOLID原則運用,封裝,繼承,多態等方法的靈活運用。

本文地址:http://www.zqhthc.tw/librarys/veda/detail/113,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.zqhthc.tw/librarys/veda/detail/113

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

大家都在看

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《人月神話》 弗雷德里克·布魯克斯 (作者), 汪穎 (譯者)

《人月神話》原文:The Mythical Man-Month: The Essays on Software Engineering, 2nd ed.在軟件領域,很少能有像《人月神話》一樣具有深遠影響力并且暢銷不衰的著作。Brooks博士為人們管理復雜項目提供了最具洞察力的見解。既有很多發人深省的觀點,又有大量軟件工程的實踐。本書內容來自Brooks博士在IBM公司System/360家族和OS/360中的項目管理經驗。該書英文原版一經面世,即引起業內人士的強烈反響,后又譯為德、法、日、俄中等多種語言,全球銷量數百萬冊。確立了其在行業內的經典地位。

更多計算機寶庫...

英超直播吻球网