恐怖！忍び寄るライブラリへのロックイン

これは [Swift Tweets](https://swift-tweets.github.io/) の発表をまとめたものです。イベントのスポンサーとして Qiita に許可をいただいた上で、このような形（ツイートの引用）で投稿しています。

---

<blockquote class="twitter-tweet"><p dir="ltr">ライブラリは便利です。作り込まれた機能を簡単に利用できる。しかしそれは裏を返せば、ライブラリに縛られることを意味します。無意識の内に、自前の処理がライブラリに依存してしまう。何かの事情でライブラリを外そうと思っても、もはや手遅れ…それが、ロックインです。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820293907313369088"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">ライブラリのロックインが何故起こるのか。以下の3パターンに分類してみました。これらのパターンについて、傾向と対策を練ってみましょう。

①依存が深くてライブラリが外せない
②使ってる箇所が多すぎて実質外せない
③ライブラリのパラダイムが違いすぎて外せない
#swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294022115643392"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">①依存が深いパターン。すべてのインタフェースをRxSwiftで繋げてしまうとか、全EntityがRealm.Objectであることを前提にしてるとか。便利なライブラリはどこでも使いたくなりますが、我慢してリスクヘッジを考えましょう。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294137383514118"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">依存リスク低減の基本は、ライブラリの実体を外側から隠蔽することです。影響範囲を内側に留めるのです。AdapterパターンやBridgeパターンを活用する・抽象に依存させる（利用者はprotocol、インタフェースだけを意識する）という手段が考えられます。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294247924367361"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">インタフェースがミニマルで合理的になっていれば、それはライブラリを超えて利用できます。たとえばAPIKitのRequestプロトコル( https://github.com/ishkawa/APIKit/blob/master/Sources/APIKit/Request.swift )は、他の通信ライブラリに乗り換えてもほぼそのまま通用します（しました）。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294361103507456"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">また、ライブラリはなるべく小さく使いたいものです。Rxであれば、用途をObservalbeとPromiseパターンの実現だけに留めるとか。…RxでUITableViewを独自拡張しててbindすると便利💕というような話を聞くと、それは悪魔の囁きでは…と感じます😈 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294476425928704"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">②使ってる箇所が多すぎて実質外せない…というのは、たとえばR.swift。文字列や画像など各種リソースをリテラルではなく、構造体のメンバとしてアクセスできるようにしてくれるライブラリです。以前自分も激推ししたんですが… http://qiita.com/takasek/items/cbef56613d3b406c9a4d #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294592478089216"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">結局、諸般の事情（ビルド時間やファイルサイズ）で脱却する方針になると、辛い作業が待ってました。一箇所一箇所は単純でも、ひたすら慎重かつ大量に書き直すしかない。どうしようもない。…導入時によくメリデメを考えましょう、としか言えないパターンです。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294707422969858"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">③パラダイムが違うパターン。パラダイムというのは、たとえばtarget/actionパターンとクロージャとかですね。例としてActionClosurable( https://github.com/takasek/ActionClosurable )というのがあるのですが…え、聞いたことない？便利ですよ😃 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294822686621698"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">ActionClosurableは、NSObjectを拡張して、こんなクロージャでの記述を可能にします。でも取り外して古き良きtarget/actionに直そうとすると…大変です。パラダイムが違うって、そういうこと。 #swtws

https://gist.github.com/86e2cb584a350c68943f11ce43e01ce7</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820294927556874240"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">Promise(SwiftTask)やアプリカティブ(swiftz)、FRPライブラリなども同様の問題を孕んでいます。同じパラダイムのライブラリなら、むしろ類似したインタフェースを持つので移行は難しくない。しかし、思想が違えば、コードの修正は「再設計」と等しい。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820295032280256512"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">パラダイム問題への対処は、ライブラリがどうというよりも、むしろ「プロダクトにそのパラダイムを導入する必要があるか」という観点が大事になってきます。開発メンバーのレベル・学習コストやプロダクトの規模など、外部要因を含めて総合的に判断すべきトピックではないでしょうか。 #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820295137204912128"></a></blockquote>

<blockquote class="twitter-tweet"><p dir="ltr">以上、3パターンのロックインの傾向と対策についてでした！　ごTweet聴ありがとうございました #swtws</p>&mdash; @takasek <a href="https://twitter.com/takasek/status/820295578135318528"></a></blockquote>