其實在看Martin Fowler的重構這本書的很長一段時間里，我一直把它錯當成了另外一本書的中文版，那本書的名字就是：John.Wiley.and.Sons.Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully.Jun.2006
以前曾經看過這本書，目前還沒有找到中文版。相對于《重構--改善既有代碼的設計》的側重實踐來說，上面這本書理論性更強一些。看講實踐的書有個缺點，就是你看了不上手做一做的話，等于白看，而理論呢，你可以記住。所以下面穿插一些《Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully》的理論，有很多通過英文字面意思很難理解，這樣我會在網上找些資料，然后抄記在下面：
設計原理
正如代碼會“有味”一樣，結構也會“有味”，他們通常會由對于設計原理的違反而引起。因此設計原理會為我們提供一些有價值的東西進而幫助我們為設計去去狐臭。在我們從設計中找出違反這些設計原理的地方的同時,我們也有了自己的想法來改善我們的設計。。下表列出了當前流行的設計原理：
1、DRY(Don't Repeat Yourself)：不要寫重復的代碼。也可以叫做“一次且僅一次(Once and Only Once)”原理。
2、SCP(Speaking Code Principle)：代碼應該清楚地表明它自己的意圖。代碼中出現注釋，說明代碼不能清楚地表現自己的意圖。
3、OCP(Open Closed Principle)：一個設計單元應該向修改開放。這種修改不應該導致調用方無效。繼承是一種能夠讓你達到此目的的方法。子類可以進行一些調整，而超類保持不變。
4、LSP(Liskov Substitution Principle)：個軟件實體如果使用的是一個基類的話，那么一定適用于其子類，而且它根本不能察覺出基類對象和子類對象的區別。反過來代換是不成立的
5、DIP(Dependency Inversion Principle)：等級高的概念不應該依賴于等級低的概念（或實現）。對于從屬關系來說剛好相反。因為等級高的概念比起等級低的概念來說變動的可能性要小。
6、ISP(Interface Segregation Principle)：接口隔離原理。接口應該盡量的小。他們應該僅包含很少的方法，但是這些被放置在同一個接口中的方法應該是緊密相關的。
7、REP(Reuse/Release Equivalency Principle)：可重用的元素必然是已經被發布的元素。
8、
CRP(Common Closure Principle)：
包中的所有類對于同一類性質的變化應該是共同封閉的。 一個變化若對一個包產生影響，則將對該報的所有類產生影響。而對其他的包不構成任何影響。
9、
ADP（Acyclic（無環的）Dependencies Principle）：包之間的依賴關系應當是無環的。
10、
SDP(Stable Dependencies Principle)：一個包應該依賴于至少像它自己那樣穩定的包。
11、
SAP（Stable Abstractions Principle）：越穩定的包，其抽象程度越高。不穩定的包通常是具體化的包。
12、
TDA（Tell,Don't Ask）：不要向一個對象去申請另外一個對象，而應該告訴這個對象應該如何去做。
13、
SOC(Separation Of Concerns)：不要在一個類中包含多個關注點。這通常也被叫做“責任單一原理”。
類關系圖中的“狐臭”兩個或多個類之間的關系通常包含“使用”和“繼承”兩種。如果我們想在一個系統中找出“使用”關系，我們應該看一下“靜態”關系圖。在系統運行時呈現出來的“使用”關系構成了對象之間的動態關系圖。
一、無用類
出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully那些不再使用的類會因為具有一些顯而易見的無用功能而增加系統的負擔。這些負擔包括：程序開發者需要花費大量的時間來分辨出一個正確的類，構建系統的時間變得更長，系統變得更加難以理解。
相對于完全無用的類，更多的情況下你會遇到包含部分無用代碼的類。這是因為一個類中包含了太多的功能，而在真正使用的時候，那些功能又被拋棄掉了。我們可以在重構的時候依據這些功能把類進行拆分，通過拆分我們會首先得到無用類。然后進一步對它進行處理。
不僅僅單單一個類會成為無用類，有的時候，處在同一個關系圖中的類都回成為無用類(s)。
無用類通常因為兩種原因而出現：
１、技術上提供覆蓋面盡可能廣的支持：一個開發者推測一個類可能最終會被用到，即使沒有跡象表明現實中有與之對應的需求。
２、重構：通過對系統的修改，以前需要用到的類，現在變得陳舊過期了。
二、樹型依賴關系
出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully樹型依賴關系圖體現了對于系統的一種分解。樹中的每一個類都確定的被另外一個類使用。
鑒于在面向對象的應用程序中，功能分解本身通常會被看作是一種“狐臭”，一種樹型依賴結構像重復代碼一樣也應該被看作是一種“狐臭”。在圖3-6中，類Protocol除了被類Data Storage使用外，不再被別的地方使用。重用沒有發生。
三、靜態環狀依賴關系
出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully兩個類彼此使用對方是最簡單的環狀依賴關系。環狀依賴關系中也可以包含多個類。
環狀依賴關系會使環本身變得更加臃腫。環所具有的消極影響包括：
a、不可理解性：這些類不能夠被一個又一個的單獨理解，因為它們彼此依靠對方來實現功能。又或者是，一個類需要從多個類中選擇一個作為理解他們本身的前提。
b、可維護性：環狀依賴可能包含嚴重的并且不可預測的遞推關系，進而導致修改包含它的系統變得非常困難。
c、可計劃性：對環的修改到底會造成什么影響是很難預期的。估算到底需要多少的工作來完成這個修改會是一件很困難的事。
d、設計的清潔性：因為處在環中的那些類會直接或間接的訪問到處在環中的任意一個類，因此，從理論上講，類中的這種關系太隨意了。如果在這個環中又恰好把一個方法放到錯誤的類中，會導致理解這種設計變得更加困難。
e、重用性：這些類必須同時重用。如果在一個給定的語境中，只有其中的一個類所提供的功能被關注，因為處在環中，這個類不能被簡單的剝離并使用。
f、可測試性：這些類必須一起被測試。這增加了測試的要求以及堪錯的難度。如果想要獨立的測試其中的一個類，就必須使用“偽對象”。
g、異常處理：通常異常會在環中被“堆積”。如果環中的一個方法拋出了異常，他會潛在得影響環中的其他方法。
h、依賴引入問題：每一個處于環中的類同時又依賴于另一個處于環中的類處在環外的依賴關系。
顯然，環中的最大長度越大，代碼的“狐臭”味就越濃。然而，在有些地方，只包含兩個類的環卻是一種被推崇的設計方案，被應用于很多設計模式中（如迭代器模式）。
四、顯式依賴
面向對象支持封裝原理以及信息隱藏原理：內部的實現被隱藏于接口之中。客戶端的代碼無須知道任何有關于API的實現。另外，接口與實現類之間存在一些“裂痕”。很多開發者相信封裝和信息隱藏只會在成員變量被定義為“私有”的時候才會有效。這當然不是事實：在很多系統中都是支持“屬性”的，并且屬性可以被繼承。然而，有這樣一個事實，在一個系統中，顯式依賴關系卻是無法隱藏的。一個具有公共依賴關系的系統在被修改的時候，總會產生這樣那樣的問題，反之，私有的局部的依賴關系只會有小范圍的影響。
TDA(Tell,don't ask)原理指出了一條正確的途徑：理想情況下，客戶端告訴對象自己打算做什么。既不要通過已有對象獲取一個新的對象，更不要用那個新的對象進行一些操作。
下面看一個例子。在這個例子中，“訂單”有很多的狀態。我們可以簡單的以打開的訂單和關閉的訂單來簡單的區分一下。打開的訂單就是客戶未回款的訂單。現在我們要寫一些代碼，來計算所有打開的訂單的總額。
如果我們使用一個方法calculateValueOpenOrders(注意，這個方法是寫在調用方的，我們的調用方的類名定為Foo），而方法體如下。可以看出這個方法違反了TDA原理：
public float calculateValueOpenOrders(ListOfOrders orders)
{
float totalValue = 0.0f;
for (int i=0; i<orders.getNumber(); i++)
{
Order a = orders.getOrder(i);
if (a.isOpen)
{
totalValue += a.getValue();
}
}
return totalValue;
}
原因就是客戶端的Foo直接使用Orders來獲取其中的一些信息，而不是告訴Orders我要做什么。
出自Refactoring.in.Large.Software.Projects.Performing.Complex.Restructurings.Successfully現在我們做一下修改，把打開的訂單的金額計算移動到訂單內部進行。如果訂單是打開的，返回本訂單的金額，反之，返回0。
public class ListOfOrders
{
public float calculateValueOpenOrders()
{
float totalValue = 0.0f;
for (int i=0; i<getNumber(); i++)
{
Order a = getOrder(i);
totalValue += a.getOpenValue();
}
return totalValue;
}
}
public class Order
{
public float getOpenValue()
{
if (isOpen())
{
return getValue();
}
else
{
return 0;
}
}
}
我們可能會因為所有Order都要返回打開的訂單的金額而感覺不爽。如果你打算多次使用TDA原理，你可能通過增加一個方法“addOpenValue”來增加類order的柔性。但是，同時這也意味著類Order會知道另外的一些Order的存在。在這種情況下，我們可能會違反SOC（即單一職責原理）。我們不應該忽略這樣一點：在使用一些設計原理的時候，還要兼顧系統的平衡性。在這個例子中，這個方法是否應該加入取決于它是否真的與這個類的“領域模型”所匹配。
新的實現方式不僅僅使代碼更加簡短，而且還包括如下的優點：
功能有了正確的歸屬。在大多數情況下，上面第一段代碼中的方法calculateValueOpenOrders通常是被放到UI類中或者是一些Helper類中，而這些類通常有一些奇異的名字（比如OpenOrders Calculator）。這對于這個方法來說，不是一個正確的歸屬。
TDA原理確保類的使用應該局部化，而不要散步到系統的各個角落。因此可以簡化一些優化方案的實現。
posted on 2007-07-08 20:31
littlegai 閱讀(407)
評論(0) 編輯 收藏 引用 所屬分類:
我的讀書筆記