9/5〜9/7に行われたカンファレンス「iOSDC」にて登壇しました。「SOLID原則を生活に適用する」という5分のLTでした。
トークのモチベーション
応募したプロポーザルは、以下のようなものでした。
SOLID原則は、オブジェクト指向プログラミングにおける基本的な5つの原則です。
S — 単一責任の原則 (Single Responsibility Principle)
O — 開放/閉鎖原則 (Open/Closed Principle)
L — リスコフの置換原則 (Liskov Substitution Principle)
I — インタフェース分離の原則 (Interface Segregation Principle)
D — 依存関係逆転の原則 (Dependency Inversion Principle)コーディングにおいて、言語化できない不吉なにおい（Code Smell）を感じたときには、これらの原則に照らし合わせることで設計の間違いを言語化し、修正の手がかりを掴むことができます。
SOLID原則はもちろん、ソフトウェア設計のための原則です。
しかしオブジェクト指向は「複雑な問題領域を分割統治する」コンセプトであり一般性を見いだせます。原則が転用できるのは、コードの中のみではないはず。
このLTでは、コーディングにまつわらない日常生活のものごとをいくつか例に挙げ、SOLID原則の視点で解釈してみます。
5つの原則を全部説明していたら5分じゃとても足りないけど、5つの原則を全部説明しなきゃ成立しない内容だったので頭を抱えましたが、喋る内容を全部書き起こして単語を削っては読み上げRTAを重ね、最終的には自己紹介を削ることでなんとかしました。詰め詰めだぞ。
トーク全文（以上）書き起こし
喋りがないとあんまり雰囲気が伝わらない発表だったのと、せっかく手元に発表全文があるので、ここに書き起こしを残しておきます。
5分に収まりきらず切った分もしれっと混ぜてるので、だいたい7分くらいの分量ですかね。
では始めます。
みなさん。
SOLID原則に、なじみはありますか？
SOLID原則はオブジェクト指向における5つの設計原則の総称…なんですが、さて、設計原則の話の前に、もう一歩手前の話。
そもそも設計って、なんなんでしょうね？
設計というのは、「ある問題に対して解決となるような構造を与える」ことです。
我々は「設計するもの ＝ ソフトウェア」という前提を持ちがちです。エンジニアですからね。
でも考えてみてください。
人生設計、という言葉があります。
人生は不確実な問題の積み重ねです。その問題には、解決の構造を作って戦う必要があります。
となるとですよ、
…と考えてみたわけです。
はい、ではさっさと本題に入ります。
SOLID原則は5つの原則の総称だといいました。
5原則、5分で全部見ますよ。ついてきてください。はいひとつめ、
SOLIDのS。単一責任原則です。
これは何かって言うと、雑に言うと
変更理由が同じならまとめる、そうじゃなきゃ分ける
ということです。これを生活に適用してみると、どうなるでしょうか。
仕様変更があるとき、その変更するコードが一箇所にまとまってると安心ですよね。
同様に「家のもの」を「外出用に持ち出す」という点で同じものが玄関にまとまってたら、安心です。
もうひとつの観点。
うち、ハサミが何本かあるんですよ。ハサミという物は同じなんですが、使いたいコンテキストが別なんです。
だとすると、それは分けていい。単一責任原則がそう言ってくれてるんです。
次いきます。
SOLIDのO。開放/閉鎖原則というものがあります。
雑に言えば、強い構造を示した原則です。
ベースの流れを変えずに細かな挙動は後付けで調整可能な型は、強い。
人間は皆、型みたいなものを持っています。
流れに載せればどんな状況でもだいたい対応できるような構造。
スクラムとかPDCAとか、もっとカジュアルな場では、とりあえず天気の話とか、なんでも野球に喩えるとか。
使う状況は後付けでOK。こなれたフレームワークに、状況に応じた差分だけ載っけると、うまく人生を切り抜けられます。
フレームワークをあらかじめ持ってると強い。そう教えてくれるのが開放閉鎖原則です。
で、この開放閉鎖原則、「オブジェクト指向設計の核心」と言われているんですよね。
そうすると人生設計原則としても、これは核心と言えるかも？
って思っちゃいますね。
次、SOLIDのLです。リスコフの置換原則。
親クラスとサブクラスの継承関係についての原則で、
雑に言えば、子は、親にできること全部できなきゃいけないってことです。全部できれば、子を親の代わりとして使える。
これを生活において適用するってどういう状況でしょう？
教育ママとかブラック上司を想像してください。
自分ができることは全部、子供や部下に完璧にやらせようとする。
リスコフですね。これはリスコフってます。
…でも、
現実の子は、親のサブクラスじゃないんですよね。
ところで、ここで開放閉鎖原則とリスコフの置換原則の関係を考えると、ある気づきが得られます。
そもそもリスコフの置換原則がなんで大事かっていうと、親クラスがサブクラスで置きかえ可能じゃないと、使う側のコードに、サブクラスを具体的に意識した分岐を書くことになる。
そうすると、その型の利用者は開放/閉鎖原則を守れないんです。閉鎖ってつまり、何が来ても同じフレームワークでまかなえるってことなので。特別処理があっちゃいけない。
つまり、こういう洞察が可能です。
自分のサブクラスを作りたがる親や上司は「自分のフレームワークを子供や部下に適用できない」のが不安なのでは？
どうでしょう。人間の心理がわかっちゃうなんて、SOLID原則すごいですねー。ホントですかね。
4つめの原則は、SOLIDのI、インタフェース分離の原則です。
雑に言えば、関わりのないメソッドだけ気にするようにして、影響範囲を最小限に留めようってことです。
生活に適用してみましょう。
世の中に物申したくなること、あります。でも、それが自分に関係あるとは限りません。「自分に関係ある？」と一歩引いて考えてみると、
誰かの言動に振り回されたり、誰かを自分のサブクラスにしたくならずに済んで、疎結合な人生が手に入るんじゃないでしょうか。
最後の原則は、SOLIDのD、依存関係逆転の原則です。
雑に言えば、抽象に依存しろという話。
生活の中で、依存しているものってどれくらいありますか？
あれじゃなきゃ、これじゃなきゃと思ってるそれ、実は、抽象化できたりしないでしょうか。
具体的な一本のハサミではなく、切る機能に注目して複数本部屋に置くとか、
旅先の荷物は旅先で買えばいいとか、あるいは会社に尽くさなくても転職していいんだよ、とか。
抽象で捉えると、依存先に振り回されがちな人生の舵取りを自分自身に取り戻せるのです。
以上、駆け足になりましたが5つの原則を見てきました。
ただ、
ここでひとつ、注意してほしいことがあります。
問題を解決する道具を手に入れたとき、人間ってどんな問題に対してもその道具を使いたがっちゃうんですよね。これをハンマー釘病といいます。
最初に言いました。設計というのは、「ある問題に対して解決となるような構造を与える」ことです。逆に言えば、それ以外の問題に対して適用できると考えてはいけません。
人生設計に対する、いわばメタ設計パターンとしてのSOLID原則も同じです。すべての人生の問題解決に適用しちゃいけません。
思い出してみましょう。
開放閉鎖原則には「強いフレームワークを作るのが設計の核心」という学びがありました。
ある特定のプログラムで使った設計パターンが他のプログラムでも利用できるように、「SOLID原則を一般化する」ことは、プログラミング以外の生活局面でも役立つのではないでしょうか。
私たちソフトウェアエンジニアは、問題解決のスペシャリストです。その能力を鍛えつつ、ついでに日常生活もいい感じにしていきましょう！
そんな便利なSOLID原則は実はプログラミングにも適用できまして、SwiftのコードにSOLID原則を適用する章も用意した設計本も昨年末発売されました。iOSアプリ設計パターン入門といいます。書きました。よかったらおひとつどうぞ！（宣伝）
以上、takasekがお送りしました。
あとがき
なんでこういう発想に至ったかというと、 去年設計大好きな人たちが集まって設計Night2018という勉強会をやってたんですが、そこでの@magnolia_k_さんの発表「設計のための、問題の捉え方」（全文書き起こし）に感銘を受けたのです。
そのとき懇親会でmagnoliaさんや他の方々と話して得られたのが、「 問題」と「設計」の関係は多重構造になっており、「どう問題を捉えるのか」にも設計原則とパターンが適用できるはずという気づきでした。
そこらへんのアイデアを、たのしく伝えられたらなと思った結果できたのが、この発表でした。
真面目に見ても、ネタとして見ても成立するような発表にしようと意識しました。試みは割と成功したと思います。
冗談めかした発表ですが、一応理屈は通ってる…と思ってるんですよね。あとS・O・L・I・Dの5つの原則の説明も、それ自体は間違っていないはずです。（もし変なところがあれば私の理解が間違っているということなので、遠慮なくマサカリください）
それにしてもそこらへんの勉強会で知り合った設計好きの人たち、毎日わいわい設計原則を生活に適用してるんだよなぁ…アホなの？
普段の仕事道具を、範囲を遊び道具にも使うと親しみが生まれるし知識が深まり使いこなせるようになるし、なにより純粋に楽しいので、おすすめですよ。
（追記）Togetterでまとめられました。設計理論の無駄遣いを見よ。
君も設計原則を生活に適用してすえなみさんの金で焼肉を食べよう！
