iOSDC 2019「SOLID原則を生活に適用する」全文以上書き起こし

9/5〜9/7に行われたカンファレンス「iOSDC」にて登壇しました。「SOLID原則を生活に適用する」という5分のLTでした。

SpeakerDeckの発表資料です

トークのモチベーション

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を重ね、最終的には自己紹介を削ることでなんとかしました。詰め詰めだぞ。

トーク全文(以上)書き起こし

では始めます。

タイトル「SOLID原則を生活に適用する」
タイトル「SOLID原則を生活に適用する」

みなさん。
SOLID原則に、なじみはありますか?

Image for post
Image for post

SOLID原則はオブジェクト指向における5つの設計原則の総称…なんですが、さて、設計原則の話の前に、もう一歩手前の話。

Image for post
Image for post

そもそも設計って、なんなんでしょうね?
設計というのは、「ある問題に対して解決となるような構造を与える」ことです。
我々は「設計するもの = ソフトウェア」という前提を持ちがちです。エンジニアですからね。
でも考えてみてください。

問題って、ソフトウェアで解決するとは限らないよね?
問題って、ソフトウェアで解決するとは限らないよね?
Image for post
Image for post

人生設計、という言葉があります。
人生は不確実な問題の積み重ねです。その問題には、解決の構造を作って戦う必要があります。
となるとですよ、

人生・生活にもSOLID原則が適用できるのでは?
人生・生活にもSOLID原則が適用できるのでは?

…と考えてみたわけです。
はい、ではさっさと本題に入ります。

Image for post
Image for post

SOLID原則は5つの原則の総称だといいました。
5原則、5分で全部見ますよ。ついてきてください。はいひとつめ、

Image for post
Image for post

SOLIDのS。単一責任原則です。

Image for post
Image for post

これは何かって言うと、雑に言うと
変更理由が同じならまとめる、そうじゃなきゃ分ける
ということです。これを生活に適用してみると、どうなるでしょうか。

Image for post
Image for post

仕様変更があるとき、その変更するコードが一箇所にまとまってると安心ですよね。
同様に「家のもの」を「外出用に持ち出す」という点で同じものが玄関にまとまってたら、安心です。

Image for post
Image for post

もうひとつの観点。
うち、ハサミが何本かあるんですよ。ハサミという物は同じなんですが、使いたいコンテキストが別なんです。
だとすると、それは分けていい。単一責任原則がそう言ってくれてるんです。

Image for post
Image for post

次いきます。
SOLIDのO。開放/閉鎖原則というものがあります。

Image for post
Image for post

雑に言えば、強い構造を示した原則です。
ベースの流れを変えずに細かな挙動は後付けで調整可能な型は、強い。

Image for post
Image for post

人間は皆、型みたいなものを持っています。
流れに載せればどんな状況でもだいたい対応できるような構造。
スクラムとかPDCAとか、もっとカジュアルな場では、とりあえず天気の話とか、なんでも野球に喩えるとか。
使う状況は後付けでOK。こなれたフレームワークに、状況に応じた差分だけ載っけると、うまく人生を切り抜けられます。

Image for post
Image for post

フレームワークをあらかじめ持ってると強い。そう教えてくれるのが開放閉鎖原則です。
で、この開放閉鎖原則、「オブジェクト指向設計の核心」と言われているんですよね。
そうすると人生設計原則としても、これは核心と言えるかも?
って思っちゃいますね。

Image for post
Image for post

次、SOLIDのLです。リスコフの置換原則。

Image for post
Image for post

親クラスとサブクラスの継承関係についての原則で、
雑に言えば、子は、親にできること全部できなきゃいけないってことです。全部できれば、子を親の代わりとして使える
これを生活において適用するってどういう状況でしょう?

Image for post
Image for post

教育ママとかブラック上司を想像してください。
自分ができることは全部、子供や部下に完璧にやらせようとする。
リスコフですね。これはリスコフってます。
…でも、

Image for post
Image for post

現実の子は、親のサブクラスじゃないんですよね。
ところで、ここで開放閉鎖原則とリスコフの置換原則の関係を考えると、ある気づきが得られます。

Image for post
Image for post

そもそもリスコフの置換原則がなんで大事かっていうと、親クラスがサブクラスで置きかえ可能じゃないと、使う側のコードに、サブクラスを具体的に意識した分岐を書くことになる。
そうすると、その型の利用者は開放/閉鎖原則を守れないんです。閉鎖ってつまり、何が来ても同じフレームワークでまかなえるってことなので。特別処理があっちゃいけない。

Image for post
Image for post

