これは Swift Tweets の発表をまとめたものです。イベントのスポンサーとして Qiita に許可をいただいた上で、このような形（ツイートの引用）で投稿しています。
ライブラリは便利です。作り込まれた機能を簡単に利用できる。しかしそれは裏を返せば、ライブラリに縛られることを意味します。無意識の内に、自前の処理がライブラリに依存してしまう。何かの事情でライブラリを外そうと思っても、もはや手遅れ…それが、ロックインです。 #swtws
— @takasek
ライブラリのロックインが何故起こるのか。以下の3パターンに分類してみました。これらのパターンについて、傾向と対策を練ってみましょう。
①依存が深くてライブラリが外せない
— @takasek
②使ってる箇所が多すぎて実質外せない
③ライブラリのパラダイムが違いすぎて外せない
#swtws
①依存が深いパターン。すべてのインタフェースをRxSwiftで繋げてしまうとか、全EntityがRealm.Objectであることを前提にしてるとか。便利なライブラリはどこでも使いたくなりますが、我慢してリスクヘッジを考えましょう。 #swtws
— @takasek
依存リスク低減の基本は、ライブラリの実体を外側から隠蔽することです。影響範囲を内側に留めるのです。AdapterパターンやBridgeパターンを活用する・抽象に依存させる（利用者はprotocol、インタフェースだけを意識する）という手段が考えられます。 #swtws
— @takasek
インタフェースがミニマルで合理的になっていれば、それはライブラリを超えて利用できます。たとえばAPIKitのRequestプロトコル( https://github.com/ishkawa/APIKit/blob/master/Sources/APIKit/Request.swift )は、他の通信ライブラリに乗り換えてもほぼそのまま通用します（しました）。 #swtws
— @takasek
また、ライブラリはなるべく小さく使いたいものです。Rxであれば、用途をObservalbeとPromiseパターンの実現だけに留めるとか。…RxでUITableViewを独自拡張しててbindすると便利💕というような話を聞くと、それは悪魔の囁きでは…と感じます😈 #swtws
— @takasek
②使ってる箇所が多すぎて実質外せない…というのは、たとえばR.swift。文字列や画像など各種リソースをリテラルではなく、構造体のメンバとしてアクセスできるようにしてくれるライブラリです。以前自分も激推ししたんですが… http://qiita.com/takasek/items/cbef56613d3b406c9a4d #swtws
— @takasek
結局、諸般の事情（ビルド時間やファイルサイズ）で脱却する方針になると、辛い作業が待ってました。一箇所一箇所は単純でも、ひたすら慎重かつ大量に書き直すしかない。どうしようもない。…導入時によくメリデメを考えましょう、としか言えないパターンです。 #swtws
— @takasek
③パラダイムが違うパターン。パラダイムというのは、たとえばtarget/actionパターンとクロージャとかですね。例としてActionClosurable( https://github.com/takasek/ActionClosurable )というのがあるのですが…え、聞いたことない？便利ですよ😃 #swtws
— @takasek
ActionClosurableは、NSObjectを拡張して、こんなクロージャでの記述を可能にします。でも取り外して古き良きtarget/actionに直そうとすると…大変です。パラダイムが違うって、そういうこと。 #swtws
https://gist.github.com/86e2cb584a350c68943f11ce43e01ce7
— @takasek
Promise(SwiftTask)やアプリカティブ(swiftz)、FRPライブラリなども同様の問題を孕んでいます。同じパラダイムのライブラリなら、むしろ類似したインタフェースを持つので移行は難しくない。しかし、思想が違えば、コードの修正は「再設計」と等しい。 #swtws
— @takasek
パラダイム問題への対処は、ライブラリがどうというよりも、むしろ「プロダクトにそのパラダイムを導入する必要があるか」という観点が大事になってきます。開発メンバーのレベル・学習コストやプロダクトの規模など、外部要因を含めて総合的に判断すべきトピックではないでしょうか。 #swtws
— @takasek
以上、3パターンのロックインの傾向と対策についてでした！ ごTweet聴ありがとうございました #swtws
— @takasek