#218 SOLID原則のわかりづらい部分をビュッフェで理解する
2024/1/31 ·
-
大変お待たせしましたお?まさか?もうファンよだれじゅるじゅるのうわー
-
汚いファンだぜユッペカでございます本当によだれとかけてきたジュルジュルでしたねクレバーです僕は久しぶりですねもうやらないと誓ってたんですがやっちゃうことになっちゃいました誓ってたんですねもうやんないって思ってたんですけどねそうだよねむちゃブッフェだったもんな
-
むちゃびっふぇ今日もむちゃびっふぇかもしれないですが本日はですね駆け出しそうというか僕も含めよくわからなかったソリッド原則本当?
-
おー マズいやつオブジェクト思考言語をやるにあたってやらなきゃいけないやつでなんかあの説明するブログやら本やらはいろいろあるんですけども書いてることはわかるがつまりどういうことちゃってなるそうだよねつまりビュッフェだとどれなのってことだよねいやそうそうそうわかってないでしょみんなビュッフェで言うと何なのかそれ理解してないと一緒ですからうんそうだその通りだ今日本当の意味で理解できるそんな話になればなとよかったー
-
やっと対応付けできるのか聞きたかったですこれまでちょこちょこ出てきてましたもんねそうですねソリッド確かにお願いしますまずソリッド原則とはこれ僕原稿に書いてませんじゅんぺいが説明してくれるのかなやばいちょくちょく気になってましたってさっき言ってたのに本当に何一文字も出てこないんですがえっと
-
いやまあざっくり全体として何かやばいそれもわかんないSOLIDに分けられる作用まずソリッド原則僕も今ふわっとした知識で話すのにのりさんがうまく補足してくれるんですけどこちらはですねオブジェクト思考言語で綺麗なコードを書く保守性の高いコードを書くために守るべき原則5つを
-
PPAP的に「んん」ってまとめたのがソリッド原則です 正解!はいで、これはですね 5つの原則の頭文字を取っててですねまあソリッドっていう単語もですね 「頑強な」とかっていう意味があるので「お、これ繋げたらソリッドってなるやん」って はしゃいでソリッド原則になったらしいですねほんと? はい、これはクリーンアーキテクチャに書いてましたそうなんだ はいテンション上がったんだ そう
-
最初に原則いろいろ作ってまとめたらソリッドになるやんってソリッドになったらしいですそうなんだそう考えるとLは結構奇跡のLだと思うこれLにするために頑張ったまであります嘘でしょ嘘でしょマジでちょっと頭から一つ一ついきますねソリッド原則のS単一責任の原則というので
-
シングルリスポンシビリティプリンシポルってやつですかはいこれはですねよく言われる説明を最初に言うんですが個々一つ一つのモジュールを変更する理由がたった一つになるようにしましょうっていう原則です変更する理由がたった一つになるようにしましょうはい
-
つまりたった一つの役割だけを持っていれば変更する理由が一つだけになるよねというところですねただこれね言ったら分かるんですけど読んでも言ってる意味は分かるんですけど実際に落とし込むとどういうことだと
-
いう風になりますのでやっぱりビュッフェにしていこうかなと思ってますなるほど今回ビュッフェのどの視点でいればいいですか我々はそうですねまずビュッフェの説明なんですけどビュッフェの説明ビュッフェの説明からちょっと入るんですけど特殊ビュッフェなんですかいや特殊じゃないんですけど旅館ホテルか海沿いのホテルですね海沿いのホテル非常にあのなんでしょう
-
中高級層の海沿いのホテル1泊3万から5万くらいですかなかなかリッチなビュッフェがついているタイプのホテルを想像していただいて千葉いいですね千葉いいとこそうですねビュッフェを作るのにあたってソリッド原則が
-
守られてるんですよやっぱりビュッフェってビュッフェを作るにあたってビュッフェデザイナーの気持ちってことですかそうですねビュッフェデザイナーのかビュッフェアーキテクチャーのかビュッフェアーキテクチャービュッフェアーキテクチャーじゃんそっち側かビュッフェアーキテクとかそっちの目線から立ってもらえればよいかなと思います
-
なるほどねやったことない視点だそうですね食べるできる食べるつもりでいたんで食べないです食べるお客さんとしてくるのはCPUがあるのかなそうですね懐かしの前回のクーバーの実は忘れてもらって単一責任の原則はですねビュッフェで言うとビュッフェで出される各料理
-
はい 各料理はたった一つのお客様に対してアクターに対して責務を負っている状況になるべきですうんうんうんアクターっていうのは何かっていうとまあ役割ですねうんうんお客さんはお客さんだからビュッフェで言うと誰向けの料理なんだっていうとうん なるほどこれはビュッフェのお金を払ったかつアレルギーがないお客様に向けて料理を出してるんですねうん なるほど
-
アレルゲンビュッフェってことですか?アレルゲンビュッフェというかビュッフェの料理って多分今日そうだと思うのでちゃんとアレルギー物質って書いてるじゃないですかアレルゲンって書いてるんであれはアレルギー持ってる人に対して提供してないよっていう意思表示これもしたった一つのアクターに責務を負ってない単一責任じゃない場合どうなるかっていうと
-
なんか今日どうやらエビアレルギーのお客様が来るのでエビチリ廃止しますとかエビの寿司廃止しますとかこれをやらなきゃいけないこれって超大変でまず予約段階でアレルギーの有無を聞かれますお客さんはめんどくさいなおかつそのお客さんが来た瞬間他のお客さんがエビチリ食べれなくなります
-
そしてオペレーションをバタバタしますそんなの良くないですなので単一の一人のアクターにのみ責任を負ってるからこそ保守しやすい運用もしやすいもしアレルギーのお客さんが来たらその人用のアレルギーに対応の料理出すのかもしくは
-
エビ入ってないやつ食べてねっていう風になるわけなんでこのようにしてビュッフェでいうと単一責任が守られているとビュッフェの各料理が単一責任になっているみたいなイメージですかそうですね各料理だからエビチリでいうとエビアレルギー小麦粉エビチリに含まれるアレルギーを持ってないお客様にのみ提供されているなるほどあと社食も違いますよね
-
社食というか従業員用のご飯従業員用のご飯もビュッフェの責任になっている場合例えばないと思うんですけど従業員は食中毒対策で牡蠣料理食べちゃダメってなった瞬間ビュッフェの料理から牡蠣を消さなきゃいけないとかそういうめんどくさいオペレーションが発生するのでこんな感じで変更理由がたくさんあるとそれを変更しなきゃいけない機会も増えますし
-
影響範囲も広がるっていうので一つに提供できるようにしましょうっていうのが単一責任の原則ですねなるほどはいはいはいちょっと喋りすぎたんでだんだんちょっとペース上げていくとはいはいオープンクローズドの原則オープンクローズドの原則すごいなホットアイスクリームみたいなオープンクローズドホットアイスクリームまあなんかそういうことか逆にしてる感じそうですねオープンクローズドこれもねちょっと分かりづらいところではあると思うんですけどどういうことかっていうと
-
既存のコードを変更するのではなく新しいコードを追加することでシステムを変更できるように設計すべきということですなるほどこれも分かりづらくてですねソフトウェアの振る舞いは何でしょうなんか追加しようと思った時に既存の部分を変更しないで追加するだけで拡張できるようにするうんうんうんでビュッフェで言うと何なのかと
-
ビュッフェで言うと新しい料理を追加するときに既存のキッチン設備とか材料の調達プロセスに影響を与えない料理を追加できることカレーライスとうどんをもともと提供しててカレーだけうどんにぶち込めばカレーうどんできるじゃんみたいなちょっと違いますね例えばですよ原則に反しているとどうなるかというとお寿司ですね
-
新しくちょっとお寿司出したいぞとうち海沿いなんで今までなかったけど海沿い意味あったんだなので寿司さばけるようにするために設備が必要だけどちょっとなんか魚さばけるまな板置く場所ねえわってなっちゃうと今の設備壊さないといけませんと大胆そうじゃなくてもともと壊さなくてもいいように最初から設計しておきましょうねとそうすると寿司にできたりもしますし
-
そうですね新しくマグロをさばかなきゃいけなくなってもどうにかなると今のこの法則は料理じゃなくてキッチンの設備の話をしているそうですねキッチンの設備の話をしていますあとは何でしょうねお寿司例えばお寿司だとしても寿司用の米を炊くために炊飯器の設備を変えなきゃいけないっていうのはオープンクローズドに反していて米はそのままで
-
シャリさえ買ってシャリじゃねえやネタさえ買ってくれば握るだけみたいなそういう風な設計にしておくべきというのがこのオープンクローズドです元々あるやつを変えなくても新しいものができるようにやる逆に言うと変更するときに元々あるやつ変えるなってことですこれはむずそうこんな気がしているあれじゃないですかむしろ料理を変えるぞってなったときにキッチン設備変えるんじゃなくて新しい道具買ってきて作り直すみたいなそういうことかまさしくそうです
-
だからよしこれから寿司作るぞって寿司切り台みたいな謎の機械を導入するってなったらスペース足りないって元々あった部分をぶち壊して変えなきゃいけないけど普通にまな板と包丁買ってくればよくねみたいなことなのかななるほどそうすればただのアドオンしたものだけで新しい機能ができそれで寿司が作れるということですかねそうです
-
なるほどなコードで考えた時これめっちゃむずいんじゃないかって思っちゃったんですけどむずいポイントちょっとちょうだい昨日俺の頭の中では今結構ファンクションなんですけどファンクションを毎回別の料理作りたいってなった時に新しいファンクションを追加するっていうのは分かるんですが元々あるファンクションを
-
条件分岐とかで修正するっていう方が現場では多いのかなっていう気がしてっていうのでこのOを適用するの結構むずいなっていう印象を受けてます今じゅんぺいが言ってたのはあるのかもしれないけどもし
-
さっき分岐させるって話があったけど分岐することによって最初の単一責任の原則に反してないならそれでもいいかもしれないですねそれは条件分岐を足してるだけだから基礎に影響出ないなるほどけどそれで結果として最初の単一責任に違反するんだったら分けるべきですねっていうことが多分行われてるはずなるほど今回あれかソリッドを総合的に見てうん
-
それをするかしないかっていう判断そうそうそうそうもちろんそうですだから本当にオジェクト思考言語でコードを書く人は新しく機能を追加したりコードを変更したりするときにビュッフェ思い出してもらってこれビュッフェじゃいけてないわってなったらダメですしねなるほどなるほどねこれだとビュッフェビュッフェ犯してるなみたいなそうですそうですわかりましたはいありがとうございますはい
-
次あたりからねちょっと僕はだんだん分かりづらくなってくんじゃないかなと思ってるんですけど3つ目リスコフの痴漢原則ですね出た
-
これちょっとすみません 僕リスコフさんっていうのを知らないんですけどこれちょっとリスコフにすることによって ソリッドにしたんじゃないかと睨んでます 深井:本当は違う人だったのかな? 深井:はい 本当に人いた中でリスコフさんだったらLだわってなったんですよね 深井:あーそうなんだ 深井:はいすみませんこれは嘘ですよ適当なこと言ってるんで 深井:リワンコフだった可能性あるってことね 深井:ありますありますダニエルかもしれないですね 深井:ダニエルのそこもいいんだ
-
これは何かというと交換可能なパーツを使ってソフトウェアを構築するならばその個々のパーツは交換可能になるようにしなきゃいけないというのでもうちょっと具体的なことを言うと親クラス子クラスありますけどもなんて言えばいいんだろうな親クラスと子クラスの動作はある程度互換性があるようにしましょうねっていうことかなと思ってます交換可能になるように作らなきゃいけないっていうので
-
ただクラスの話だと分かりづらいんでやっぱりちょっとここビュッフェ落とし込んでいくんですけどシーフードカレーはいシーフードですねシーフードカレーシーフードカレーをちょっと思い浮かべていただいてですねシーフードカレーってカレー継承してるんですよ
-
してますね カレー系としてシーフードカレーになってるんですけど これはリスコフの痴漢原則に従ってやっぱやられててビュッフェでやっぱシーフードカレー美味しいんでね 順平がいっぱい取っていくわけですよめちゃくちゃ食いますね そうだよね 売り切れましたとシーフードカレーないと シーフードもないってなった時にカレーで大体できるんですよ
-
鍋置き場の鍋とあと周りのカレーライスのライスとの組み合わせて食うっていう動作に関しては 時間できるじゃないですかあーはいはい 動作に関してはそうそうそうそうあのシーフードカレーじゃないじゃないかってブチ切るやつがいるかもしれないですけどまぁでもその料理に穴を開けずに円滑にビュッフェを回していくという観点では互換性があると確かにこれあのカレーから発生してるカレーパン
-
これはね、リスコフの痴漢原則に違反してるんですね確かにあのカレーコーナーにシーフードカレーコーナーにカレーパン置きますとまずカレーライスの鍋は多分お湯の上に浮かんでるんでカレーパンがビチャビチャになりますと
-
サラもなくなるんだカレーパンそうかカレーパン用の鍋かでもあれだよカレーパンの横に炊飯器があるっていう謎の状況にはなるよねそうですねこれで飯食えってばいいのかっていうやつが出てきますからそうそうそうそうそういうカレーとカレーパンみたいな継承は良くないですねなるほどちゃんとその互換性のあるというかリスクオフの時間原則にのっとっているようにうんうん
-
なるほどね じゃあクラムチャウダーとシチューはいけますかクラムチャウダーとシチューうわーこれ戦争ですねこれ戦争なんですかシチューでご飯食えるか食えないか戦争じゃないですかクラムチャウダーはいけるんだご飯クラムチャウダーはご飯いけないだろどっちもご飯ないと思ってました僕も
-
僕はどっちでもいけるんですけど 僕もそうなんですけど一般 スラムジャウダーは有無を癒さずダメだろコメンダメ? 怒ってる怒ってるそうなんだ わかんないけど 怒ってたかいちさんギリギリ人によって違いそうだななのでカレーパン作る時は継承しないんですねおそらく
-
確かにあれはコンポジションだなそうコンポジションですよねコンポジションっていうのは何て言えばいいんでしょうね注入するんですねコンストラクターでカレーぶち込むんですねパンにカレーを持たせてるそうそうそうそうこういう判断基準だと何を継承させるべきかとかは判断できるかもしれないですね確かになるほどなるほどっていうのがリスコフの力の原則シークドカレーのカレーを思い出してくださいって感じですはいはいありがとうございます4つ目インターフェース分離の原則です出た
-
これはですねソフトウェア設計する際に使ってないものへの依存は回避すべきだという原則ですとこれは今使ってないものへの依存を回避すべきだという原則という話をしましたがどういうことかとまずですねオブジェクト思考言語ではインターフェースというのがありますとこれは普通に
-
メソッドを呼び出す例えばちょっといきなりビュッフェに行っちゃうんですけどお寿司を作るのを想像しましょうかお寿司多分握り寿司クラスがあって握り寿司.createお魚米包丁とかを引きずに入れてクリエイトするわけなんですけどこの時って握り寿司はお魚米包丁に依存してますねないと作れないからないと作れない
-
この時にですよ例えば包丁包丁に依存してますとこの包丁はいろんな包丁あるじゃないですかフルーツナイフ肉切り包丁中華包丁
-
まあとかとかでこういうなんかいろんな包丁がある系のやつについては包丁インターフェースっていうのはなんか包丁類をまるっと呼び出せるみたいな仕組みを使って呼び出すインターフェースっていうのがあるんですけどもそのインターフェースをうまく分けましょうねって話ですねで具体的にどう分けるかというとですねはいさっきの包丁の話で言うとこれはただ包丁クラスだと良くないんですねうん
-
なぜならJavaという言語についてなんですけどこれはもう別の言語はもはやインターフェース分離しなくていいんじゃないかとちょっと思ったりするんですがJavaにおいては依存している包丁クラスに変更があったら毎度コンパイルしなきゃいけないっていう制限があるんですねなので例えばただただお寿司作って
-
今のところ何も問題ないし今度の春のメニュー改定でも寿司に関連するメニュー改定ないから変更しなくていいやって思ってたら豚さばきショーが追加されることになって
-
豚さばきショーショーってどのショー解体ショーのショーそういうことかキングダムかと思いましたどでか中華包丁が包丁クラスに入りましたとそうするとですね包丁クラスじゃなくて包丁インターンですかにどでか中華包丁が追加されたことによって包丁クラスに依存している寿司も再コンパニーしなきゃいけないんですねイギリス寿司もほう
-
それで無駄に依存しちゃってるので刺身膨張インターフェースに依存するようにしましょうねというのがこのインターフェース分離の原則ですねなるほどね雑に書くんじゃねえぞっていうのが言いたいことなのかなと思ってますなるほどね意味が分かりましたクラスについてはインターフェースに依存することはあると思うんですけどインターフェースの先に使ってないものはないようにしようねっていう
-
ところですねどでか中華包丁はすいませんがなんかマグロよりでかい魚を捌くときに必要なのかもしれませんが遠くいらないと思うのでマグロのあれじゃないあのもうノコギリじゃないなんかありますよねほぼ刀みたいなやつですよねそうなんだめっちゃでかい骨切るときノコギリですねなんかもうさ
-
机に設置されてるさ電動のノコギリでシャーンシャーンって切ってるイメージあるわ冷凍のマグロそれは市場ですね市場かわかるわかるはいつのでそのインターフェース分離の原則は包丁クラス包丁インターフェースじゃなくて刺身包丁インターフェースに依存しましょうねという話でしたなるほどねインターフェースめっちゃ増えそう増えそうですねねまあでもビュッフェなんてね超エンタープライズシステムなんで
-
ある程度した話ですねそうねうわーこれ自信ないないやあの包丁となんだっけ出刃包丁みたいなやつはい
-
みたいな行動があってこれを一つにするべきかしないべきかって悩んだ時に分離させるのかそれとも共通部分多いよなって思うのかそこの判断なんかちゃんとできる自信ないわ難しいですよね本当にそこはアクターで考えるんでしょうねでも難しいところですよねこれでも全く同じやつ2個になってるぞでもそれでも正解のケースありますもんねアクターが2人だったら
-
そういうことか日本食料理長と中華料理長の長をつけなくていいわ日本食料理職人とかそのアクターによって変わるってことかそうですそうですだからそのビュッフェって一つのシステムに見えて別にそうじゃないですからね多分厨房もね分かれてるでしょうし冷蔵庫もねそれぞれ持ってるでしょうからそういった形で多分その
-
普段接してるシステムも一つに見えるけど裏っかは全然別とかはあるのでいかにねそうやって無駄にまとめないかが大事ですね確かに分かれてました分かれてました?あービュッフェの話?ビュッフェの裏側の話リアルな話で養殖のゾーンみたいなリゾートバイト中華のゾーンすごいちゃんとねだから作るときですよビュッフェだったら分かれてるかこれを基準にちょっとインターフェースとか考えてみるといいんじゃないかなと思いますうーん
-
最後これも分かりづらいんですが依存関係逆転の原則ですこれビッフェでやるのむずいぞこれディペンデンシーなんですかリレーションインバージョンじゃないですかディペンデンシーバージョンインバージョンプリンシポありがとうございます逆転しちゃうんですか逆転の原則ですこれはですねよく言われる説明だと上位レベルのコードは下位レベルの詳細の実装コードに依存するべきではなく
-
詳細側が方針に依存すべきだという原則ですはい意味が分かりませんとそうね特に普通に上位レベル下位レベルってやつねはいさっき言った握り寿司と包丁の話ですけどはい呼び出す側が依存するやんとどう考えてもうん
-
どう考えても呼び出す側が依存してますと呼び出す側握り寿司側が包丁に依存してるって話しましたよねはいはいはい呼び出す側というか呼び出す側親?上側?はいはいはい上側が下側に依存するのが普通なんですけどそれを逆転させろよっていう原則ですで具体的にどういうことかとはいまあビュッフェでいくんですけどもはいさっきのお魚と寿司の話そのまんまいきますでまあ寿司ってお魚と
-
米でできるじゃないですかさっきの握り寿司.createでもお魚ぶち込んでますとこれは今寿司例えばマグロのお寿司で考えると寿司はマグロに依存してるんですねだってマグロなくなったらマグロの寿司じゃなくなりますしねこれは良くないと寿司がマグロに依存してない状態じゃあどういうことかと言いますとですねこれはちょっとさっきちょろっと話しちゃったんですけどお魚に依存させるんですねマグロじゃなくておおおおおお
-
どういうことかというと従来のこの依存性逆転の原則に反しているやつだと握り寿司.createマグロなんですよコードでそうやって書いてるとこれマグロうわ今日マグロ取らんかった酒しかねーって時にコードを書き換えて再コンパイルしなきゃいけないんですけどなるほどね魚が変わると寿司を再コンパイルしなきゃいけないんだそうですそうですこれを
-
握り寿司.createをお魚にしますそうするとマグロに依存してないですねお魚に依存するんです逆にマグロの気持ちになってくださいマグロはお魚に依存するようになるんですよというとインターフェースJavaとかオジェクト思考を触ってない人はあんまり馴染みないかもしれないんですけどインターフェースってどういうものかっていうと今回の例でいうとお魚骨に違う
-
骨、身、スウィムスウィム、そうですねお魚、そうですねお魚のメソッドを定義しているテンプレみたいなやつなんですけどインターフェースでで、マグロは具体的に言うとねお腹、お腹じゃない、なんて言いましたっけ身、身、身、身、マグロが一番ややこしいですねすいません、サバにしますサバの身
-
サバの身じゃないですかサバの身その言い方初めてしたけど木の身みたいになっちゃったマグロの部位を考慮しすぎたってことですかマグロの部位ややこしいねサーモンもね身じゃないですか多分全部同じ寿司に使いますよ上から下までうんうん
-
っていう感じでその魚ってこういう感じだよねっていうのが定義されているのがインターフェースでそれに沿った形でお魚も定義されるんですね身を寿司に使いますから骨は使ったりしませんからまあマグロはややこしいんでちょっとなかったことにしてなるほどね大トロと中トロがあるからかそうです大トロとか中トロとかが出てきちゃうなるほどね混ざったなと思ったんですけどうん
-
ここにもでも一つ判断の難しさありますよねお魚は共通にできるけど包丁は別々に分けてるみたいな不思議さというかやっぱアクターが違うんですねなるほどねそのヤバボーチャーは別のアクターがいるからってことかそうですしその魚もマグロだから寿司用の魚クラスなんでしょうね生食分野のお魚クラスなんでしょうね多分刺身には使いたいんですよきっとなるほどね
-
生で食えるフィッシュクラスってことね生で食えるフィッシュクラスになるんで生で食えるフィッシュクラスを炙るんでしょうね炙り寿司にする場合はねこういう風に定義してますとこれ今骨とか身とかって言ってましたけどタコとか来た時もどうすんねんって感じじゃないですか確かにタコはタコでその
-
生で食えるお魚インターフェースに沿って定義するんですねタコもそっちに行くんですねタコ.meにやると切り身が出てくるような感じでタコさんを実装するとさっき最初に言ってた握り寿司.createでタコぶち込んでも同じ感じで作れるとなるほどゲットボディメソッド呼べばいいんだゲットボディってそっちねいいですねゲットボディいいですね
-
タコゲットボディでタコの切り身が取れるタコのボディどこなんだっていう妄想ありますけどねヘッドはフットなんじゃないかっていうレッグなのかっていうでもそこは抽象化してていいんじゃないですかレッグないですから他の魚にね確かにボディでいいですね
-
っていう形でインターフェースをかませることによってあの末端のそのタコのタコというかお魚のネタ変わった時でも握り寿司側を変更しないで良くなる変更に強いコードが作れますよっていうのが依存関係逆転の原則ですなるほどねなんか今こう設計のこう妙というかなんてんだろう
-
こういうの考えるようなってめっちゃ今思ったのがあるんですけどじゃあ卵追加するときどうしようとかって現場で議論になりそうだなってめっちゃ思ってたこれはこれはでもすごいですね卵を多分どうしよう
-
なんかやりようによっては生で食えるお魚インターフェースにぶち込むのがまず一つでしょ僕はもうそれですねそうじゃなかったらでも卵は卵以外の多分なんかきゅうりじゃなくて他にもあるじゃないですかそういう色物系あるねきゅうりでいいんじゃないきゅうりの寿司ってあります?え?あーそうか握り寿司なのか握り寿司で握り寿司なのかやっぱハンバーグじゃないですかあそうそういいハンバーグいい多分そっちになるんでしょうねうーん
-
生で食えるお魚じゃない握るタイプのおかずクラスインターフェスか握るタイプのおかずインターフェス作ってそこでは絶対クリエイトとかカットじゃないなプット確かにプットボディオンライスボディシャリなんじゃないさすがにシャリかそっちの方がいいわ
-
いいですね卵そういうのいいですね卵とかあとあれサーモンはサーモンなんだけど上にオニオンスライスとなんかこってりしたマヨネーズみたいなのってあるやつとかとかねまあそうですねだからたぶん握り寿司.createの任意の引数の中にたぶんオプションみたいなやつがあるんでしょうねなくても大丈夫ねあーなるほどね今回ポイントなのが握り寿司.createなんですよね
-
今回巻き寿司と分けてますクラス握り寿司か確かに巻き寿司は多分違うなと思って作り方しかもあれだねオニオン乗せるってなったらそこオープンクローズドの原則でオニオンぶち込めそうな気もしてきたなんか
-
ちょっともう少しお願いしますもう少しお願いします上に具乗ってるトレートみたいなやつをミックスインすればいける気がしてきたなそのノーマルサーモンの寿司から生やすというかそうそうそうそうオニオントレートをミックスインしていくみたいな
-
なんか料理って全部そうなのかもしれないですねもはやそうなんなら今回のビュッフェほとんど寿司しか出てきてないカレーと寿司全部魚に絡めましたねすごいなビュッフェじゃなくてもいいんですよねまさかこんな海沿いが海沿いに来ましたねはいマジで多分ラーメン屋とかでも良かったんじゃないかっていう説ありますいやでも確かにラーメン設計しがいあるなラーメンはねいいと思いますよかなりねえ
-
なんかその一見まあラーメンもそうですけどまあだからマックとかすごいんですよ多分あいつら多分すんごい限られた材料ですっごいレパートリーのメニュー出してるんで確かにマクドナルドのオブジェクト思考面白そうだなおもろいね詳しくないから勉強用教材勉強用教材でソリッドマクドナルドマクドナルドのマクドナルドを作るっていうチュートリアル
-
いいねでもキャッチだしそういうのありだよななるほどちょっと次マックかもしれないですね新商突入でもマック詳しくないんだよなノリさんはビュッフェやってたってちょっと関わってたって強みあるじゃんちょっと関わってた俺デリバリーピザだからそれでもいいかそうだねほぼマックだしなデリバリーピザならいけるかも
-
弟者あとラーメンもいけるよ弟者お、強い 兄者すげえ弟者ラーメン屋で働いてたから兄者飲食店ないなぁ弟者ないんだ 兄者ないっすね
-
というので ちょっと掴みどころのなかったソリッド原則の解像度が1ミリぐらい上がると嬉しいなと思ってますでも全部これにのっとってる必要があるっていうよりはこれを現場の事情と勘案していい感じに意識しつつなるべくクリーンな感じにしていくっていうイメージなんですよね本当に気を付けてもらいたいのはそうですね 例えばですけどリスコフの痴漢原則の説明をするときにカレーとシーフードをカレーの話をするのはやめてください
-
そうだね心に留めてください意味わかんないやつだと思われる現場ではそうですねこういう例えをするとねリスクはなんだっけカレーのやつっていうぐらいの解像度しか残んない時あるからはいぜひ聞き返しながらお願いしますビューフェンに例えてほしいお題こちらも募集してますのでそうですね期待せずに送ってもらえるとみんなの考えたビューフェンみたいな
-
そこまで考えてもらったのを送ってもらったことかでもなんか別にこれを説明してくださいでもいいですお便りであってもいいかもね質問とご意見とビュッフェなんだっけネタ職人じゃなくてハガキ職人みたいなことっすねそうそうそうそうビュッフェで例えましたっていうコーナービュッフェで例えましたっていうコーナーですね狭いんだよなはい時間ぼちぼちいってるんで終わろうかな
-
お手入れします?ちょっとどのくらいのボリュームなのかが想像ついてないですねへぇ
-
行かないといけませんでは最後にハッシュタグひまじんプログラマーでSNSのXでフィードバック募集してますのでお願いいたします僕の私のビュッフェをぜひ書いてくださいビュッフェで働いてたようなども募集してますいらねえあとは説明欄からGoogleフォームにお便り質問を募集してますこちらもお気軽にお願いいたしますこちらでもビュッフェ募集中なんでこちらでも働いてた情報ください欲しくなってきたあとは
-
ポッドキャストのプラットフォームの高評価フォローお待ちしてます毎週聞いてるというか2週間3週間連続で聞いてるという方そろそろフォローお願いいたしますお願いします本当僕ら今年ミシュラン狙ってるんでね高評価もお願いしますそれではまた次回のビッフェあるかないかまた次回バイバイ
-
やめて!ラーのバグ侵入の特殊能力でマスターザブランチが焼き払われたら闇のスパゲティコードと密結合しているじゅんぺうちの心までクラッシュしちゃうお願い死なないでじゅんぺうちあんたがここでクラッシュしたら戦法との契約はどうなっちゃうの?ソースコードはまだ修正の余地があるここを耐えればコードを納品できるんだから次回納期間に合わずデバッグスタンバイ
#218 SOLID原則のわかりづらい部分をビュッフェで理解する