Notices by りこ🍥 (lycolia@ukadon.shillest.net)

@lacherir なんとなく頭に浮かんだワードだよ。EXPRESSとESPRESSOって似てるなとか

@lacherir SHINKANSEN SUPER ESPRESSO？

@ponapalt 先生、Devinと契約してニートになりたいッス！

@lacherir 太閤の湯自体もクーポンは通年で出してるけど、交通費で相殺されるぶんを考えると企画乗車券には到底叶わないショボさなのが不思議なんだ…

@lacherir 太閤の湯の企画乗車券ってのがあって、基本的に区間内電車乗り放題かつ太閤の湯のフルタイム入館ができるのだけど、価格が太閤の湯のフルタイム入館料と大体おんなじなんだ。

んで鉄道での往復を考えると利用者はそれだけで元が取れるケースも少なくないのだけど、そう考えた場合、太閤の湯の儲けはどこにあるん？もし、鉄道会社と折半してるとしたらどっちも赤字に見えるし…

@lacherir ただもし鉄道を利用しない場合であれば太閤の湯のクーポンのほうが安くはなるんだ。

問題は太閤の湯が交通アクセスの悪い山奥にあり、車で行くメリットが薄いとこだけども…

@lacherir 鉄道利用客だけがただただひたすらお得になる謎きっぷ…

ラーシェちゃんのモデ理由出るようになってるぽい〜？

@ponapalt わぁい！モデレーション祭りはっじまっるよー！

@ponapalt そんにゃ〜

@lacherir まぜこぜやなー

@lacherir 大和川より南は和歌山ってほんまなん？ということは大阪弁の発祥？となった河内弁は和歌山弁ってこと？大阪弁は実は和歌山弁だった…？

@lacherir 兵庫丼が重すぎるのでうかどんに避難していい？

私は大枠で考えるとMVCベースがよく、細部を見ると責務を分けた単一機能の関数を切りまくってそれを繋げていくのが良く、ある程度の変更に耐えられるように名前は極力抽象化した上でインターフェイス経由でDIするのが理想だと思ってるのだが、なかなか理解されない…ムズい。

ただここでぶつかるのがクラスの扱いをどうするかで、まだ答えが出せていない。OOPは終わったみたいな話もあり、それ自体は分からなくはないのだが、エンティティを論理的にまとめるには都合がいい存在なんよね…。（余りに疎にしすぎると何がなんだかわからなくなる）

答えの一つとしてDDDはあると思うけどあれは保守性がお通夜な気がしており…。

@lacherir 「何を」「どんな順序で」実行するかをオーケストレーションするのとメイン関数に「何を」「どんな順序で」実行するかを書くことの違いは？

@lacherir それはメイン関数の中で逐次的に関数を呼び出すことに対してどのような違いがあるの？

@lacherir では具体的な設計を考えてみよう
例えばWebサービスによくある新規登録画面を設計するよ
画面を表示しユーザーが内容を入力する。登録ボタンを押すと登録処理が実行され、問題なければ完了画面に遷移するとしよう。

さて、この時に画面は様々な処理を行うので単一の処理に収めることができない。

例えば登録ボタンが押されたとき、押下イベントのハンドリングと入力チェックとAPIへの送信、正常時の画面遷移、エラー時のエラー表示があるとしよう。

これらの処理をメインとなる関数にベターっと書くのは当然駄目だけど、各機能ごとに関数を切り分けて逐次呼び出すのは凝集度が低くなる要因になってしまう。

しかし凝集度を低くしてはならない。しかし処理は逐次的に行う必要がある。

ラーシェちゃんであれば、この二律背反をどう解消する？

@lacherir ラーシェちゃん
一般的なプログラム設計として凝集度を高くし、結合度を下げるアプローチが良いとされてるよね？

@lacherir オーケストレーターはどのように呼び出されるの？
オーケストレーターに指揮者はいないの？
どのように呼び出し順が正しく管理されるの？

@lacherir 東海道本線と山陽本線はなんで分けてあるの？東海道新幹線や山陽新幹線も別れてるよね？
あと国道一号線と国道二号線も