#開閉原則(Open-Close Principle)
##簡介
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
軟件實體（類，模塊，方法等等）應當對擴展開放，對修改關閉，即軟件實體應當在不修改的前提下擴展。
問題由來:在軟件的生命周期內，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經過重新測試。
解決方案: 開閉原則是面向對象設計中最基礎的設計原則，它指導我們如何建立穩定靈活的系統。開閉原則可能是設計模式六項原則中定義最模糊的一個了，它只告訴我們對擴展開放，對修改關閉，可是到底如何才能做到對擴展開放，對修改關閉，并沒有明確的告訴我們。以前，如果有人告訴我“你進行設計的時候一定要遵守開閉原則”，我會覺的他什么都沒說，但貌似又什么都說了。因為開閉原則真的太虛了。
在仔細思考以及仔細閱讀很多設計模式的文章后，終于對開閉原則有了一點認識。其實，我們遵循設計模式其它5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要我們對其它5項原則遵守的好了，設計出的軟件自然是符合開閉原則的，這個開閉原則更像是前面五項原則遵守程度的“平均得分”，前面5項原則遵守的好，平均分自然就高，說明軟件設計開閉原則遵守的好；如果前面5項原則遵守的不好，則說明開閉原則遵守的不好。
開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟件架構的穩定。而軟件中易變的細節，我們用從抽象派生的實現類來進行擴展，當軟件需要發生變化時，我們只需要根據需求重新派生一個實現類來擴展就可以了。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行。
**其它的5項原則，恰恰是告訴我們用抽象構建框架，用實現擴展細節的注意事項而已：單一職責原則告訴我們實現類要職責單一；里氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口編程；接口隔離原則告訴我們在設計接口的時候要精簡單一；迪米特法則告訴我們要降低耦合。而開閉原則是總綱，他告訴我們要對擴展開放，對修改關閉**。
最后說明一下如何去遵守這六個原則。對這六個原則的遵守并不是是和否的問題，而是多和少的問題，也就是說，我們一般不會說有沒有遵守，而是說遵守程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是一樣，制定這六個原則的目的并不是要我們刻板的遵守他們，而需要根據實際情況靈活運用。對他們的遵守程度只要在一個合理的范圍內，就算是良好的設計。我們用一幅圖來說明一下。
圖中的每一條維度各代表一項原則，我們依據對這項原則的遵守程度在維度上畫一個點，則如果對這項原則遵守的合理的話，這個點應該落在紅色的同心圓內部；如果遵守的差，點將會在小圓內部；如果過度遵守，點將會落在大圓外部。一個良好的設計體現在圖中，應該是六個頂點都在同心圓中的六邊形。
##實例
在軟件開發過程中，永遠不變的就是變化。開閉原則是使我們的軟件系統擁抱變化的核心原則之一。對擴展可放，對修改關閉給出了高層次的概括，即在需要對軟件進行升級、變化時應該通過擴展的形式來實現，而非修改原有代碼。當然這只是一種比較理想的狀態，是通過擴展還是通過修改舊代碼需要根據代碼自身來定。
在Volley中，開閉原則體現得比較好的是Request類族的設計。我們知道，在開發C/S應用時，服務器返回的數據格式多種多樣，有字符串類型、xml、json等。而解析服務器返回的Response的原始數據類型則是通過Request類來實現的，這樣就使得Request類對于服務器返回的數據格式有良好的擴展性，即Request的可變性太大。
例如我們返回的數據格式是Json，那么我們使用JsonObjectRequest請求來獲取數據，它會將結果轉成JsonObject對象，我們看看JsonObjectRequest的核心實現。
```
/**
* A request for retrieving a {@link JSONObject} response body at a given URL, allowing for an
* optional {@link JSONObject} to be passed in as part of the request body.
*/
public class JsonObjectRequest extends JsonRequest<JSONObject> {
// 代碼省略
@Override
protected Response<JSONObject> parseNetworkResponse(NetworkResponse response) {
try {
String jsonString =
new String(response.data, HttpHeaderParser.parseCharset(response.headers));
return Response.success(new JSONObject(jsonString),
HttpHeaderParser.parseCacheHeaders(response));
} catch (UnsupportedEncodingException e) {
return Response.error(new ParseError(e));
} catch (JSONException je) {
return Response.error(new ParseError(je));
}
}
}
```
JsonObjectRequest通過實現Request抽象類的parseNetworkResponse解析服務器返回的結果，這里將結果轉換為JSONObject，并且封裝到Response類中。
例如Volley添加對圖片請求的支持，即ImageLoader( 已內置 )。這個時候我的請求返回的數據是Bitmap圖片。因此我需要在該類型的Request得到的結果是Request，但支持一種數據格式不能通過修改源碼的形式，這樣可能會為舊代碼引入錯誤。但是你又需要支持新的數據格式，此時我們的開閉原則就很重要了，對擴展開放，對修改關閉。我們看看Volley是如何做的。
```
/**
* A canned request for getting an image at a given URL and calling
* back with a decoded Bitmap.
*/
public class ImageRequest extends Request<Bitmap> {
// 代碼省略
// 將結果解析成Bitmap，并且封裝套Response對象中
@Override
protected Response<Bitmap> parseNetworkResponse(NetworkResponse response) {
// Serialize all decode on a global lock to reduce concurrent heap usage.
synchronized (sDecodeLock) {
try {
return doParse(response);
} catch (OutOfMemoryError e) {
VolleyLog.e("Caught OOM for %d byte image, url=%s", response.data.length, getUrl());
return Response.error(new ParseError(e));
}
}
}
/**
* The real guts of parseNetworkResponse. Broken out for readability.
*/
private Response<Bitmap> doParse(NetworkResponse response) {
byte[] data = response.data;
BitmapFactory.Options decodeOptions = new BitmapFactory.Options();
Bitmap bitmap = null;
// 解析Bitmap的相關代碼,在此省略
if (bitmap == null) {
return Response.error(new ParseError(response));
} else {
return Response.success(bitmap, HttpHeaderParser.parseCacheHeaders(response));
}
}
}
```
需要添加某種數據格式的Request時，只需要繼承自Request類，并且實現相應的方法即可。這樣通過擴展的形式來應對軟件的變化或者說用戶需求的多樣性，即避免了破壞原有系統，又保證了軟件系統的可擴展性。
