00:00
Yoshiori Shoji
このポッドキャストは、俺とドラフト コードがタメ口で適当に技術について
好きなように話し合うという雑な チャンネルです。僕がyoshioriです。
よろしくお願いします。
draftcode
ドラフト コードです。よろしくお願いします。
Yoshiori Shoji
というわけで、今回はDIについて 話そうという回です。
最初にまずは、クレイジーボブについて、 ドラフトコードのほうから。
draftcode
クレイジーボブというハンドル名で、 DI界隈を賑やかしていた。
賑やかしていたって言うとちょっと あるんですけど、有名なのかな?
Yoshiori Shoji
有名って。
だって、使用策定とかにも入ってたよね、 DI系の。
draftcode
そうだね。
デペンデンスインジェクションナイブラリ といった場合に、
Springが一番有名で、 DuggerとかJuiceとかと思うんですが、
ボブリーはJuiceの作者であり、 Dugger1の作者であり、
Dugger2もGoogleが作ってるんで、 ボブリーはもともとGoogleにいたんで、
そういうDIフレームワークを作り まくった人なんですが、
なんと亡くなりになったという 感じになってます。
Yoshiori Shoji
痛ましい事件が。
draftcode
はい、痛ましい事件があったので、 ツイートをポッドキャストですね。
Yoshiori Shoji
ツイートをポッドキャストということで、 DIPENDENCE INJECTIONについて語ろうと。
draftcode
そうですね。
この殺人事件っていうのも、 友人なのかな?知り合いなのか分からないけど、
見栄えの中っていう感じの写真で、 びっくりっていう感じですね。
Yoshiori Shoji
なんかちょっとWikipedia見たら、 事件当初より結構詳細が載ってて、
刺した人の妹と付き合ってた。
draftcode
へー。
Yoshiori Shoji
そうそうそう。
で、クレイジーボブやっぱちょっと クレイジーじゃん。
draftcode
で、妹と一緒にマリファナかなんかを やりまくってるのを、
Yoshiori Shoji
なんか、やめてくれみたいなのに 注意しに行って口論になったみたいな。
draftcode
おー。
Yoshiori Shoji
っていうのをWikipediaから見ただけだから、 本当に正しいかどうかは分からない。
draftcode
まあ、なんか差もありだみたいな感じが なくもない。
一応マリファナ合法といえば合法。
Yoshiori Shoji
そう、合法は合法なんだけど、
お兄ちゃんとして止めたいって 気持ちも分かるしなみたいな。
draftcode
まあ分かる、分かる。
まあまあ、そうですね。
Yoshiori Shoji
どちらにしてもやっぱね、暴力で解決っていうのは やっぱすごい痛ましい事件なので。
draftcode
そうですね。
いや、まあということなので、DI。
DIか。
DIおっさん向けのトピックだからね。
Yoshiori Shoji
そうそうそう。
draftcode
おー。
DI、初めてのDIって何だった?
初めて…
Yoshiori Shoji
えっとね、歴史の話をちょっとしようと思っていて、
03:01
Yoshiori Shoji
まず前回のオブジェクト思考から続くんだけども、
DIって実はDependency Ejectionって言われたのは スプリングが生まれた後の話なのね。
なので、順を追って説明すると、
2002年の日本語で言うと実践J2EEシステムデザイン っていうエキスパートワンオンワンJ2EEデザイン&デベロップメント っていう本をロド・ジョンソンっていうのが書いたんだけど、
これは何かって言うと、J2EEで開発をするときの 本当のTipsみたいなやつ。
昔はJ2EEのAPIとかしか公開されてないし、 3からしか本が出てなかったので、
EJB万世みたいな本ばっかりだったんだけども、
これはロド・ジョンソンがJ2EEで開発するんだったら、
ちゃんとこうやった方がいいよっていうので、
EJBをボックスに批判しながらこういう風に書いた方がいいよっていう本の中で、
スプリングっぽいものの宣伝とかもしていて、
書きながらスプリングのベータバージョンがリリースされてたんだよね。
この頃はまだDIっていう言葉はなくて、
IOC、Inversion of Controlっていう話があって、
それで2003年にスプリングがリリースされた。
この時は俺は本当にちょうどスプリングベータからベータが外れる時にマジで使ってて、
当時所属してた会社のCTOがすごいこのロド・ジョンソンの本大好きで、
スプリングベータから導入しててさ、
これなんすかって俺言ったら、うん、これいいやつだよって言われて、
ドキュメントとかないんですかって言われたら、
そのロド・ジョンソンのまだ日本語翻訳されてない本をゴンって忘れて、
これって言われたっていうのがオフトピエピソードとしてあるんだけど、
そんな感じで2003年にスプリングがリリースされて、
まだこの頃はIOCコンテナーとか言われてた。
2004年の1月にまた、またですよ、
またですね、
これをつけた、
Dependencyのインジェクションということで、
Inversion of Controlとかその辺の話も含めて、
DIっていう風に呼んだら分かりやすいんじゃないかみたいな話をして、
そこら辺からDIコンテナーって呼ばれるようになってきた。
それが2004年の1月で、
2004年の3月ぐらいには、
軽快なJava、
Better, Faster, Lighter Javaみたいな本がオライリーから出て、
そこで結構そのロド・ジョンソンが指定して、
ボロクソンに言ってたEJBから、
軽快な風に開発しようよって言って、
Hibernateとスプリングを中心にした開発の仕方っていうのの本が出て、
これ結構爆発的に流行った、
俺の中では気がする。
っていうのが2004年。
今Hibernateとスプリングって聞くと、
重厚だなって思うかもしれないけど、
この当時、EJBと比べたらむちゃくちゃ軽快だったのね。
06:02
draftcode
エンタープライズってやつよね。
Yoshiori Shoji
そう、エンタープライズってやつに比べたらめちゃめちゃ、
軽快だったっていう時代があります。
この頃2004年とかだから、
Googleジュースとかが2007年とかなのね。
さっきのクレイジーボブが作ってリリースするとかが。
だいぶ前の話で、
アノテーションすらなかったのよ、Javaに。
そもそもJavaにアノテーションという機構がなくて、
なのでXMLで記述したりとかして、
最末端でどうしてもそのオブジェクトを使うところでは、
ビーンを取得しなきゃいけないところでは、
もうアプリケーションコンテキスト.getbeanとかっていうメソッドを使って、
取ってくるみたいなことをやってて、
getbeanメソッドみたいなのがベータから正式リリースで、
メソッド名が実は変わって、
泣きながら全部修正した記憶がある。
というのがDIの流れ。
よく言われてるのが、
ソリッド原則オブジェクト志向。
これ前回の続きになるんだけど、
ソリッド原則のD、
Dependency Inversion Principleの、
これの読み方はよく分かってないですけど、
draftcode
プリンシパルって校長先生の原則って、
どっちがどっちだっけっていつもなるやつだよね。
Yoshiori Shoji
ソリッドのDとも結構依存してるよねって言われるんだけども、
調べたらソリッド自体が出てきたのが2004年とかなので、
ソリッドっていう5個にまとめて発表されたのが2004年とかなんで、
スプリングの後なんだよね。
DIってファウラーが名を付けた後だと思うので、
そこまで直接関係はしてないけど、
逆に意識してるんじゃないかなっていう気がする。
逆に言うとソリッドのDとすごい似ている話なので、
つまりオブジェクト志向を理解してる人は
DI難しいわけないんだよねっていう。
もう何でも簡単な概念ですっていう、
前回と同じような話になるんだけども。
知ってる概念だよねっていう話になります。
っていうのが起源前というか、
スプリング誕生前から誕生のお話。
draftcode
そうですね。
なのでこのソリッドを理解してればとか、
オブジェクト志向とは結局なんだったのかみたいなのを、
ある程度感覚として分かってみると、
別にDIってそんな複雑じゃない感じが、
僕はしてしまうんだけれども、
複雑と言われる。
複雑になる部分も分かってるんだけれども、
複雑になりがちですね。
Yoshiori Shoji
そこはちょっと分けて考えなきゃいけないと思うのは、
DIっていうパターン。
IoCを実現するための一個のパターンなわけだよね、
09:01
Yoshiori Shoji
DIっていうの。
そうね。
draftcode
パターンの話とDIコンテナっていうフレームワークの話、
Yoshiori Shoji
はちょっと分けて考えなきゃいけないなと思ってて、
パターンはすごい単純な話をしてるだけなのよ。
draftcode
そうだね。
なんか、
アプリケーションレベルでなんかDIみたいなのを話そうと思うと、
別に結構単純な使い方になるんだけれども、
なんかその上でDIコンテナをうまく利用して、
なんかやでコンフィグだなんだろう、
サーバーの設計だとかをうまくしたいみたいな感じの欲求が出てしまって、
そこがちょっと意味分からん複雑なところになりがちなんだね。
そうそう。
Yoshiori Shoji
だからなんか設定とか使い方とかがめちゃくちゃ複雑とか、
いろんなことを考慮しなきゃいけないってなるけれども、
DI自体はすごい簡単。
すごいよく出てくるサンプルで言うと、
なんかDIのデータベースへのコネクションが必要なプログラムを書いてるときに、
そのデータベースへ値を挿入するっていうサービスクラスみたいなのを作ってたときに、
そのクラスがDBのコネクションを使うために、
そのクラス内で自分でユーザーIDとパスワードはENVから持ってきて、
コネクションはXMファイルから持ってきてみたいなのでコネクションを作るっていう、
その生成自体を自分の中でやるんじゃなくて、
DBコネクションみたいなオブジェクトを外部から注入してもらって、
そこに対してライトみたいなのをするっていう風にするっていうだけの話。
内部でニューしないみたいな。
クラス内でニューしないだけとか。
めちゃめちゃ本当はDIってすごいシンプルな概念なんだよね。
draftcode
そうだね。
まあそうだよね。
適当に呼んでさ、適当に呼んだ人と呼んだらさ、
急になんかどっか環境変数からユーザーの名前、パスワードとか取ってきて、
アクセスされるのをちょっとねっていう感じはするもんね。
そう。
Yoshiori Shoji
なんかその生成方法を知らないと使えないっていう。
使う側って使い方を知ってればいいんだって、
生成方法は知らなくていいよね。
っていうのがやっぱりあって、
そこでJavaとかの言語使用になってくるとインターフェースを使って、
作り方は知らないけど使用方法だけ知ってるっていうのを表すとどうなるかっていうと、
インターフェースになるよねみたいな形になっていたりとか。
っていう風になる。
あとはIoCの考え方、制御の逆転みたいな話。
っていうのもちょっとあって、
制御の逆転がちょっと難しいんだよね。
難しいっていうのは、
簡単すぎて難しいというか当たり前になっちゃってるんだよね今。
draftcode
なんか構造化プログラミングみたいなもんだよね。
我々も構造化プログラミング以前のことは想像できない。
だからそういう感じなんだと思うんだけど。
12:02
Yoshiori Shoji
IoCっていうのは何かっていうと制御の逆転なので、
普通のプログラミング、
Cとかのめっちゃシンプルなプログラムって、
メインから実行されてってっていう処理が走るじゃん。
プログラミングが処理を呼び出してっていうのをどんどんやっていく。
なのでプログラミングが主なんだよね。
処理を呼び出して実行されるっていうのが今までのプログラミングで。
IoCっていうのはどういうのかっていうと、
例えばJavaScriptとかそうなんだけども、
ブラウザで何かイベントが起きるとプログラムが呼び出されて発火するわけじゃん。
大体のWebフレームワークとかもそういう仕組みになってると思うんだけども、
自分で能動的に何かを発火するんじゃなくて、
何かプログラムとかフレームワークとか、
環境から呼び起こされてプログラムが実行されるっていうのをIoCで言っていた。
でも今も当たり前すぎてあんまりピンとこない気がするんだよね。
だから逆に考えるの難しいなと思うんだけど。
っていうのは原則として考えられて、
そうなったときに呼び出されたときに、
メインからのプログラム書いてるとDBAのコネクションとか、
メインからの一番最初の数行に書いておいて、
あとそれ持ち回せばいいんでしょうとか思えるんだけども、
イベントドリブンでそうやってプログラムが呼ばれると、
じゃあDBの書き方どこですればいいの?みたいなのが分かんなくなったりするから、
DIみたいなのをやるといいよねみたいなのもあった。
draftcode
難しいね。
理屈で言っても様々な初期化コードとか考えられるし、
あとスプリングみたいなのも、
逆にメインっていうものがまず存在しなくなってるから、
何かの初期化をしたいんだけど、
どこでやればいいの?みたいなのってすごく分かりにくくなってる。
そうそうそうそう。
Yoshiori Shoji
DIコンテナっていう風になってくるとちょっと扱いが難しいね。
draftcode
これはよしおりと自分の前でやろうと思ったけれども、
自分でDIフレームワークみたいなのを作るっていう風になると、
あ、そこそこ簡単なんだみたいな感じのベースのコンセプトとしてはね。
そこからプロダクションレベルのDIコンテナになるとちょっとギャップがあるんだけれども、
特にスプリングとかは。
簡単なやつ、特にダガーとかはね、
本当に生成されたコードも見れるし、
こんな感じかみたいな感じのレベルですね。
Yoshiori Shoji
昔とかはジュースも1.0の頃はめちゃめちゃ素朴だったから。
draftcode
それがね、だんだん、
セッパーインジェクションみたいなのしたいとか、
マップインジェクションみたいなのしたいなとか、
生成タイミングでちょっと発火させたいなみたいなのが、
フック機構みたいなやつを入れ始めて、
作るやつになってしまうわけです。
Yoshiori Shoji
あとスプリングが多分いろいろややこしくしたのは、
15:01
Yoshiori Shoji
スプリングAOPだと思うんだよね。
AOPもね。
インジェクションするタイミングで処理を挟み込むみたいな、
トランザクションとか、
全部を理解したら便利なんだけどさ、
AOPも理解するの結構大変じゃん、概念として。
draftcode
自分はあんまりAOP触ってなかったから、
あんまり近寄らんとこっていう感じの雰囲気しか感じ取ってなかったけれども、
そうですね。
さっきインターフェースがあって言って、
特に我々今Javaのコンテクストで話してるから、
インターフェースがあって言った時にすごく誤解を招くような感じはするんだけれども、
インターフェースを定義して、
実際に具体的なクラスを複数定義するみたいなケースって、
そこまでないなみたいな感じのプログラミングをしてるんですね。
Yoshiori Shoji
それは多分、うん。
draftcode
大抵クラスがあればいいだけで、
そこから共通のビヘビアみたいなもの、
コンタクトみたいなやつをインターフェースとして抜き出して、
複数のクラス、実装クラスを作るみたいなパターンって、
コードバックとかは別としてもそんなにないなっていう。
Yoshiori Shoji
あとフレームワーク的なところを作ってる時はそういうのもいっぱいあるけれども、
普通のアプリケーションコードを書いてる時はまあないよね。
draftcode
そうだね。インターフェース提供するのはフレームワーク側が多いよね。
なので、インターフェースっていった場合に、
特にクラスベースで、この場合はクラスベースで考えてるんだけども、
そのクラスの単一責任原則を満たしたいみたいな要求が結構自分の中ではあって、
書いてるとこれすっごく責任が増えていってしまっているみたいな状態の時に、
パッと2つのクラスに分ける。
うまくちゃんと責任を2つのクラスに分けてインターフェースをきれいにしてやるっていった時に、
こういったDIコンテナーとかがあると、
もともとあったクラスを生成する方法っていうのは全部DIコンテナー側に押し付けられているから、
使用者側も全然考えなくても、
正しくこの責任はこっちのクラスになったんで、こっちのクラス使ってくださいって言ったら、
別にそんなにコードを変えなくてもスプリットができるっていう、
そういったリファクタリングがすごくしやすいなっていう意味が、
自分はDIコンテナーの中で非常に大きい部分を占めているかなって感じがしますね。
これが逆に使う側が生成方法をしない、
どうやってそのクラスを生成するのかっていうのを知らないといけないと、
いろんなところで、新しくデータベースに依存し始めたから、
これ入れて、こっちに入れてとか、スプリットしたから、
コンスタクターのアーギュメント分けてみたいな感じのをしないといけないんだけれども、
それがDIコンテナーによって全部抽象化された、なくなった。
18:01
draftcode
生成方法はDIによって隠されているっていうのが、
非常に自分の中では使いやすいツールだなって感じがしますね。
Yoshiori Shoji
俺もそう思っていて、
やっぱり生成方法と使用方法を分けるっていうのは、
すごい分かりやすいのかなっていう気がしている。
draftcode
これも言語が良くないのかもしれないけどね。
生成方法だけ抽象化できないんだよね。
コンスタクターだけ抜き出すみたいなのができなくて、
だからファクトリーっていうパターンが生まれたわけだね。
Yoshiori Shoji
ファクトリーっていうのはコンスタクターを抽象化するパターンなので。
draftcode
それがもしかしたら言語レベルでサポートされていたら、
もっと別の世界になってたのかもしれないけれども、
今のところJavaはコンスタクター自体を言語レベルで抽象化することはできないので。
Yoshiori Shoji
そうね。
まあだから、
でもまあそれがなんか、
draftcode
うん。
Yoshiori Shoji
その通り。
draftcode
その通り。
2人でそうだよねっていう風に言える感じになってるけどね。
Yoshiori Shoji
そう。
draftcode
みんなは、でもDI、
Java、Spring使ってる人はSpring、
まあ仕方ないじゃん。
でも他の言語の人はどうなんだろうなっていうのはちょっと、
なんとも言えないんだよね。
Java以外自分DI使ってないから、
よくいろんなこと言うなみたいな感じも多少してきてしまう。
Yoshiori Shoji
はいはいはい。そうね。
これは結構難しいよね。
なんでJavaでこんだけDIが必要だ必要だって言われてるのに、
他の言語で必要ないのかみたいなのは、
結構面白いところだなと思っていて。
なんかJavaとPHPぐらい?
draftcode
PHPもそうなの?
Yoshiori Shoji
うん。
draftcode
PHP書いてないからな、なんか。
Yoshiori Shoji
PHPも結構DIが流行っていた気がする。
でもそれ以外であんまりDIが流行ってるっていう話は聞いたことはない。
うん。
draftcode
だよね。なんか。
うん。
Yoshiori Shoji
なんか例えばなんだけれども、
DIっていうのは、
その生成方法を他に任せるっていうのが、
まあ、生成方法と使い方を分けるみたいなところが、
結構肝だよねみたいな話を今してたじゃん?
うん。
っていうので言うと、
それこそRubyで言うと、
まあRubyで言うとっていうかRailsで言うとか、
Railsで言うとだいたい継承でそれがなんか賄われてる感があるんだよね。
draftcode
へー。
Yoshiori Shoji
一番分かりやすい、
データベースのコネクションっていうのをどうやって表してるかっていうと、
そのアクティブレコードを継承したユーザーモデルとか、
そういうところがユーザー.クリエイトとかってやると、
21:00
Yoshiori Shoji
そのコネクションを持った親クラスを持っているから、
draftcode
うん。
Yoshiori Shoji
その、自分自身は作り方を知らなくてもいいって、
そのフレームワークが担保してるというか。
draftcode
それって、でも、
ある意味コネクションとかをグローバルにフレームワークを持っていて、
Yoshiori Shoji
そうそうそうそう。
draftcode
その、自分ではグローバルを定義してないんだけども、
インプリシットにグローバルを使っているっていうね。
Yoshiori Shoji
グローバルを使っているっていう。
DIコンテナもグローバルなコンテナだからね。
draftcode
そうね。その、理屈の上ではさ、
そのDIコンテナインジェクターみたいなインジェクターをさ、
複数定義すれば、
複数定義できるけど。
複数の世界が定義できてみたいな。
またこのインジェクターっていつも悪い奴でさ、
その、何かっていうと、そのライフタイムを制御したいから、
言ってた通り、そのDIコンテナっていうのは基本的にシングルトンの集まりで、
その、だからそのシングルトンっていうのも、
サーバーレベルのそのプロセスレベルのシングルトンと、
まあリクエストレベルのシングルトンみたいなのが欲しいなみたいな。
リクエストのライフタイムだけシングルトンになったみたいな。
で、そういうリクエストシングルトンみたいなところにさ、
なんかログ、なんか、
JSONロギングとしてなんか最終的に出るような、
1個のログオブジェクトみたいなやつ持ってると便利なんですけど、
なんか、あとなんかリクエストレスポンスとかのオブジェクトができるみたいな。
ライフタイムが違うオブジェクトのシングルトンの集まりみたいなやつが、
どんどんできていって、
これがまた、これを制御しようと思うと複数の、
インジェクターの親子関係みたいな感じの、
Yoshiori Shoji
そうだよね。
draftcode
ができていって、これは悪いんだけども、
まあそうだね、その理屈の上ではインジェクターっていうのが1つの、
シングルトンスコープっていう風になってるけども、
実際にプロアクションで走らせるときは結局1つしかないんだから、
じゃあ、もうグローバルでいいのよっていう、
スタティック最高みたいな感じの世界観もありだよね。
Yoshiori Shoji
結局そのインジェクターもさ、
インジェクター自身も管理するためのものが、
結局グローバルな何かになるわけじゃない?
draftcode
まあ、それだけ、
そこだけなんか最終的に、
最初のメインのスタートポイントのところでインジェクターを作って、
で、それだけはメイン関数のノーカルに入ってるみたいな感じのスタートとかね。
Yoshiori Shoji
なんで、ちょっと話を戻すと、そんな感じでグローバルな、
グローバル変数置き場って言うと乱暴だけどさ、
でも実際問題、スプリングとかが入る前ってそうやってたのよ。
スタティックなクラスにDBのコネクションを持っておいて、
それを持ち回って、コネクションプールとかを持ち回って、
DBにアクセスするみたいなのをやってたんで、
まあそのDIコンテナ、DAじゃないよ、DIコンテナには、
そのグローバルオブジェクトのコンテナっていう側面もあるよねっていう。
draftcode
そうだね、それが結構側面というか大きいよね、そこも。
Yoshiori Shoji
大きい、大きい。
draftcode
シングルトンがないこうDIコンテナ、
24:00
draftcode
いや、自分がそのクラスの分割をそれとかに使うんだけども、
まあでもシングルトン欲しいよねって言ったのもね、結構あるしね。
あとパターンとしてあるかなって思ったのは、
そのコンテクストみたいなものを使って、
そのグローバルっぽい動きを成立するっていうパターンもあり、
まあありあるいみたいな感じ。
これ多分Goとかもそうだし、
リアクトもコンテクストみたいなのがあって、
そこにいろんな、
例えばグラフQLクライアントみたいなものを押し込んだりとか、
その環境、その呼び出しコンテクストの中で使えるもの、
コンテクストローカルみたいなやつっていうのを。
Yoshiori Shoji
Javaのあるよね、
なんかスプリングアプリケーションコンテクストだし、
サーブレッドはサーブレッドコンテクストあるし、
リクエストコンテクストあるしみたいなさ。
あるあるある。
draftcode
多分そっちである程度代用もできるんだと思う。
こういうことやってると、
じゃあ結局どっちを使うのがいいんだよみたいな、
それは結構微妙な感じだよね。
どっちのパターンもな。
コンテクストコンテクストでさ、
あんまりタイプっていうものがないじゃん。
タイプっていうものがないって言うとあれだけど。
Yoshiori Shoji
そう、あれは本当にあれだよね。
グローバルにあるハッシュマップというかさ。
そうそうそう。
draftcode
そんな感じになりがちで、
ない場合があるみたいな感じの工事しないと。
絶対その仕組み上、
実際に動く中で、
ランタイムでは絶対この値は入ってるはずなんだけれども、
型の都合上絶対入ってない場合も
ハンドルしないといけないみたいなのがあったりして、
ちょっともにょにょにする感じかな。
Yoshiori Shoji
そう。
なので、だんだんDIコンテナの実装の話になってきたんだけれども、
DI自体は難しくない概念。
draftcode
のはず。
Yoshiori Shoji
のはず。
はず。
DIコンテナの実装とかのよりの話になってくると、
今みたいにちょっとややこしい話がいっぱい出てくるよねっていうのがあって、
ちょっと感じているのは、
制御の反転とか依存性の反転みたいな話もあるわけじゃん。
ソリッドのDの部分、ディペンデンシインバージョン。
draftcode
ディペンデンシインバージョン。
なんかこれ全部似たような名前だからさ、
Yoshiori Shoji
どれがどれなのか分かんなくなるんだよね。
IOC DI DIP?
しかもDIがディペンデンシインジェクションのときと
ディペンデンシインバージョンのときがあってややこしいよね。
で、制御の反転みたいな話でいうと、
インターフェースがあったことは結構大事だったんだよね。
そうだね。
AがBを使いますってなったときにBをインジェクションするんじゃなくて、
BのインターフェースをAは知っているだけ。
27:01
Yoshiori Shoji
で、実際にAに入れるのはBなのかBダッシュなのか、
それはこのB側が選べるみたいなところで
依存性の逆転みたいな話があったんで、
そういう意味でいうと、
多分インターフェースがあることは結構大事だったんだよね。
draftcode
まあまあ、分離できるっていうのはね。
Yoshiori Shoji
分離できるっていう意味でも。
ただ、今現在、
思想の話じゃなくて、
今現在のアプリケーションを実装するときは必要かっていうと、
まあいらないよねと思って、
インターフェース作んないよね、最近DI使うとき。
draftcode
闇の時代があってねって話をしました。
闇の時代が、人類闇の歴史ばっかりだから、
この闇の時代を調べたんですよ。
具体的には1993年ぐらいなんですけれども、
マイクロソフトの、
マイクロソフトってインターフェース、
マイクロソフトのAPIを見ると、
インターフェース文化だね。
分かんない、勝手に名前つけてるんだけれども、
あいなんちゃらっていうのめっちゃたくさんあるんだよね。
Yoshiori Shoji
あいなんちゃらめっちゃあるね。
draftcode
そう。
古くはコンポーネントオブジェクトモデルっていうのがあって、
僕この辺でコミュニティティゴジゴジ言ってるのはおかしいと思うんだけれども、
コンポーネントオブジェクトモデルって言ってもらって、
その時は多分夢があったんですよ。
僕もね、
Excelとかを非常に自動化するみたいなバイトをしまくって、
おお、いいオートネーションだ。
おお、Pythonだ。
Pythonでコミュニティをたたけるから、
Pythonでいろいろできるじゃんとか、
WebScriptでいろいろ全部たたけるじゃんみたいな感じの、
その仕様に従ってはいいじゃんね、
すごいねみたいな感じで思ってたんですが、
そういう時は、
インターフェースっていうのがまずあって、
あいなんちゃらっていうのが全部あって、
その上で、
なんとかインプルみたいなやつがペアであって、
全てのクラスは、
あいなんとかっていうインターフェースと、
なんとかインプルっていうのがペアになってて、
必ずそれを作らないといけないみたいな感じの世界観だったんだよね。
今そんなことやってたら、
すいませんね、マイクロソフト規範になっちゃうんで。
今そんなことやってたら、
マジで?みたいな感じがしちゃうんだけど、
そういう時代もあったんだねっていう。
ギャミの時代だね。
Yoshiori Shoji
想像すると1個分かるのは、
インターフェースを1個切り分けておくと、
特にマイクロソフトとかもそうだと思うけどさ、
ものすごくでかいソフトウェアだと、
それぞれの実装者を分けられるんだよね。
draftcode
理屈の上ではそうだね。
Yoshiori Shoji
今俺たちも結構やると思っててさ、
例えばグラフQLのスキーマを先に作っておいて、
俺バックエンド作るから、
にじくフロントエンド作っておいてみたいなことやるじゃん。
あれってグラフQLのスキーマがインターフェースなわけじゃん。
分けるっていうのと同じことができるんで、
そのインターフェースを決めるっていうのを先にやって、
30:00
Yoshiori Shoji
インプリはそれぞれ別の人が違うところでできるみたいなのは、
未だにそんななくはないんじゃないかなぐらいの感覚では。
自分の中ではやるけれども、
draftcode
それをクラスレベルではやらんかなみたいな感じの話かな。
何事も程々というか、
適切なレベルでやるのがいいのよみたいな感じがね。
確かにな、今多分アイナッチャーとか見たら若い人、
これイミュータブルなんとかですかっていう感じで、
アイリストとか見たら、
これイミュータブルなんとかですかねみたいな。
Yoshiori Shoji
アイって何ですかってなる。
draftcode
インターフェースってやつがあってさ。
インターフェースを作るか作らないかによらず、
もちろんどういったメソッドをそこに生やしておくといいのかっていうのは、
考える価値は全然。
むしろ考えてほしい。
ちゃんと設計してほしいっていう感じがしますね。
なんとかインプルとか見るとね、
Yoshiori Shoji
昔だからSpringの時は作ってたよ全部。
一番初期の頃は、
インターフェースにiは付けなかったけれども、
インターフェースの方に要はユーザーサービスみたいな名前をついてて、
実装クラスにユーザーサービスインプルみたいなのをやったね。
これちょっと余談になるんだけどさ、
Juiceの1.0が出てきた時にさ、
俺はちょっとさ、え?って思ったのが一個あって、
その頃はまだね、Springが出たばっかりでさ、
EJBの呪縛からやっと解き放たれて、
軽快な開発をできるようになってて、
IoCとかが素晴らしいなって思っていた頃の俺ね。
俺がJuiceが出た時って、
ちょうどJavaのアノテーションを使ってDIし始めたの。
多分Juiceの方が先なのよ、Springより。
Springも同時に実装し始めてたけども、
Juiceの方が世に出たのは先で、
で、atmark injectって書くとそこにインジェクトされますみたいな、
これは便利じゃんみたいになったんだけども、
結局そのインターフェースに、
実装クラス何をインジェクトするのっていうのは、
どっかには書かなきゃいけないわけじゃん。
それはXML、Springの昔の方だとXMLで書いたりとか、
Juiceも昔はプログラムで書いてたのよ。
今のJuiceとかDaggerがどうかは分からないけども、
config.bindなんちゃらみたいなので、
このインターフェースにはbind toで、
この実装クラスをみたいなのを、
一番最初のメイン関数の最初の方でそれを書いておくと、
atmark injectでインジェクトされるところに入りますよ、
みたいなのが最初の設定だったんだけど、
確か1.0が出るときに、
atmark implement byっていうアノテーションができたのよ。
draftcode
あるね。今もあるよ。
今もある。
Yoshiori Shoji
何かっていうとインターフェースに、
33:01
Yoshiori Shoji
このインターフェースの実装クラスはこれですっていうのを書くためのものなんだよ。
インターフェースにそれ書いちゃったら逆転じゃないじゃん。
draftcode
分かるよ、その気持ち。
Yoshiori Shoji
IoCは何だったの?みたいな気持ちにちょっとなった。
draftcode
実際デフォルトインプがそれっていうのを示していて、
さっきのbindとかでオーバライズできるっていうのは。
Yoshiori Shoji
オーバライズできるんだけど。
draftcode
別なんだけれども、気持ちは分かるよ。
Yoshiori Shoji
多分現実界的にはそっちの方が使いやすいのよ。
そういうのもなってて、現実界的には、
どっかで多分現実界的にはインターフェースいらないよねっていう話になって、
インターフェースももう作らなくなったのが、
最近なんじゃないかなっていう気はしている。
draftcode
最近かっこ何年前みたいな感じの話ではあるけれども、
あとあれだよね、Mockライバリーの進化っていうのがね、
多分すごかったなっていう感じがするね。
Mockって言うとまた怒られるから、
Mockじゃなくて、みたいなテストスタブです。
テストスタブ。
あるよね、フェイクとMockとスタブと、
draftcode
あともう一つ、なんかダブルがあって、
全部違うんだみたいな感じの、
すいませんでしたみたいな感じになっちゃったけど。
Yoshiori Shoji
すいませんでした、僕ちょっとよく分からないんで、
全部合わせてMockって言っていいですかみたいな感じになっちゃった。
昔は、
人類が知識をつけて、
さまざまな闇に今魔術をやった結果、
いろんなものがMockできるようになったから、
わざわざインターフェースを作らなくても、
draftcode
Mockしやすいですねっていうことがあって、
一応やっぱりMockをするためにインターフェースを作るみたいな側面もあったから、
それが一つ需要がなくなったっていうところかな。
Yoshiori Shoji
そうね。
いまだにインターフェースが必要な時に使えるようには全然できてるしね、
全てのDIコンテナ。
デフォでは使わないで本当に必要なところだけ使うっていうのは、
すごいメイクセンスな気がするよね。
draftcode
なんだかそれのおかげで、
こういったさまざまなものができたおかげで、
ナチュラルな使い方ができるようになったんじゃないかなっていう感じがするよね。
わざわざシステム上とか言語上の制約によって、
何か作んなきゃいけなかった、
何とか作んなきゃいけなかったみたいなのが、
何かそういうのいらなくて、
別に作りたいように、
普通に自然にクラスを書いておけば、
それがDIで、DIコンテナによってインジェクト可能になる。
これをシングルトンにしたかったら、
シングルトンって書けばいい。
36:00
draftcode
そう言ってたわけだけど、
そんな感じになってるかな。
そうでもね。
なんで、
Yoshiori Shoji
俺の中での答えは、
この前の継承に若干近いかなと思ったんだけど、
思ってて、
一番最初に考えられたときは、
すごい崇高な依存性の逆転とか、
処理の制御の逆転とかを含めて考えられていた仕組みだったんだけど、
今はぶっちゃけオブジェクト生成器と保持場所、
ストアする場所ぐらいの感覚で使われてるよね。
そうだね。
オブジェクトの継承が、
本当はモデルをうまく継承してツリーを表していたはずなのに、
継承になっちゃったのと同じように、
今はオブジェクトの生成器とストア場所です、みたいな感じで、
うまく使われてる。
ただ継承と違うのは、うまく使われるようになったなっていう気がする。
draftcode
うまく使われてる現場ではうまく使われてるんだろうなっていう感じがするけど、
どうだろうな、自分未だにSpring嫌だなって思うからな。
Yoshiori Shoji
Springの嫌なところはあれでしょ。
機能が多すぎたからでしょ。
draftcode
そう言うとちょっとあれだけど、
完璧に言うとそうなんだと思う。
素朴な世界観で収めたいっていうモチベーションがどうしてもあって。
わかるよ。
現代ではこういう感じだよねっていうレベルの機能でOKにしてほしいんだよね。
なのでSpringを打ってなるし、
でも最近もうJava書かなくなったからな。
逆にJava以外の言語でどうしてるんだろうっていつもさっきも言ったけども、
自然にDIとかを使わずになんとかなっているんだから、
なんとかなんとか。
逆になんでJavaはそうなってないんだろうねっていう感じは。
でも逆に言うとJavaはDIコンテナが出る前はそのコンテキストとかに持たせてたのよ。
Yoshiori Shoji
サーブレットコンテキストとか。
ちょっと野蛮じゃん。
draftcode
今更変なオブジェクトが帰ってきてキャストするみたいな。
野蛮じゃん。
あとラストとかはどうなんだろうねっていう感じもするかな。
一つの予想としては、
自分はあんまりラスト書いてないんだけど、
ラスト式者の人に。
特にラストでどうだろうな。
CNIとかだと結構プログラム自体のライフサイクルが短いかもしれないし、
ラストでウェブサーバーとかを書いている人たちはどういう感じなんだろうなっていうのはちょっと気になる。
そうだよね。
だからそこが今言ったドラフトコードの底が肝だと思ってて、
CNIとかのアプリケーションとかのアプリケーションっていうのは
基本的にCNIとかのアプリケーションっていうのは
39:00
draftcode
CNIとかのアプリケーションっていうのは
Yoshiori Shoji
だからそこが今言ったドラフトコードの底が肝だと思ってて、
CNIとかのアプリを書いているとき、
ラストでちょっとしたコマンドラインアプリとかを書くときっていうのは
IoCではないんだよね。
上からメインから書くから。
そのときは必要ないのよ、やっぱり。
だから本当にでかいウェブアプリケーションとか書いてる人がどうしてるかを聞かないとわからないよね。
draftcode
ぶっちゃけCNIとかだったらグローバルに適当に置いて書くんですよ。
まあまあっていう感じはするし。
サーバーもそうなのかな。
サーバーの大規模になるとちょっとあれかわからないけど。
Yoshiori Shoji
それこそGoはどうなのよ。
draftcode
Goは自分の中では、
Goはまず処理の階層を浅くしたいっていう特色があると思っていて、
エラーハンドリングがあんまり深いところからローレベルのエラーをどんどんどんどん上にラップして投げるみたいなのがちょっと微妙。
ある程度処理自体を浅くしたいっていう面があると思ってて。
なので本当にデータベースをすごい深いところから読んでいるみたいなことはあんまりないんじゃないかなって思ってるのね。
ってなるとインプットによってアップが決定されるようなファンクショナルなものを後でラベラリーにぴょって変えてもらうみたいなパターンがまず一つあるのかなっていう。
あともう一つ、そうだね、ソデーが青いのどうなんだろうね、かなっていうふうに今予想してるけど。
Yoshiori Shoji
そうなってくるとさっきのRailsの話もそうなんだけどさ、言い方を変えるとそのフレームワークとかウェブフレームワークとかそっちがDIコンテナの役割的なこともしてるってことだよね。
そのグローバルなオブジェクトの生成とそれをどう渡すかみたいなのはフレームワークがやってくれてる?
draftcode
いや、多分その単純にメインコンセルがどっかにあって、そいつがそいつの中でデータベースコネクションとかを作ってるんじゃないかな。
それをクロージャーとして持ったハンドラーみたいなやつをポチポチポチポチセットしていくみたいなパターンとか、
そもそもサーバーオブジェクトみたいなの作って、その中のその上にメソッドをいろいろ定義して、それがハンドラーになってるみたいなパターンなのかな。
あんまりGoアノテーションとか、アノテーションがないという人はあるんだけど、そういう感じではないので、
明示的にこのURLのハンドラーはこれみたいな感じのセットすると思うんだけども、そういう風になってるのかなっていう風に思っています。
あとそうだね、ORMみたいなやつを使ってる人は、最初のORMのクエリ、ドキュメント、オブジェクト、エンティティ、何でもいいけどもをクエリしたら、
42:08
draftcode
そのエンティティに表すオブジェクト自体にデータベースコネクションみたいなのが既に内蔵されていて、
そこから次のオブジェクトみたいなのをどんどん辿っていくって言ったときに、別にその部分ではあまりコネクションとかを意識しなくてもいいから、
最初に必要な何かオブジェクトをクエリしてしまえば、そこからあとはそのオブジェクト自体を渡してあげればいいので、
Yoshiori Shoji
あんまり意識しないところだよね。
アクティブレコードとかも、アクティブレコードっていうのはアクティブレコードパターンの話じゃなくて、
Rubyのアクティブレコードもそんな感じだよね。
今あれ自体が持ってるからっていう。
draftcode
なので、Javaの場合って言うとあれだけれども、
深い階層で、呼び出しの階層の深いところからデータベースをクエリしたいっていう要求は、
そんなに直接クエリしたいっていうことはあんまりないのかなっていう気分があるかな。
Yoshiori Shoji
設計層の違いなのかな。
draftcode
でもJavaもそんなに深い階層からデータベースクエリ投げたいかというと気持ちしなくてもないけど。
Yoshiori Shoji
投げたくはないけれども。
draftcode
そうだね。
でも言うて、RPCクライアントみたいな、APIクライアントみたいなんですか、
どこかで作らないといけないしね。
グローバルでもいいんじゃないかなっていう感じは微妙にするけどね。
どうせみんなテストでめんどくさくなるか。
Yoshiori Shoji
逆にテストグローバルに持つといけない。テストでもそこのグローバルぽっと書き換えればいいんだけど。
draftcode
そうするといい感じにテストがクリーンアップしないとか。
Yoshiori Shoji
アフターでクリーンアップしないとどうかみたいな話が出てくる。
draftcode
またパラレルで走んないんですよとか。
このテストの後にこのテストを走らせないとこのテスト落ちるんですよみたいな。
そういう意味わかんないパターンが出るんだよ。
Yoshiori Shoji
クソだなっていう。
わかった。
そういう意味でもグローバルをちょっと抽象化してくれてるものがいろいろあって、
その中の一つがDAっていうことなのかな。
draftcode
そうだね。グローバルやっぱり嫌だねっていうのがあるから、
それをグローバルを抽象化したいっていう気持ちはみんなあって、
それをグローバルやめたい。
そういうグローバルみたいなものはやっぱり厳しいっていう気持ちがあるから、
それを何とかしたいっていう欲求がみんなあるんだけども、
それをどうするかっていうと一つの回が多分DIみたいになったんですよ。
DIコンテナ。DIフレームワーク。
そういったものになっていて、それ以外だとコンテクストみたいなやつもあるし、
45:01
draftcode
本当に素朴にグローバルとなるようなものを排除して、
素朴に受け渡していくっていうのもあるのかもね。
Yoshiori Shoji
基本的にグローバルが欲しくなるときって、
大体外部とのコネクション以外で何かあるのかな。
例えば今言った話だと、
DBのコネクションはグローバルで管理しててほしいじゃん。
コネクションプーリングとかあるしさ。
あとはHTTP周りのクライアント。
GRPCとかも。
もうちょっと管理しててほしいなっていう。
サーキットブレーカーとかもあるし。
draftcode
あとはキャッシュかな。
Yoshiori Shoji
キャッシュも。
draftcode
シングルトンいつつけるかなっていったときに、
そういったコンスバクトが、
シングルトン何いつつけたいかっていうと、
意味的にシングルトンっていうパターンと、
思いからシングルトンみたいなパターンがたまらなくて、
意味的にシングルトンっていうのは、
これ本当にサーバー内で一つのオブジェクトしかない状態にしないと、
意味がなくなってしまうみたいな。
カウンターとかそうだよね。
サーバー内でリクエストカウンターみたいなの持ちたいときは、
毎回カウンターを持つオブジェクトっていうのは、
毎回作るんじゃなくて、
サーバーで一個っていう。
これ意味的にシングルトンじゃないといけないとか。
キャッシュとかは、
毎回キャッシュをフラッシュしても、
まあいいけど意味ないよね。
だから動きはする。
セマンティクス的に、
契約的に動きはするんだけれども、
一個じゃないといけない。
これも意味的にシングルトンっていうパターンかな。
あとはデータベースコネクションとかあるよね。
これはコンストラクトがハイコストだから、
シングルトンのほうが良いというパターン。
Yoshiori Shoji
その辺はないときは、
ぶったけDIなくてもいいのかなっていう気も。
draftcode
まあ、
物は使いようだから、
便利に使えばさっき言ったみたいに、
クラスをうまく分離して、
モジュールを分離して、
それを影響なく、
吉田にやってあげることができるパターン。
でもそれも結局最終的に、
コンストラクト自体が簡単だったら、
それも特に意味もないんだと思うんだけれども。
あとは全部スタティックみたいな。
多分リアクトコンポーネントとかは
全部結構スタティックだから、
良いような気はするね。
リアクトコンポーネント結構全部スタティックだよな。
あれもあれか、さっき言った最初に設置して、
全部レンダリングするっていうパターンだから、
内部で設置しないんだよね、別に。
しないよね。
あんまりスラントエンドやってないような気もするけれども。
Yoshiori Shoji
でも中のデータが変わると自動的に
呼び出されるよね、イベント的に。
draftcode
それはそうなんだけれども、
その中でリアクトコンポーネントの
めっちゃ深いところで、
ここでもAPIフェッチをして、
この上の方でもまたAPIフェッチをして
48:01
draftcode
っていう感じにするかっていうと、
あんまりしないのかな。
一番上の方でデータフェッチをして、
それをその結果、
よくわかんないJSONがギアって返ってきて、
それに基づいて
いろんなUIコンポーネントをレンダリングしていく
っていう世界観なのかな。
Yoshiori Shoji
でもあれだよね、多分。
もうちょっとモダンな今の現代的なのだと、
GraphQLのAtomのクライアントが入っていて、
それぞれのコンポーネントで、
欲しいコンポーネントの
GraphQLクエリみたいなのも敷いていて、
それが流れた後、
全部の処理がまとまって、
Atomクライアントが
そのGraphQLのクエリをまとめて、
ボンって一個リクエスト投げてくれて、
返ってきてデータがみたいな。
draftcode
まあまあまあ、
2個に分かれているってことだよね。
本質的には2個に分かれているんだけども、
1個で書かれているっていう感じが。
1個で書かれている。
そうだね。
まあ、なので
外界との繋がりの部分が
一番重要なのかな、
Yoshiori Shoji
DIA。
draftcode
そうね。
中小化したい。グローバルっていうものを中小化したい。
うん。
Yoshiori Shoji
そう、でもこれね、
ちょっともうそろそろ話が
終わってきた感があるので、
ちょっと今回調べてて面白かったことを
一つ言うと、
そのマーティン・ファウラーがDI
っていう名前をつけた
2004年1月
の頃で、
これまだSpringがメインだったんだよね。
このファウラーは
そのDIの設定を
プログラミングで書けるべき
だ、みたいなことが書いてあるんだよね。
うん。
だからJuice的なアプローチだよね。
Bind toみたいな。
XMLとかで
書けてもいいけれども、それはオプションであって、
基本は全部プログラムで書けるべきだ
みたいなことが書いてあって。
なんかさ、マーティン・ファウラーの
文章って後から読み返すと
あ、ファウラーは昔からこれを
知ってたんだみたいなのが出てくるんだけどさ。
マイクロサービスの時も
そうなんだけど。
ああっていう新たな発見があって
ちょっと面白かったね。
draftcode
やっぱり今は
今は
様々なアプリケーションの
コンフィグというか
Yoshiori Shoji
考えた時に
draftcode
ある程度プログラム可能な
コンフィグファイルっていうのを
使うんですかね。どうなんでしょうね。
みんなもう
XMLは使わないじゃない。
うん。
YAML?
ここでねまたちょっと
ホットな
ホットかもしれないまた出すと
HCLっていう言語もあって
ハッシュコープコンフィグランゲージ
ハッシュコープ今燃えてますけれども
あれもプログラミング可能な
コンフィグランゲージであるし
ポピュラーなのかもしれないけど
51:01
draftcode
あんま使わない。
使うとこはあると思うんだけどな。
そこまで使われてないのかな。
結構使われてる気はするわけもないけど。
Yoshiori Shoji
コンフィグランゲージみたいな
アパッチのコンフィグファイルみたいな
よくわからないのを
draftcode
イニファイルとかじゃなくて
Yoshiori Shoji
イニファイルみたいなやつ
そう
コンフィグイニみたいな
あの書式よくわからないなと思ってたんだけど
FluentDが似たような書式になってて
draftcode
うってなった記憶が
カッコが二重になってるみたいなやつとか
そうそう
トムルかなあれ
Yoshiori Shoji
トムルではなかった気がするんだけどな
トムルはもうちょっと
構造化がわかりやすくなってた気がするんだけど
まあまあちょっと話が発散してきた
draftcode
DIのコンフィグは
やっぱり
自分は
このプログラミング言語上でやるのは
あんままず
そもそも
DIでコンフィグをするなっていう話を
自分はちょっとしたいけど
まずコンフィグをしなくて
デフォルトインジェクションでできる感じで
終わらせようっていう
こっちはまずあって
どうしてもしなきゃいけない
っていう場合は
最小限に
プログラミング言語で
このインターフェースは
これにバインドされています
以上みたいな感じで終わらせたい感じがしますね
Yoshiori Shoji
で多分
コンフィグファイルでも
プログラミングで書くときも
そうなんだけども
めちゃめちゃ大事なこととして
設定する箇所は一箇所であってほしいよね
draftcode
一箇所であってほしい
これも
一箇所っていうのを
様々なクラスに分割されて
様々なクラスに書かれているっていう感じ
っていうパターンと
やっぱこれ
テスト用とか
デベロップメント
プロダクション用とデベロップメント用みたいなのが
あって
コモンみたいなやつを作りたいから
コモンモジュールとデベロップメントモジュールとプロダクションモジュール
みたいな感じにしたいんですよ
コモンみたいなパターンもあって
様々な
思想があるんですけど
言いたいことが分かる
Yoshiori Shoji
ある程度一箇所にまとめててほしい
draftcode
オーバーライドしないでほしいですね
オーバーライドしないでほしい
ベースみたいなのがあって
その上にオーバーライドされてる何かみたいなのがあると
これコンフィグ全般に
言える気はするんですけども
一箇所見て
こうなんだって思ったら
違うところで違う値があって
マジかみたいな感じ
Yoshiori Shoji
気分になりがちですね
それがさっきした
Juiceのインプリメンテッドバーになったよね
draftcode
そうそう
デフォルト用意すると便利でしょみたいな感じの
雰囲気を醸し出してるけどもね
Yoshiori Shoji
テストの時だけ実は違うところでバインド2してますみたいな
クソそれ分かんねーよみたいな
draftcode
ハマりをするやつ
批判を受けると
お前ら
54:01
draftcode
インターフェースが重要だって言ってたじゃん
実装が何であっても
インターフェースが分かっていたらいいんだよみたいな感じで
言われるかもしれないんですけども
どうしても
デバッグとかをするときに
実装クラスを追うよね
実装クラスを追わないといけないとか
あと
ソースコードに重大な疑義がある
ソースコードに自信がない場合は
これ契約でそう言ってるけど
実際は
インターフェースに書かれているとか
メソッドに書かれている
ドキュメントに書かれていること以上のことを
知りたい場合があるんだよね
本当に
中身がこういう風になってるのかとか
実はこれ
インプットが相当下げなきゃいけなかったみたいな
書かれてないとか
そういう場合があったりするんで
読むときに実際に実装はどうなのか
見る必要はあるんですよ
言い訳をするとね
Yoshiori Shoji
どうなのか
ヌルのリストは渡してはいけないのは分かってるんだけど
draftcode
空のリスト渡していいんだっけみたいな
そうそう
それもね
ドキュメントに書いて
まずヌル
リストとか
いろいろあるよね
Yoshiori Shoji
多分
DAとかIoCとかの
すごい厳密に言うとDAコンテナって
多分設定は設定で
分離しておかなきゃいけなくて
それがXMLであろうがプログラミングであろうが
いいと思うんだけど
どっかに分離はしておかなきゃいけない
インターフェースの実装も分けておかなきゃいけない
多分めちゃめちゃ原理原則
的な部分なんだよね
でも現代的にはもうそれ使えないから
それめんどくさいから
そうはやめとこうね
だいたいこうなんか
アットマークインジェクトでデフォルトのが
一個に定まるように実装しようね
draftcode
っていう
自然な思想はそうだったのかもしれないが
そんなオリジナルの思想はいつまで
引き継っててもしょうがないんでね
逆に
全部分離されてたら
うんっていう
Yoshiori Shoji
今はもうなるよね
ちょっとね
宅配便が来た
draftcode
はいお待たせ
Yoshiori Shoji
カットされました
カットされないかもしれないめんどくさかったら
draftcode
結構DI周りって
我々マネージャーとかでクリーンとかしてると
DI分かんないですよみたいな感じで
言われることって
何回かあるじゃないですか
うん
どういうパターンなんですかねやっぱり
Yoshiori Shoji
煽りパターンと
正しく答えるパターンで言うと
draftcode
はいどうぞ
Yoshiori Shoji
煽りパターンで言うと
君はオブジェクト思考分かってるよね
ソリッド原則知ってるよね
ソリッド原則のD分かるよね
それですで終わりなんだよね
煽りパターンで言うと
DI分かんないんですって言われて
答えるべきは
57:01
Yoshiori Shoji
ちゃんと真面目に答えると
DI分かんないですって言っている人の
ほとんどはDIコンテナの動きが
分からないですとか
DIコンテナをどう使えばいいのかが
分からないですなんだよね
多分DIという思想が分かんないとかではなくて
スプリングでこうこう
こういう風になってるんですけど
思った挙動しないんですけど
なんでなんですかだと思うのよ
基本的にDI難しいって言ってる人は
draftcode
それか
あとあれかもね
なんか
コンストラクターにアーギュメントを書いていくと
勝手に入ってる
なんか魔法が起こって
そこに入ってるんだけれども
なんかよく分かんないままずっと
とりあえずそこに書けば入ってるんだろう
みたいな感じでやってると
なんかよく分かんないものを使って
よく分かんないコードを書いている感じがしてきて
こうDI分かんないんですよね
みたいな感じの
その特に具体的に手元に
問題があるわけではないかもしれないけれども
怖いみたいな感じのパターンも
Yoshiori Shoji
あるのかなっていう
多分DI分かんないんですよねーが
言う人がもう一つ言うのは多分
アノテーションが分かんない何をやってるか
分かんないっていうんだよねみんな
アノテーションは本当にただの
アノテーションでしかなくて
DIコンテナフレームワークとかが
それを利用して色々やってるだけなんだけれども
っていう
話からしなきゃいけなく
なっちゃうじゃん正しく話すとさ
draftcode
そうね
Yoshiori Shoji
だからそこをちゃんと話してあげるのが
大事なんじゃないかな
DI分かんないって言われたら
DAって概念は別に多分どうでもよくて
DIコンテナのフレームワーク
っていうのがあって
それがアノテーションを元に
プログラムを走らせるときに
このアノテーションがあったときに
これは僕が持ってるこれをここに
インディクトしなきゃいけないんだなって
インディクトしてみたいなのをやってるんですよ
draftcode
っていう
手元に問題が
ある場合に
それを一緒に
DIが分かんなくて
なんでDIが分かんないか
って言ったときに
なんでDIが分かんない
って言い始めたのか
っていうと手元に問題があって
それをデバッグしたい
それを直したいんだけれども
コードが
追えないっていう
パターンが何回か
見たことがあって
で
やっぱり
実際にその実装クラスが入っている
インジェクトしてるものも実装クラスで
インターフェースもなんもないんだけれども
なんか
どれが入ってるのか分かんないみたいな
ことを言われる場合があって
でもこのクラスはこのクラスしかないんだから
このクラスしか入ってこないのよ
みたいな風に言うんだけど
あまり納得してもらえないことが
まあまあありますね
Yoshiori Shoji
なんか
シンプルなパターンは結構
楽だと思うのよ
例えばレシピサービスっていうのに
アットマークインジェクトってついてて
それがインジェクトサービスで
レシピサービスの使ってる
1:00:01
Yoshiori Shoji
コードを読むってなったときは
このクラスに行けばいいのよ
でもさ例えばさ
データソースっていうのが
インジェクトされますって書いてあるんだけど
データソースっていうクラス
これはSpringが作ってるクラスで
どこにあんのっていうとさ
アプリケーションの一番
トップのところにアットマークビーン
とか書いてあってさ
データソースとかが作られて
リターンでデータソースが返ってるみたいなのが
あったりするわけじゃん
そういうところが難しくなってると思ってて
そういうところの難しさってやっぱり
draftcode
DIコンテナの難しさなんだよね
DIコンテナとそれを
使用して
フレームワーク側の
難しさもあるよね
個別のケースによるのかな
ここで
よくわからないなって
もちろんね複雑なプロジェクトになってくると
それぞれでDI
DIフレームワーク
DIコンテナ
様々な特殊な使い方を
できると思うから
どうしても
追いにくいっていう場合もあると思うんだけども
そうだね
まあ
そういうのをなくすために
極力シンプルな使い方に
持っていきたいなとは
Yoshiori Shoji
思うけどね
あと前ドラフトコードってやったけど
DIコンテナを自分で作る
ワークショップみたいなのをやる
draftcode
あれも
どこまでみんなに
使えるかなっていう感じは
ちょっとわからないけどね
僕たちからするとさ
DIコンテナなんて
コンストラクターのアーギュメントみて
クラス入れて
全部
作りゃいいのよって
これにまたシングルトンとか入れたいって
ちょっとせずになるかもしんないけど
特にコンストラクターインジェクションだけだったら
簡単でしょ
逆になんか
JavaBeansのさ
セットとかセットが入ってるさ
ゲッターセッターインジェクションとか
見るとちょっと
Yoshiori Shoji
身構えてしまうよね
draftcode
本当かって本当に大丈夫かみたいな感じになるし
あと
シンプルじゃないDIコンテナ
高機能なコンテナって
ヒールドにさ
Yoshiori Shoji
なんかよくわかんないけど
draftcode
リフレクションで入れるよね
プライベートだけど本当に入るんだよなみたいな
これファイナルじゃいけないんだよねみたいな感じ
なったりとかね
最近のリコメンデーションは
コンストラクターインジェクションをするっていう
Yoshiori Shoji
でもねそれがね
またファウラー感になるんだけど
マーチン・ファウラーのこのドキュメント見ると
コンストラクターで入れろって書いてあるんだよ
draftcode
そうだよね
そうだよね
Yoshiori Shoji
でそれは
そっからまた
またお前からの名前がもう一個出てくるんだけど
今度はケントベックが出てきて
それファウラーが
ケントベックのスモールトークの
デザインパターンの本に書いてあるけれども
基本的に必要なものは全てコンストラクターで渡すべきだ
ってのがスモールトークの
設計のベストプラクティスにも書かれている
だからコンストラクターでインジェクトしろ
1:03:01
Yoshiori Shoji
ってのが書いてあんのよファウラーが
draftcode
2004年1月に
Yoshiori Shoji
そうなんだよ
draftcode
コンストラクターはコンストラクトするためにあるんだから
それでコンストラクトできなきゃ
おかしいんだって
Yoshiori Shoji
そう
draftcode
そうなんですよ
いやーわかるなそれ
Yoshiori Shoji
DIがわからない人は
マーティン・ファウラーのこれを読むと
今でもマジで通じるって思いながら
俺昨日めちゃめちゃ
こいつ本当に何でも知ってたなって思って読んだ
こういうのもさ
draftcode
わかった後に
見るとさ
Yoshiori Shoji
こいつ何でも知ってたなみたいな感じ
draftcode
思うんだけどね
またね
最初に見ても何かわかんないんだよね
わかんない
Yoshiori Shoji
それこそ
マーティン・ファウラーとかケント・ベッカーすごいよね
draftcode
相当リーダーシップっていう感じがするね
ちょっとまた
Yoshiori Shoji
宅配便が来てる感じがするから
draftcode
オス
Yoshiori Shoji
間に合いませんでした
draftcode
マーティン・ファウラー
マーティン・ファウラーって
コード書いてんのかな
コード書いてるのか
こういうコード書いてるんだと思うんだけど
Yoshiori Shoji
そうだよね
でもそれこそ
ブルーグリーン・デプロイとかも
ファウラーだよね確か
あれチャドだっけ
draftcode
チャド・ファウラーのほうだっけ
Yoshiori Shoji
とかだし
近年
もう10年ぐらい経ったのか
draftcode
マイクロサービスとかもファウラーだしね
でもこういうの
有名な人にちゃんと言ってるんだな
みたいな感じでもさ
自分でさ
ある程度の結論が出るわけじゃん
自分の中でさ
シンプルなクラスで
責任原則で責任を小さくして
みたいな感じでやっていくといいんだな
後で偉い人のやつを見て
やっぱ偉い人もそういう風に考えるから
自分も楽しかったんだみたいな感じに
ちょっとね
安心するとこがあるよね
Yoshiori Shoji
プログラミングの
ドキュメントに似てるよね
最初ドキュメント見てもなんだこれ
わかんねえな使い方と思いながら書いててさ
いっぱい書いて理解した後に
ドキュメント見ると
ここに書いてあるじゃん
ドキュメントの
ドキュメント全然足りないから
追加してやろうと思って
ドキュメント見に行くと
ここに書いてある
draftcode
全部書いてあるわ
Yoshiori Shoji
特に追加することはねえなってなる
draftcode
あの感覚に似てるね
完璧マニュアル人間はそういうのもね
全部わかってるんだと思うんですよね
ちゃんとねマニュアルが読めると
そうマニュアルがね
読めるようになるといいですね
Yoshiori Shoji
いいですね
まあということで
今日はこれくらいにしときますか
そろそろ締めていいかな
クレイジーボブに捧げる
いやー
draftcode
でもクレイジーボブなくなったことで
DIももしかしたら
これから廃れていく
消えていく運命かもしれない
1:06:01
Yoshiori Shoji
どうだろうね
でもスプリングはね
draftcode
残るだろうし
わからんよ
スプリングは
急に伝えた
急に技術伝えることはありますからね
あるあるある
急に復活する場合もあるけどね
ジャバスクリプトとかは
急に復活するっていうパターンなのかな
急にではないけども
Yoshiori Shoji
どのタイミングの話をしてる
Googleマップが出たときの話
draftcode
ジャバスクリプト
結構前の話よ
ジャバスクリプト
死んでいた時期も
あったわけじゃないですか
歴史の中で生まれていたというか
あまり
ウッという言語だった
時期もあったのに
もう今ジャバスクリプトですよ
ジャバスクリプト書かないけど
手で
Yoshiori Shoji
タイプスクリプトとかだよね
draftcode
でもちゃんと復活して
みたいなパターンもあるので
もしかしたらDIも復活するのかもしれないけども
まあでも
自分はJava以外では使わないかな
Yoshiori Shoji
そうね
DIの仕組みがちゃんと整ってるところだったら
使おうかなって気がするけども
今から自分で例えば
それこそGoとかRustとか
他のちょっと
硬い言語に
DIコンテナから
自分で書いて作って
使いますかって言われたら
draftcode
いらねえんじゃねって思うよね
あとあると思うのよ
全然そのRustの
DIライブラリとかGoのDIライブラリとかも
あるはずなんだけども
わざわざ入れなくてもいいかなっていう感じが
するかな
こう
そういうといらなかったんやみたいな感じに
思われるかもしれないけど
場合による
場合によるんですよ
Yoshiori Shoji
言語によるんだと思うんだけど
基本はオブジェクトの
生成と使用
箇所を分ける
あとは
draftcode
使用者は作らなくてもいい
Yoshiori Shoji
作り方を知らなくてよいっていうのが
実現できてれば
俺はまあいいかなっていう気がする
draftcode
Newとかしてなければ
いいかな
あとはシングルトンでね
シングルトンでStaticとかに入ってなければ
いいかなっていう感じは
はい
Yoshiori Shoji
じゃあ
以上です
次回は何に話すか何にも決めてない
draftcode
またなんかネタを
思いついたら
Yoshiori Shoji
第3回があるかもしれない
ないかもしれない
draftcode
はい
Yoshiori Shoji
おつかれさまでーす
おつでーす
