マリオで学ぶSOLID原則

はじめに 最近オブジェクト指向とデザインパターンについて学び始めたので、勉強しつつ記事にまとめていきたいと思います。 初回はSOLID原則についてです。SOLID原則はオブジェクト指向プログラミングにおいて、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくするために考えられたルールです。 この記事では、オブジェクト指向プログラミングの重要な開発原則であるSOLID原則について皆さんが想像しやすいマリオのクラス実装を例に解説していきます。 1. S (Single Responsibility)：単一責任の原則 クラスは単一の責任を持つべきと言う原則です。 ここでの責任というのは、オブジェクトが持っている機能のことです。 一つのクラスができる機能（責任）が複数あると、クラス内部の関数が強い結合を起こす可能性が高ま理望ましくありません。 次のマリオクラスを見てみましょう。

[hasiduki]

明日ここに来てください！！！！！SOLIDを1ミリも守らないグッドコードをお見せしますよ！！！！！！！！誰かがね！！！！！

[versatile]

OOPちゃんと知ってる人が書くと、たいていこう書ける。でもろくに知らない人が書くと「こっちのほうが短くなる」とか意味不明なことを言いながらメンテ不能なコードを量産してしまう。

[chikoshoot]

”interface FireAction” の定義が間違っているね。 / 修正されたそうです。

[yimajo]

単一責任原則についても依存関係逆転の原則についても間違えている。厳密には書かれてるような単純なことじゃない。自分の知ってる範囲で理解しようとしてしまうんだろう。

[naoya2k]

CoinManagerって出てきた時点で「あ、こいつドメイン知識ない人だ。要注意」って思っちゃうのでそこは注意したほうがいいと思いました。Jumpは特殊なキャラをつくるたびに親クラスをいじらないといけなくなる予感がする

[yamadadadada2]

山岡と雄山のスパゲッティコード対決見てみたい。/ 「このモジュールを作ったのは誰だあっ！！」

[nunulk]

SRP について誤解があると思う https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

[sa-yama321]

オブジェクト指向にとらわれている人をみると、かわいそうになる。こんな原則、実務ではたいして役に立たないのに。

[pmint]

なんだこれ…説明に都合いいようにでっち上げられたコードじゃん…依存性逆転なんか何が逆転したのやら。オブジェクト指向本によくある差分プログラミング（共通化）でしょ。改善前も有用なコードじゃないとダメ。

[kat21]

SOLID原則が役に立たないとかいうkusoブコメはとりあえず置いておいて、アウトプット素晴らしいです。色々教えたいw

[a-kuma3]

「依存性の逆転」は命名が悪いと思ってる。何に対してのInversionかをイメージできてないとOOに囚われてるみたいになる／"D"は、マリオで例えるなら「ヨッシーは空中でジャンプできる」の方が適切な気がする

[turanukimaru]

FCの頃のコインはマリオとルイージで別だったような気がするが今は共通なんだっけ？まぁManagerという単語を見て反応する（でも正しい言葉は言わない）人が沸くので共通の財布 joint purse が良いと思うよ。

[nghrk]

super("Mario")て書きたかっただけ説

[onesplat]

出たManager

[yarumato]

“獲得コイン集計機能をMarioクラスが持つのは適切ではない。Luigiクラスでも使うから。多すぎる責任を持っている（単一責任の原則に反している）”　　←なんか違うぞ。ブコメだとまちがいなのか

[queeuq]

マリオとルイージのコインは別物ではないか？（たいしてコードは読んでない）

[momonga_dash]

“super("mario");”／これ言いたかっただけど違うか？

[sansansanba]

constructor() { super("Mario"); ここ好き

[tomaho]

みんな優しいな。ルールを盲目的に適用するとかえって見通しが悪くなることがあるよね。このあたりは個々の世界の捉え方と関わってくる気がしている。

[ghostbass]

マリオそのものは各種アクションの複合オブジェクトになるからSRPもなにもないんじゃないか、って気がする

[tattyu]

マリオクラスがコインを持っている、という構造ならマリオクラスにウォレットクラスを持たせる方が綺麗じゃない？。分離すると逆にコード追いづらくなる。

[marshi]

oopにとらわれる必要はないけどoopで実務してるなら役に立つ場面多数あるし知っておいて損はない。

[tk_musik]

Single Responsibility(単一責任コイン管理は外出し)、Open-Closed(ピーチ追加でも既存触らない)、Liskov Substitution(親クラスを子クラスに入れ替えても動くヨッシー)、Interface Segregation(不要なIFはなし、ファイヤは別IF)、Dependency Inversion