- 原文連接：https://academy.realm.io/posts/donn-felker-solid-part-1/
- 譯文出自：kailaisi的簡書
- 譯 者：kailaisi
SOLID原則簡介
SOLID是一種縮寫，是面向?qū)ο笤O(shè)計的五項基本原則。
里氏替換原則
依賴倒置原則
接口隔離原則
在未來一段時間，我將會深入研究每一個原則，解釋它的含義以及它與Android開發(fā)的關(guān)系。
SOLID原則背景
SOLID是在2000年早期由Robert Martin (AKA: Uncle Bob)和Michael Feathers領(lǐng)導(dǎo)的團(tuán)隊一起提出的。這五個面向?qū)ο笤O(shè)計的基本原則，能夠極大的幫助開發(fā)人員，增強系統(tǒng)的可維護(hù)性以及可擴(kuò)展性。
如果你不熟悉Uncle Bob或Michael Feathers，我強烈建議挑選他們的幾本著作來閱讀。Uncle Bob編寫的《敏捷軟件開發(fā):原則、模式與實踐》和《代碼整潔之道》是其在軟件方面的主要著作。Michael Feathers編寫的《修改代碼的藝術(shù)》是我在領(lǐng)導(dǎo)團(tuán)隊時要求每一個開發(fā)者必讀的一本書。它能夠幫助你重構(gòu)處理舊代碼并增強其可維護(hù)性。更重要的是，它能夠幫助你理解“遺留代碼”的真正含義。您的代碼最近有測試過么？沒有！？！嗯，那么你的代碼可能已經(jīng).....你猜對了......是遺留代碼了。
閱讀這些書籍對于我的生涯具有決定性作用。我強烈建議每一個開發(fā)者能夠把它們放入自己的閱讀清單中，并且能夠把它們放在書架上以便經(jīng)常回顧。
我記得，早在2003年，我就在各種.Net工程中使用了SOLID原則。當(dāng)時，SOLID原則的提出確實使我震驚，因為當(dāng)時我的.Net代碼正在變得越來越雜亂無章，而且毫無架構(gòu)可言。這不僅僅是.Net的癥狀，在所有新的技術(shù)（例如移動設(shè)備-Android等）中也存在著這樣的問題。新技術(shù)在SOLID原則的使用上逐漸變得成熟，這也是為何SOLID原則越來越重要。
最近關(guān)于Uncle Bob的《代碼整潔之道》在安卓社區(qū)中復(fù)蘇，我覺得有必要來解釋一些Uncle Bob中提及的基本原則。這一系列的文章將會討論SOLID原則以及它在安卓開發(fā)中的應(yīng)用。
--------------------------------特別華麗的分割線-------------------------------
單一職責(zé)原則
單一職責(zé)原則（SRP）很容易理解。它的描述如下：
一個類應(yīng)該只有一個引起它變化的原因。
我們以 RecyclerView 和它的adapter為例。正如你所知道的那樣，RecyclerView是一個能夠在屏幕上顯示數(shù)據(jù)的靈活控件。為了將數(shù)據(jù)展示在屏幕上，我們需要一個RecyclerView.Adapter。
adapter從數(shù)據(jù)集獲取數(shù)據(jù)，并將其展示在視圖中。adapter中最重要的一部分可以說是onBindViewHolder方法（有時候可能是ViewHolder本身，但為了簡潔我們?nèi)匀粓猿质莖nBindViewHolder方法）。RecyclerView的adapter只有一個職責(zé)：將對象映射到的顯示在屏幕上的對應(yīng)視圖中。
假設(shè)對象以及RecyclerView.Adapter的實現(xiàn)如下：
public class LineItem {
private String description;
private int quantity;
private long price;
// ... getters/setters
}
public class Order {
private int orderNumber;
private List<LineItem> lineItems = new ArrayList<LineItem>();
// ... getters/setters
}
public class OrderRecyclerAdapter extends RecyclerView.Adapter<OrderRecyclerAdapter.ViewHolder> {
private List<Order> items;
private int itemLayout;
public OrderRecyclerAdapter(List<Order> items, int itemLayout) {
this.items = items;
this.itemLayout = itemLayout;
}
@Override
public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
View v = LayoutInflater.from(parent.getContext()).inflate(itemLayout, parent, false);
return new ViewHolder(v);
}
@Override
public void onBindViewHolder(ViewHolder holder, int position) {
// TODO: bind the view here
}
@Override
public int getItemCount() {
return items.size();
}
public static class ViewHolder extends RecyclerView.ViewHolder {
public TextView orderNumber;
public TextView orderTotal;
public ViewHolder(View itemView) {
super(itemView);
orderNumber = (TextView) itemView.findViewById(R.id.order_number);
orderTotal = (ImageView) itemView.findViewById(R.id.order_total);
}
}
}
在上面的例子中，onBindViewHolder方法是空的。我看到過很多實現(xiàn)是這樣的：
@Override
public void onBindViewHolder(ViewHolder holder, int position) {
Order order = items.get(position);
holder.orderNumber.setText(order.getOrderNumber().toString());
long total = 0;
for (LineItem item : order.getItems()) {
total += item.getPrice();
}
NumberFormat formatter = NumberFormat.getCurrencyInstance(Locale.US);
String totalValue = formatter.format(cents / 100.0); // Must divide by a double otherwise we'll lose precision
holder.orderTotal.setText(totalValue)
holder.itemView.setTag(order);
}
上面的代碼就違反了單一職責(zé)原則。
Why?
adapter中的onBindViewHolder方法不僅僅將order對象映射到視圖中，而且負(fù)責(zé)了價格的計算以及數(shù)據(jù)的格式處理。這違背了單一職責(zé)原則。Adatper應(yīng)該僅僅負(fù)責(zé)將order對象映射到對應(yīng)的視圖。onBindViewHolder承擔(dān)了兩個額外的職責(zé)。
為什么這是一個問題？
一個類中包含了多種職責(zé)經(jīng)常會引起一系列問題。
首先，order中的邏輯處理是與adapter耦合的。如果你需要在其他地方顯示order的總價，你就必須復(fù)制那段邏輯。一旦發(fā)生這種情況，你的應(yīng)用程序?qū)媾R著邏輯重復(fù)問題。當(dāng)你更新某一處的代碼時，很可能忘記更新另一處的代碼。寫到這里，相信你已經(jīng)抓住重點了。
第二個問題和第一個問題一樣——數(shù)據(jù)的格式處理與adapter耦合了。如果需要移動或者更新格式呢？最終，我們可能會使一個類負(fù)責(zé)了遠(yuǎn)多于他應(yīng)該負(fù)責(zé)的事情。由于在一個位置負(fù)責(zé)了太多的任務(wù)，應(yīng)用程序更容易發(fā)生錯誤。
值得慶幸的是，通過將總計的計算提取到Order對象以及將貨幣的格式化移動到貨幣格式化類中，我們就可以解決這個簡單的例子。格式化類能夠被order類調(diào)用。
更新后的onBindViewHolder方法如下：
@Override
public void onBindViewHolder(ViewHolder holder, int position) {
Order order = items.get(position);
holder.orderNumber.setText(order.getOrderNumber().toString());
holder.orderTotal.setText(order.getOrderTotal()); // A String, the calculation and formatting moved elsewhere
holder.itemView.setTag(order);
}
你可能會想：“這很容易啊，這難道不是很簡單么？”。難道總是那么容易么？就像大部分軟件的答案一樣，“這取決于....”。
讓我們更深入一些....
“職責(zé)”的含義是什么呢？
我相信很難找到比Uncle Bob形容的更恰當(dāng)?shù)拇鸢噶耍虼宋以谶@里引用他的話：
在單一職責(zé)原則（SRP）中我們將職責(zé)定義為：一個變化的原因。如果你能夠想到多種動機來改變一個類，那么這個類就包含多種職責(zé)。
事情就是這樣，有時候很難察覺到，特別是你已經(jīng)寫了很長時間代碼之后。在這一點上，這句名言通常會浮現(xiàn)在腦海中:
只見樹木 ，不見森林。
在軟件領(lǐng)域，這句話意味著你太關(guān)注于代碼的細(xì)節(jié)，而忽略了整體的框架。比如：你編寫的代碼看起來運行良好，但那是因為你在這個類上花費了很長時間以至于忽略了它身兼多職。
對于我們來說，最大的挑戰(zhàn)是什么時候該使用SRP原則。以下面的adapter代碼為例，如果我們重新回顧一下代碼，我們就會發(fā)現(xiàn)，很多情況都會導(dǎo)致我們不得不修改代碼。
public class OrderRecyclerAdapter extends RecyclerView.Adapter<OrderRecyclerAdapter.ViewHolder> {
private List<Order> items;
private int itemLayout;
public OrderRecyclerAdapter(List<Order> items, int itemLayout) {
this.items = items;
this.itemLayout = itemLayout;
}
@Override
public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
View v = LayoutInflater.from(parent.getContext()).inflate(itemLayout, parent, false);
return new ViewHolder(v);
}
@Override
public void onBindViewHolder(ViewHolder holder, int position) {
Order order = items.get(position);
holder.orderNumber.setText(order.getOrderNumber().toString());
holder.orderTotal.setText(order.getOrderTotal()); // Move the calculation and formatting elsewhere
holder.itemView.setTag(order);
}
@Override
public int getItemCount() {
return items.size();
}
public static class ViewHolder extends RecyclerView.ViewHolder {
public TextView orderNumber;
public TextView orderTotal;
public ViewHolder(View itemView) {
super(itemView);
orderNumber = (TextView) itemView.findViewById(R.id.order_number);
orderTotal = (ImageView) itemView.findViewById(R.id.order_total);
}
}
}
該adapter類負(fù)責(zé)繪制視圖，負(fù)責(zé)將order綁定到視圖中，負(fù)責(zé)創(chuàng)建ViewHolder等等。這個類就是一個多職責(zé)類。
這些職責(zé)應(yīng)該被拆分開么？
這最終取決于應(yīng)用的發(fā)展趨勢。如果應(yīng)用經(jīng)常更改視圖的展示方式以及數(shù)據(jù)的連接功能（視圖的邏輯），就像Uncle Bob所描述的那樣，這種設(shè)計就有一些問題，因為一種改變需要改變另一個事情。視圖結(jié)構(gòu)的變化需要修改adapter，從而導(dǎo)致這個設(shè)計變得有些死板。如果應(yīng)用程序一直都不會變更這部分的需求，那么就沒有必要將他們分離。在這種情況下，進(jìn)行功能的隔離反而會導(dǎo)致不必要的復(fù)雜性。
那么，我們應(yīng)該怎么做呢？
一個說明剛性的例子
假設(shè)有一個新的產(chǎn)品需求：如果訂單的總價格是0時，視圖上不再顯示文本形式的總價，而是顯示一張亮黃色的“Free”圖片。這個邏輯應(yīng)該在哪里處理？在一種形式下，你需要一個TextView，另一種形式下，你需要一個ImageView。代碼有兩處需要修改：
- 展示視圖的地方
- 處理邏輯的地方
我所遇到的大部分的程序，都是在adapter中處理。不幸的是，當(dāng)你的視圖改變時，需要你修改Adapter。如果邏輯的處理也在adapter中處理，那么這種需求也會要求你必須修改adapter中關(guān)于邏輯部分的代碼。這就為adapter增加了另一個職責(zé)。
這正是一些類似于MVP模式等方案中所提及的，通過必要的解耦方式，來降低類的復(fù)雜度。這種處理方式增強了代碼擴(kuò)展的靈活性、可組合性以及可測性。例如，View層應(yīng)該實現(xiàn)一個接口來提供對外的交互，presenter層來執(zhí)行必要的邏輯處理。persenter在MVP模式中只負(fù)責(zé)展示的邏輯，僅此而已。
將邏輯處理部分從adapter轉(zhuǎn)移到presenter中，這就會使adapter更加遵循單一職責(zé)原則。
事情遠(yuǎn)不止這樣.....
如果你深入研究過RecyclerView adapter，你會發(fā)現(xiàn)adapter做了很多事情。比如：
- 繪制視圖
- 創(chuàng)建ViewHolder類
- 回收ViewHolder
- 提供展示數(shù)據(jù)的數(shù)量
- 等等....
由于SRP是單一原則，你可能會疑惑，adapter的這種設(shè)計是否遵守SRP原則呢？Uncle Bob Martin 是這樣解釋的
只有變化發(fā)生的時候，這種改變才能稱得上改變。如果沒有發(fā)生任何變化，那么將SRP或者任何其他原則應(yīng)用在這個事件上是很不明智的。
Adapter本身就是被設(shè)計成為一種執(zhí)行這些操作的類。畢竟adapter只是適配器模式的一種簡單實現(xiàn)。在這種情況下，將視圖的繪制、ViewHolder的創(chuàng)建在一個地方進(jìn)行處理是合理的。也就是說，這個類的職責(zé)就是這樣。然而，引入額外的行為（比如視圖邏輯的處理）就破壞了SRP原則。可以通過MVP模式或者其他重構(gòu)的方法來避免這種情況的發(fā)生。
總結(jié)
單一職責(zé)原則可能是SOLID原則中最簡單的一種，因為它只有一句簡單的描述：
一個類應(yīng)該只有一個引起它變化的原因。
也就是說，這也是最難以應(yīng)用的原則之一。過分的分析代碼，很容易讓你覺得有必要使用SRP原則，而一旦你這樣做了，你的應(yīng)用程序可能就會變得復(fù)雜。我的建議是遠(yuǎn)離代碼，客觀得看待它。將你對代碼的感性刨除出去，用新眼光看待它。如果你這么做了，你將會發(fā)現(xiàn)你代碼中一些不同的東西。你可能會意識到你需要使用SRP模式，或者你可能意識到你已經(jīng)做的很棒。不管如何，花費一些時間來重新審視一下自己的代碼。
最后，隨著程序變更，你可能發(fā)現(xiàn)原來不需要應(yīng)用SRP的地方需要使用這種原則。這種情況是完全ok的，也是建議這么處理的。
Happy coding...
