モジュール化とデカップリング

16671 ワード
http://blog.cnbluebox.com/blog/2015/11/28/module-and-decoupling/
本論文では主にiOS開発において、モジュール化されたエンジニアリングアーキテクチャの1つの構成を述べ、本明細書では主にcocoapodsに基づいてモジュール化されたスキームを述べ、iOS開発がどのようにモジュール分割されているかを詳細に説明した.
なぜモジュール化しますか?
モジュール設計原則モジュール開発にはどのようなメリットと欠点がありますか?
デカップリング1.なぜモジュール化しますか?
基本的なコード設計の原則はよく知っています.「Don’t repeat yourself!」というのは、各工程に独自のアーキテクチャがあります.入門したばかりの開発者でも、何日間のコードを書いても、よく使われている重複コードを単独に取り出してcommonというところに置いて、コード多重を実現します.このように見ると、開発者はいずれも多かれ少なかれ構造的なことをしています.各チームは少なくとも1～2人がこのようなことをしています.
アプリコードアーキテクチャといえば、Samuraiの開発者郭虹宇が群の中でこの素晴らしい話をしたことを覚えています.
派はapp開発には犬のPアーキテクチャが必要ではないということです.第二派は自分たちのNB構造があると言います.第三派はモジュール化が十分であれば、各モジュールは自分の構造を持つべきです.
この3つの観点の出発点は、私も分かりやすいと思います.最初は個人の開発者で、個人の能力がとても強いです.いつも一人で早くappを作っています.彼の映像の中では自分の枠を多く作る必要はありません.しかし、彼も自分の仕組みを持っています.第二派はいくつかの会社や大手会社であるべきです.NBの構造はチームにとって大きな意義を持っています.安定した反復を保証し、規範と持続可能性を保証します.第三派はBATのような多くのBUを持っているスーパー会社であるべきです.或いはいくつかの先進的な開発者達は、より良いモジュール化が、appにまたがるコードと機能の多重化を実現し、より良い資源を共有し、輪を作らないようにします.
なぜモジュール化しますか?もう明らかになりました.モジュール化されたコードフレームは最高の意味がありません.信じないで、アップルのフレームを見てみてください.
2.モジュール設計原則
モジュール化の最高の意味がないなら、どうやってプロジェクトのモジュール化の分割ができますか?ここで私の経験を共有します.
下のモジュールを越えると、より安定して、より抽象的で、より高い再現性を持つべきです.
この点については、皆さんが比較的に認めているべきだと思います.下の階のSDKほど安定しているはずです.安定した最も直観的な表現はAPIが長い間変わらないことです.すべての変化因子は露出しないでください.そのモジュールに頼ることを避けてください.しかし、APIのセットを設計するには長い間変わらないで、設計する時に抽象的になることができます.つまり、私たちの抽象的な総括能力が必要です.
安定性 もう一つの特徴はBモジュールがAモジュールに依存している場合、Bモジュールが安定していますが、Aモジュールが不安定であれば、Bモジュールも不安定になります.
安定したモジュールを不安定なモジュールに依存させないでください.
上に依頼しないほうがいいと言っていますが、Bモジュールは確かにAモジュールに不可欠なコードに依存しています.どうすればいいですか?仮に依存コードセグメントがxであると仮定して、今はxの特性を見てみます.Xが高復用のコードセグメントであれば、Aモジュールからxを取り出して、モジュールXだけにしてもいいです.BモジュールはXモジュールに依存すればいいです.霊の場合、xは方法や関数で、モジュールを作るのにあまり適していないので、Bモジュールの中にxコードをコピーすればいいです. 安定性 和 自己補完性
上の二つの方法があまりよくないなら、私たちは後の結合についてどのように結合するかを教えます.
モジュールの多重化度を向上させ、完全性からコード多重化より優れている場合があります.
自己補完性とは、できるだけ少ないモジュールに依存してコード多重化を行うことです.
たとえば、モジュールがあります.  Utils たくさんのcategoryツール方法などが入っています.日常UI製品の開発には、このUtilsを頼りにすると便利ですが、今は比較的基本的なモジュールを書きたいです.多重度がもっと高いことを要求します.この時はUtilsの中のいくつかの方法を使う必要があります.これは上の設計原則とは違っています.ですから、このモジュールの自己完全性のために、Utilsモジュールに依存するのではなく、このいくつかの方法を再実現できます.
各モジュールは一つのことしかできません.Commonを出現させないでください.
モジュール化構造は工程構造をより明確にし、モジュールごとに一つのことしかしないので、自分の名前が付いています.このモジュールが良性的に発展することができます.しかし、この名前は絶対にCommonと呼ばないでください.このようなことをしたことがありますか?このCommonは毒瘤になりました.みんな依存しています.関連コードもいっぱいあります.このUtilsモジュールは私達の設計原則の第一点である反面教材です.モジュールのデザインをよく考えて、もうだめです.もし多重性があれば、モジュールを単独で作ってもいいです.なぜいけないですか?
あなたのアーキテクチャの階層数によって上から下へ依存して、下のモジュールが上のモジュールに依存する現象が現れないようにしてください.
ビジネスモジュール間でも、できるだけ結合しないでください.
3.モジュール開発にはどのようなメリットと欠点がありますか?
利点:1、コードの多重度を向上させるだけでなく、同じ機能モジュールが自己補完性を実現すれば、複数のアプリで2、トラヒック分離を多重化でき、チーム間でコード制御とバージョンリスク制御の実現3、モジュール化はコードのパッケージ性、合理性に対して一定の要求があります.開発者の設計能力を高める.
欠点は、モジュール化ももちろん欠点があります.1、入門の敷居が高く、初心者入門に必要なコストもより高いです.2、工具の使用コストは、チーム間とモジュール間の配合コストが高くなり、開発効率が短くなります.
しかし、長期的な影響から、メリットはデメリットよりもはるかに大きいので、モジュール化は依然として最適なアーキテクチャ選択である.
4.結合と通信
まず、なぜ結合を解除するかというと、モジュール化はプロジェクトのコードを50 podまたはframe ebookに分割して完成したというわけではありません.モジュール間の本当の結合を実現するためには本当のモジュール化が必要です.そうでなければ、モジュール間のコードがお互いに呼出され、循環依存しているなら、元のフォルダに入れるのと同じです.じゃ、モジュール間の結合は何ですか?
モジュールの結合の目的は、モジュール設計に基づく原則として、モジュール間の循環依存性をなくし、業務モジュール間の依存性を解除することである.
4.1共通モジュール下層
これは実際にはまだ説明されているモジュール設計です.一つの工程の構造は多くの層に分けられているかもしれませんが、開発の過程で、下の層にあるべきモジュールを上の層のモジュールに依存させることに注意しない人がいます.この場合はモジュールの設計を改造し、一方的に依存するべきです.
例えば、一般的な例として、共通のWebViewモジュールの中にWebView Controllerの基質があるかもしれません.そしてJSBridgeのサービスもあります.もし設計する時に注意しなかったら、開発過程でこのモジュールは大量の他の業務コードに詰め込まれて、多くの業務モジュールに依存しています.JSBridgeサービスは常に登録されているので、業務と結合する必要があります.
この時はどうすればいいですか?まずWebViewモジュールの位置付けを考えて、より大局的な観点から考えます.各appのアーキテクチャはこのようなモジュールが必要です.このモジュールを単独で持ち上げて、基礎モジュールに沈下することができます.この時のデカップリングはWebViewモジュールにいくつかの設計をして、登録型アプリを追加してください.JSBridgeのサービスを変更して登録することによってロジックを追加して、業務との結合を実現します.業務は完全に自分の業務に関連するコードを自分のモジュールに入れて、あなたが設計したAppを通じてWebViewモジュールに登録できます.
4.2インターフェース向けに呼び出す
公共モジュールは、アーキテクチャ設計によって結合業務を回避することができるとはいえ、業務モジュール間には結合がありますよ.そして、このような状況が一番多いです.例えば、ページジャンプやデータ転送など、前の方法はもう足りないです.じゃ、どうやって違う業務モジュール間のコードを結合しますか?
それはインターフェースに向かって呼び出します.コードを直接引用すれば、依存があると知っています.
1
2
3
4
5
6
7
8
9