つまり、こういう洞察が可能です。
自分のサブクラスを作りたがる親や上司は「自分のフレームワークを子供や部下に適用できない」のが不安なのでは?
どうでしょう。人間の心理がわかっちゃうなんて、SOLID原則すごいですねー。ホントですかね。

Image for post
Image for post

4つめの原則は、SOLIDのI、インタフェース分離の原則です。

Image for post
Image for post

雑に言えば、関わりのないメソッドだけ気にするようにして、影響範囲を最小限に留めようってことです。
生活に適用してみましょう。

Image for post
Image for post

世の中に物申したくなること、あります。でも、それが自分に関係あるとは限りません。「自分に関係ある?」と一歩引いて考えてみると、

Image for post
Image for post

誰かの言動に振り回されたり、誰かを自分のサブクラスにしたくならずに済んで、疎結合な人生が手に入るんじゃないでしょうか。

Image for post
Image for post

最後の原則は、SOLIDのD、依存関係逆転の原則です。

Image for post
Image for post

雑に言えば、抽象に依存しろという話。

Image for post
Image for post

生活の中で、依存しているものってどれくらいありますか?
あれじゃなきゃ、これじゃなきゃと思ってるそれ、実は、抽象化できたりしないでしょうか。

Image for post
Image for post

具体的な一本のハサミではなく、切る機能に注目して複数本部屋に置くとか、
旅先の荷物は旅先で買えばいいとか、あるいは会社に尽くさなくても転職していいんだよ、とか。
抽象で捉えると、依存先に振り回されがちな人生の舵取りを自分自身に取り戻せるのです。

Image for post
Image for post

以上、駆け足になりましたが5つの原則を見てきました。
ただ、

Image for post
Image for post

ここでひとつ、注意してほしいことがあります。

Image for post
Image for post

問題を解決する道具を手に入れたとき、人間ってどんな問題に対してもその道具を使いたがっちゃうんですよね。これをハンマー釘病といいます。

Image for post
Image for post

最初に言いました。設計というのは、「ある問題に対して解決となるような構造を与える」ことです。逆に言えば、それ以外の問題に対して適用できると考えてはいけません。

Image for post
Image for post

人生設計に対する、いわばメタ設計パターンとしてのSOLID原則も同じです。すべての人生の問題解決に適用しちゃいけません。

Image for post
Image for post
Image for post
Image for post

思い出してみましょう。
開放閉鎖原則には「強いフレームワークを作るのが設計の核心」という学びがありました。

Image for post
Image for post

ある特定のプログラムで使った設計パターンが他のプログラムでも利用できるように、「SOLID原則を一般化する」ことは、プログラミング以外の生活局面でも役立つのではないでしょうか。

Image for post
Image for post

私たちソフトウェアエンジニアは、問題解決のスペシャリストです。その能力を鍛えつつ、ついでに日常生活もいい感じにしていきましょう!

Image for post
Image for post

そんな便利なSOLID原則は実はプログラミングにも適用できまして、SwiftのコードにSOLID原則を適用する章も用意した設計本も昨年末発売されました。iOSアプリ設計パターン入門といいます。書きました。よかったらおひとつどうぞ!(宣伝)

以上、takasekがお送りしました。

あとがき

Image for post
Image for post
「設計のための、問題の捉え方」の書き起こしより

そのとき懇親会でmagnoliaさんや他の方々と話して得られたのが、「 問題」と「設計」の関係は多重構造になっており、「どう問題を捉えるのか」にも設計原則とパターンが適用できるはずという気づきでした。
そこらへんのアイデアを、たのしく伝えられたらなと思った結果できたのが、この発表でした。

真面目に見ても、ネタとして見ても成立するような発表にしようと意識しました。試みは割と成功したと思います。
冗談めかした発表ですが、一応理屈は通ってる…と思ってるんですよね。あとS・O・L・I・Dの5つの原則の説明も、それ自体は間違っていないはずです。(もし変なところがあれば私の理解が間違っているということなので、遠慮なくマサカリください)

それにしてもそこらへんの勉強会で知り合った設計好きの人たち、毎日わいわい設計原則を生活に適用してるんだよなぁ…アホなの?
普段の仕事道具を、範囲を遊び道具にも使うと親しみが生まれるし知識が深まり使いこなせるようになるし、なにより純粋に楽しいので、おすすめですよ。

(追記)Togetterでまとめられました。設計理論の無駄遣いを見よ。
君も設計原則を生活に適用してすえなみさんの金で焼肉を食べよう!

Written by

「iOSアプリ設計パターン入門」 を書いた。 https://twitter.com/takasek

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store