前言
工程大了以后，就需要分拆，不管是組件化還是插件化，還是什么，解耦是第一步，而且是各個(gè)維度的解耦。
模塊解耦合的方式
【1】Runtime 運(yùn)行時(shí)調(diào)用
Class targetClass = NSClassFromString(@"TestViewController");
id instance = [[targetClass alloc]init];
//屬性賦值
SEL sel = NSSelectorFromString(@"setImageName:");
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
[instance performSelector:sel withObject:@"測(cè)試參數(shù)"];
#pragma clang diagnostic pop
[self.navigationController pushViewController:instance animated:YES];
/*
Runtime 這樣的機(jī)制增加了程序的靈活性，可以通過給一個(gè)方法傳遞sel參數(shù),
讓這個(gè)方法動(dòng)態(tài)的執(zhí)行某一個(gè)方法，我們也可以通過配置文件制定需要執(zhí)行的方法，
程序讀取配置文件之后把方法的字符串翻譯成sel變量然后給相應(yīng)的對(duì)象發(fā)送這個(gè)消息。
*/
//當(dāng)然屬性的賦值還可以通過 KVC ，比上面的performSelector:sel 屬性的set方法更方便！
[instance setValue:infoDic[attributeName] forKey:attributeName];
【2】接口隔離，機(jī)制與策略分離，面向接口調(diào)用
雖然說公共模塊可以通過架構(gòu)設(shè)計(jì)來避免耦合業(yè)務(wù)，但是業(yè)務(wù)模塊之間還是會(huì)有耦合，而且這種情況是最多的，比如頁面跳轉(zhuǎn)啊，數(shù)據(jù)傳遞啊，這些情況前面的方法已經(jīng)不夠用了。那如何解耦不同業(yè)務(wù)模塊之間的代碼調(diào)用呢？
那就是面向接口調(diào)用，我們知道只要直接引用代碼，就會(huì)有依賴，比如：
// A 模塊
- (void)getSomeDataFromB {
B.getSomeData();
}
// B 模塊
- (void)getSomeData {
return self.data;
}
那么我們可以實(shí)現(xiàn)一個(gè) getSomeDataFromB 的接口，讓 A 只依賴這個(gè)接口，而 B 來實(shí)現(xiàn)這個(gè)接口，這樣就實(shí)現(xiàn)了 A 與 B 的解耦。
// 接口
@protocol BService <NSObject>
- (void)getSomeData;
@end
// A 模塊, 只依賴接口
- (void)getSomeDataFromB {
id b = findService(@protocol(BService));
b.getSomeData;
}
// B 模塊，實(shí)現(xiàn)BService接口
@interface B : NSObject <BService>
- (void)getSomeData {
return self.data;
}
@end
這樣就可以實(shí)現(xiàn)了即滿足了模塊之間調(diào)用，也實(shí)現(xiàn)了解耦
協(xié)議與實(shí)現(xiàn)做成了一個(gè)機(jī)制與策略分離
所謂機(jī)制即是抽象出來的規(guī)則,比如:
f(x)=x^2 x屬于R
所謂策略即是在具體場(chǎng)景中的應(yīng)用，比如當(dāng)x=2的時(shí)候:
f(2)=4 x=2
【3】中間件的路由通信解耦
A ：推薦CTMediator 方式的組件化解耦
可以看我這篇文章：iOS組件化設(shè)計(jì)與開發(fā)
B：URL路由式組件化解耦
還有一種手段就是通過定義一套協(xié)議來實(shí)現(xiàn)模塊間的通信，比如app里面的任何頁面，或者任何操作都是通過一個(gè)URL來喚起的話，這樣是不是就把各個(gè)復(fù)雜的業(yè)務(wù)之間解耦了呢，通信都使用URL.
為何如此URL(統(tǒng)一資源定位符)?
回到最開始我們描述的問題中第一點(diǎn): 模塊發(fā)現(xiàn)。其實(shí)也就是模塊這種資源的定位問題，
這個(gè)和URL設(shè)計(jì)的初衷是不謀而合的。URL整套的設(shè)計(jì)思路就是在整體的互聯(lián)網(wǎng)中解決信息孤島，
讓各個(gè)信息孤島之間能夠進(jìn)行資源發(fā)現(xiàn)和資源調(diào)用而設(shè)計(jì)。而我們目前所要處理的模塊間通信問題，
其實(shí)是這個(gè)宏大問題域的一個(gè)子集。因而選用URL協(xié)議，是一個(gè)非常順理成章的事情。
可以方便地在頁面之間構(gòu)建高內(nèi)聚和低耦合開發(fā)模式。他的核心思想是將每個(gè)頁面視為一種資源，并通過標(biāo)準(zhǔn)URL協(xié)議（統(tǒng)一資源定位器）定位每個(gè)可訪問的頁面（資源）。