// A    - (void)getSomeDataFromB {  B.getSomeData(); }  // B    - (void)getSomeData {  return self.data; }
私たちは一つの実現ができます.  Common Aはこのインターフェースだけに依存し、Bはこのインターフェースを実現し、AとBの結合が実現される.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//    @protocol BService <NSObject> - (void)getSomeData; @end  // A   ,       - (void)getSomeDataFromB {  id b = findService(@protocol(BService));  b.getSomeData; }  // B   ，  BService   @interface B : NSObject <BService>  - (void)getSomeData {  return self.data; }  @end
これによりモジュール間の呼び出しが満足され、結合も実現されます.
利点:
1、      ，               。
短所:
1、                  ，            ，    。
2、      ，           service，   ,                   ，
4.3プロトコルに向けて呼び出す
インターフェースに向けての呼び出しの欠点は、すべての需要を満たすことができないし、完全には結合されていないので、最終的な手段は、プロトコルを定義することによってモジュール間の通信を実現し、既存のプロトコルは、getSomeDataFromBジャンププロトコルです.これは単にモジュールの結合に役立つだけではなく、統一化された運営にとっても素晴らしい助けになります.例えば、appの中のどのページも、あるいはどの操作も一つのURLを通して呼び覚まされるならば、それぞれの複雑な業務の間を結合してしまうのではないでしょうか?
5.ソースのおすすめ
こんなに多くの話をしましたが、干物も入れますよね.次は2つの倉庫の紹介をします.モジュール化のプロセスに役に立ちたいです.
1、 JL Routes URLジャンププロトコルのサポートライブラリです.私が欲しいのにぴったりです.強くオススメします.
2、自分で書いたデカップフレーム AppLord.いくつかの概念を簡単に紹介します.
* Module             ，      AppDelegate                 module   
* Service       4.2               
* Task,           ，
ionic新規プロジェクト