最大限制地提高代碼的可重用性,克服傳統物件導向編程方法在可重用性方面的不足

來源:互聯網
上載者:User
編程|對象     重用是一種神話,這似乎正在日漸成為編程人員的一種共識。然而,重用可能難以實現,因為傳統物件導向編程方法在可重用性方面存在一些不足。本技巧說明了組成支援重用的一種不同方法的三個步驟。 第一步:將功能移出類執行個體方法由於類繼承機制缺乏精確性,因此對於代碼重用來說它並不是一種最理想的機制。也就是說,如果您要重用某個類的單個方法,就必須繼承該類的其他方法以及資料成員。這種累贅不必要地將要重用此方法的代碼複雜化了。繼承類對其父類的依賴性引入了額外的複雜性:對父類的更改會影響子類;當更改父類或子類中的任一方時,很難記住覆蓋了哪些方法(或者沒有覆蓋哪些方法);而且是否應該調用相應的父類方法也不明朗。執行單一概念性任務的任何方法都應該是獨立的,並應將其作為要重用的首選方法。要實現這一點,我們必須返回到過程式編程,將代碼移出類執行個體方法並將其移入全域可見的過程中。為了提高這類過程的可重用性,您應該像編寫靜態實用方法那樣編寫這類方法:每個過程只使用其自身的輸入參數和/或對其他全域可見過程的調用完成其工作,而且不應該使用任何非局部變數。這種外部依賴性的減弱降低了使用該過程的複雜性,從而可促進在別處對它的重用。當然,即便那些不計劃重用的代碼也會從這種結構中受益,因為它的結構總是相當清晰。在 Java 中,方法不能脫離類而存在。但是,您可以採取相關步驟,使方法成為單個類的、公用可見的靜態方法。作為樣本,您可以採用類似下面這樣的一個類:class Polygon {..public int getPerimeter() {...}public boolean isConvex() {...}public boolean containsPoint(Point p) {...}..}並將其更改為類似以下的形式:class Polygon {..public int getPerimeter() {return pPolygon.computePerimeter(this);}public boolean isConvex() {return pPolygon.isConvex(this);}public boolean containsPoint(Point p) {return pPolygon.containsPoint(this, p);}..}其中,pPolygon 如下所示:class pPolygon {static public int computePerimeter(Polygon polygon) {...}static public boolean isConvex(Polygon polygon) {...}static public boolean containsPoint(Polygon polygon, Point p) {...}}類名 pPolygon 反映了該類所封裝的過程主要與類型 Polygon 的對象有關。類名前的 p 表示該類的唯一用途就是將公用可見的靜態過程組織起來。然而,在 Java 中類名以小寫字母開頭是不規範的,像 pPolygon 這樣的類並不完成正常的類功能。這就是說,它不代表一類對象;它只是該語言所需的一個組織實體。在以上案例中所作更改的全部效果就是,用戶端代碼不再非要通過繼承 Polygon 來重用其功能。現在這一功能在 pPolygon 類中是以過程為單位提供的。用戶端代碼僅使用它所需的功能,而不必關心它不需要的功能。這並不意味著類不會在新的過程式編程風格中發揮積極作用。恰恰相反,類要執行必要的分組任務,並封裝它們所代表的對象的資料成員。此外,類通過實現多個介面而具備的多態性使其具備了卓越的可重用性,請參閱第二步中的說明。但是,您應該將通過類繼承獲得可重用性和多態性的方法歸類到優先順序較低的技術中,因為將功能包含在執行個體方法中並不是實現可重用性的最佳選擇。四人合著的暢銷書 Design Patterns 簡要提及了一種與這一技術只有細微差別的技術。那本書中的 Strategy 模式提倡用一個共公介面將相關演算法的每個系列成員都封裝起來,以便用戶端代碼可互換這些演算法。因為一種演算法通常被編寫為一個或幾個獨立的過程,因而這種封裝強調重用執行單一任務(即一個演算法)的過程,而不強調重用包含代碼和資料、執行多項任務的對象。本步驟也體現了同樣的基本思想。然而,用介面封裝演算法意味著將演算法編寫為實現該介面的一個對象。這意味著我們仍然被束縛在與資料耦合在一起的過程及其封裝對象的其他方法上,因而使重用變得複雜。每次使用演算法時必須執行個體化這些對象也是個問題,這將降低程式的效能。幸運的是, Design Patterns 提供的一種解決方案可解決這兩個問題。在編寫 Strategy 對象時您可使用 Flyweight 模式,以使每個對象僅有一個眾所周知的共用執行個體(該執行個體處理執行問題),這樣每個共用對象就不會在兩次訪問之間維護狀態(因此該對象不包含任何成員變數,從而解決了許多耦合問題)。產生的 Flyweight-Strategy 模式將本步驟中封裝功能的技術高度整合在全域可用的無狀態過程中。第二步:將非基礎資料型別 (Elementary Data Type)的輸入參數類型轉換為介面類型通過介面參數類型而非通過類繼承利用多態性,這是在物件導向編程方法中實現可重用性的真正基礎,正如 Allen Holub 在 "Build User Interfaces for Object-Oriented Systems, Part 2" 中所講的那樣。“... 可重用性是通過編寫介面,而不是通過編寫類來實現的。如果一個方法的所有參數均為一些已知介面的引用,而這些介面又是由您從未聽過的一些類實現的,那麼該方法可對編寫代碼時還不存在的類的對象進行操作。從技術上講,可重用的是方法,而不是傳遞給該方法的對象。”將 Holub 的論述應用到第一步的結果,一旦某個功能塊可作為一個全域可見的獨立過程,您就可以通過將它的每個類級輸入參數類型轉換為介面類型,從而進一步提高它的可重用性。這樣,實現該介面類型的任何類的對象都符合該參數的要求,而不僅僅是符合原始類的要求。這樣,該過程便潛在地可用於更多的物件類型。例如,假定您有一個全域可見的靜態方法:static public boolean contains(Rectangle rect, int x, int y) {...}該方法旨在判斷給定的矩形是否包含給定的位置。此處您應該將 rect 參數的類型從類類型 Rectangle 更改為介面類型,如下所示:static public boolean contains(Rectangular rect, int x, int y) {...}Rectangular could be the following interface:public interface Rectangular {Rectangle getBounds();}現在,可描述為 Rectangular 的類(即可實現 Rectangular 介面)的對象都可作為 rect 的參數傳遞給 pRectangular.contains()。我們通過放寬對可傳遞給方法的參數的約束來提高方法的可重用性。但是,就以上樣本而言,當 Rectangle 介面的 getBounds 方法返回一個 Rectangle 時,您可能不知道使用 Rectangular 介面會有什麼實際的好處;也就是說,如果我們知道我們要傳入的對象在被請求時能返回 Rectangle;為什麼不傳入 Rectangle 類型而要傳入介面類型呢?最重要的原因與集合有關。假定有這樣一個方法:static public boolean areAnyOverlapping(Collection rects) {...}該方法旨在判斷給定集合中的 rectangular 對象是否有重疊。接下來,在方法體中,當您依次處理集合中的每個對象時,如果無法將對象轉換為諸如 Rectangular 這樣的介面類型,如何才能訪問那個對象的 rectangle 呢?唯一的選擇是將對象轉換為特定的類類型(我們已知該類中有一個方法能提供 rectangle),這意味著該方法必須事Crowdsourced Security Testing道它要對何種類類型進行操作,因此重用它時只能使用這些類型。這就是這一步首先要避免的問題!第三步:選擇耦合性較小的輸入參數介面類型在執行第二步時,應該選擇何種介面類型來替代給定的類類型呢?答案是:能充分描述過程對參數的要求且累贅最少的任何介面。參數對象要實現的介面越小,任一特定類能實現該介面的機會就越大 -- 因而其對象可用作該參數的類的數量也就越多。很容易看出,如果您有如下這樣一個方法:static public boolean areOverlapping(Window window1, Window window2) {...}該方法旨在判斷兩個(假定為 rectangular)視窗是否重疊,如果該方法僅要求它的兩個參數提供它們各自的 rectangular 座標,則最好簡化這兩個參數的類型以反映這一事實:static public boolean areOverlapping(Rectangular rect1, Rectangular rect2) {...}以上代碼假定前面的 Window 類型對象也能實現 Rectangular。現在您就可以重用任何 rectangular 對象的第一個方法中所包含的功能。您可能有過多次這樣的經曆,即充分指定了參數要求的可用介面包含過多不必要的方法。碰到這種情況時,您就應在全域名稱空間中定義一個新的公用介面,以便其他可能面臨同樣窘境的方法重用這個介面。您也可能有過多次這樣的經曆,即最好建立一個獨特的介面來指定單個過程對一個參數的要求。您所建立的介面只會用於那個參數。當您希望將參數當作 C 中的函數指標處理時經常會出現這種情況,例如,假定有這樣一個過程:static public void sort(List list, SortComparison comp) {...}該過程通過使用給定的比較對象 comp 對列表的所有對象進行比較,從而對給定的列表進行排序,sort 對 comp 的全部要求就是調用其單個方法執行比較。因此,SortComparison 應該是僅包含一個方法的介面:public interface SortComparison {boolean comesBefore(Object a, Object b);}該介面的唯一用途就是為 sort 提供一種訪問完成其工作所需功能的方法,因此 SortComparison 不應在別處重用。小結以上三步旨在改進用更傳統的物件導向方法編寫的現有代碼。將這三個步驟與物件導向編程結合使用即可構建一種新的方法,您可用這種新方法編寫以後的代碼,這樣編寫代碼將提高方法的可重用性和內聚性,同時也會減少方法的相互耦合及複雜性。很明顯,您不應該對本質上不適合重用的代碼執行這些步驟。這種代碼通常存在於程式的展示層。建立程式使用者介面的代碼及將輸入事件綁定到完成實際操作的控制碼是不可重用的兩個例子,因為它們的功能隨程式的不同而相差甚遠,根本無法實現可重用性。

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。