- 原文連接：https://academy.realm.io/posts/donn-felker-solid-part-1/
- 譯文出自：kailaisi的簡書
- 譯 者：kailaisi
SOLID原則簡介
SOLID是一種縮寫躏吊，是面向對象設計的五項基本原則空猜。
在未來一段時間他挎，我將會深入研究每一個原則英支，解釋它的含義以及它與Android開發(fā)的關系扛门。
SOLID原則背景
SOLID是在2000年早期由Robert Martin (AKA: Uncle Bob)和Michael Feathers領導的團隊一起提出的。這五個面向對象設計的基本原則，能夠極大的幫助開發(fā)人員，增強系統(tǒng)的可維護性以及可擴展性航邢。
如果你不熟悉Uncle Bob或Michael Feathers，我強烈建議挑選他們的幾本著作來閱讀骄蝇。Uncle Bob編寫的《敏捷軟件開發(fā):原則膳殷、模式與實踐》和《代碼整潔之道》是其在軟件方面的主要著作。Michael Feathers編寫的《修改代碼的藝術》是我在領導團隊時要求每一個開發(fā)者必讀的一本書九火。它能夠幫助你重構處理舊代碼并增強其可維護性赚窃。更重要的是，它能夠幫助你理解“遺留代碼”的真正含義岔激。您的代碼最近有測試過么勒极？沒有！鹦倚？河质！嗯冀惭，那么你的代碼可能已經(jīng).....你猜對了......是遺留代碼了震叙。
閱讀這些書籍對于我的生涯具有決定性作用。我強烈建議每一個開發(fā)者能夠把它們放入自己的閱讀清單中散休，并且能夠把它們放在書架上以便經(jīng)趁铰ィ回顧。
我記得戚丸，早在2003年划址，我就在各種.Net工程中使用了SOLID原則。當時限府，SOLID原則的提出確實使我震驚夺颤，因為當時我的.Net代碼正在變得越來越雜亂無章，而且毫無架構可言胁勺。這不僅僅是.Net的癥狀世澜，在所有新的技術（例如移動設備-Android等）中也存在著這樣的問題。新技術在SOLID原則的使用上逐漸變得成熟署穗，這也是為何SOLID原則越來越重要寥裂。
最近關于Uncle Bob的《代碼整潔之道》在安卓社區(qū)中復蘇嵌洼，我覺得有必要來解釋一些Uncle Bob中提及的基本原則。這一系列的文章將會討論SOLID原則以及它在安卓開發(fā)中的應用封恰。
--------------------------------特別華麗的分割線-------------------------------
單一職責原則
單一職責原則（SRP）很容易理解麻养。它的描述如下：
一個類應該只有一個引起它變化的原因。
我們以 RecyclerView 和它的adapter為例诺舔。正如你所知道的那樣鳖昌，RecyclerView是一個能夠在屏幕上顯示數(shù)據(jù)的靈活控件。為了將數(shù)據(jù)展示在屏幕上低飒，我們需要一個RecyclerView.Adapter遗遵。
adapter從數(shù)據(jù)集獲取數(shù)據(jù)，并將其展示在視圖中逸嘀。adapter中最重要的一部分可以說是onBindViewHolder方法（有時候可能是ViewHolder本身谱邪，但為了簡潔我們仍然堅持是onBindViewHolder方法）蛛枚。RecyclerView的adapter只有一個職責：將對象映射到的顯示在屏幕上的對應視圖中。
假設對象以及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);
}
上面的代碼就違反了單一職責原則。
Why?
adapter中的onBindViewHolder方法不僅僅將order對象映射到視圖中惹悄，而且負責了價格的計算以及數(shù)據(jù)的格式處理强戴。這違背了單一職責原則。Adatper應該僅僅負責將order對象映射到對應的視圖残家。onBindViewHolder承擔了兩個額外的職責榆俺。
為什么這是一個問題？
一個類中包含了多種職責經(jīng)常會引起一系列問題坞淮。
首先茴晋，order中的邏輯處理是與adapter耦合的。如果你需要在其他地方顯示order的總價回窘，你就必須復制那段邏輯诺擅。一旦發(fā)生這種情況，你的應用程序將會面臨著邏輯重復問題啡直。當你更新某一處的代碼時烁涌，很可能忘記更新另一處的代碼。寫到這里酒觅，相信你已經(jīng)抓住重點了撮执。
第二個問題和第一個問題一樣——數(shù)據(jù)的格式處理與adapter耦合了。如果需要移動或者更新格式呢舷丹？最終抒钱，我們可能會使一個類負責了遠多于他應該負責的事情。由于在一個位置負責了太多的任務，應用程序更容易發(fā)生錯誤继效。
值得慶幸的是症杏，通過將總計的計算提取到Order對象以及將貨幣的格式化移動到貨幣格式化類中，我們就可以解決這個簡單的例子瑞信。格式化類能夠被order類調用厉颤。
更新后的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);
}
你可能會想：“這很容易啊，這難道不是很簡單么凡简？”逼友。難道總是那么容易么？就像大部分軟件的答案一樣秤涩，“這取決于....”帜乞。
讓我們更深入一些....
“職責”的含義是什么呢？
我相信很難找到比Uncle Bob形容的更恰當?shù)拇鸢噶丝鹁欤虼宋以谶@里引用他的話：
在單一職責原則（SRP）中我們將職責定義為：一個變化的原因黎烈。如果你能夠想到多種動機來改變一個類，那么這個類就包含多種職責匀谣。
事情就是這樣照棋，有時候很難察覺到，特別是你已經(jīng)寫了很長時間代碼之后武翎。在這一點上烈炭，這句名言通常會浮現(xiàn)在腦海中:
只見樹木 ，不見森林宝恶。
在軟件領域符隙，這句話意味著你太關注于代碼的細節(jié)，而忽略了整體的框架垫毙。比如：你編寫的代碼看起來運行良好霹疫，但那是因為你在這個類上花費了很長時間以至于忽略了它身兼多職。
對于我們來說露久，最大的挑戰(zhàn)是什么時候該使用SRP原則更米。以下面的adapter代碼為例欺栗，如果我們重新回顧一下代碼毫痕，我們就會發(fā)現(xiàn)，很多情況都會導致我們不得不修改代碼迟几。
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類負責繪制視圖消请，負責將order綁定到視圖中，負責創(chuàng)建ViewHolder等等类腮。這個類就是一個多職責類臊泰。
這些職責應該被拆分開么？
這最終取決于應用的發(fā)展趨勢蚜枢。如果應用經(jīng)常更改視圖的展示方式以及數(shù)據(jù)的連接功能（視圖的邏輯）缸逃，就像Uncle Bob所描述的那樣针饥，這種設計就有一些問題，因為一種改變需要改變另一個事情需频。視圖結構的變化需要修改adapter丁眼，從而導致這個設計變得有些死板。如果應用程序一直都不會變更這部分的需求昭殉，那么就沒有必要將他們分離苞七。在這種情況下，進行功能的隔離反而會導致不必要的復雜性挪丢。
那么蹂风，我們應該怎么做呢？
一個說明剛性的例子
假設有一個新的產(chǎn)品需求：如果訂單的總價格是0時乾蓬，視圖上不再顯示文本形式的總價惠啄，而是顯示一張亮黃色的“Free”圖片。這個邏輯應該在哪里處理任内？在一種形式下礁阁，你需要一個TextView，另一種形式下族奢，你需要一個ImageView姥闭。代碼有兩處需要修改：
- 展示視圖的地方
- 處理邏輯的地方
我所遇到的大部分的程序，都是在adapter中處理越走。不幸的是棚品，當你的視圖改變時，需要你修改Adapter廊敌。如果邏輯的處理也在adapter中處理铜跑，那么這種需求也會要求你必須修改adapter中關于邏輯部分的代碼。這就為adapter增加了另一個職責骡澈。
這正是一些類似于MVP模式等方案中所提及的锅纺，通過必要的解耦方式，來降低類的復雜度肋殴。這種處理方式增強了代碼擴展的靈活性囤锉、可組合性以及可測性。例如护锤，View層應該實現(xiàn)一個接口來提供對外的交互官地，presenter層來執(zhí)行必要的邏輯處理。persenter在MVP模式中只負責展示的邏輯烙懦，僅此而已驱入。
將邏輯處理部分從adapter轉移到presenter中，這就會使adapter更加遵循單一職責原則。
事情遠不止這樣.....
如果你深入研究過RecyclerView adapter亏较，你會發(fā)現(xiàn)adapter做了很多事情莺褒。比如：
- 繪制視圖
- 創(chuàng)建ViewHolder類
- 回收ViewHolder
- 提供展示數(shù)據(jù)的數(shù)量
- 等等....
由于SRP是單一原則，你可能會疑惑雪情，adapter的這種設計是否遵守SRP原則呢癣朗？Uncle Bob Martin 是這樣解釋的
只有變化發(fā)生的時候，這種改變才能稱得上改變旺罢。如果沒有發(fā)生任何變化旷余，那么將SRP或者任何其他原則應用在這個事件上是很不明智的。
Adapter本身就是被設計成為一種執(zhí)行這些操作的類扁达。畢竟adapter只是適配器模式的一種簡單實現(xiàn)正卧。在這種情況下，將視圖的繪制跪解、ViewHolder的創(chuàng)建在一個地方進行處理是合理的炉旷。也就是說，這個類的職責就是這樣叉讥。然而窘行，引入額外的行為（比如視圖邏輯的處理）就破壞了SRP原則⊥疾郑可以通過MVP模式或者其他重構的方法來避免這種情況的發(fā)生罐盔。
總結
單一職責原則可能是SOLID原則中最簡單的一種，因為它只有一句簡單的描述：
一個類應該只有一個引起它變化的原因救崔。
也就是說惶看，這也是最難以應用的原則之一。過分的分析代碼六孵，很容易讓你覺得有必要使用SRP原則纬黎，而一旦你這樣做了，你的應用程序可能就會變得復雜劫窒。我的建議是遠離代碼本今，客觀得看待它。將你對代碼的感性刨除出去主巍，用新眼光看待它冠息。如果你這么做了，你將會發(fā)現(xiàn)你代碼中一些不同的東西煤禽。你可能會意識到你需要使用SRP模式铐达，或者你可能意識到你已經(jīng)做的很棒。不管如何檬果，花費一些時間來重新審視一下自己的代碼。
最后，隨著程序變更选脊，你可能發(fā)現(xiàn)原來不需要應用SRP的地方需要使用這種原則杭抠。這種情況是完全ok的，也是建議這么處理的恳啥。
Happy coding...
