クラス設計 まずはやってみよう
あいさつ
どうも、はかせです。
今回はいつもとちょっと趣向を変えて
クラス設計の話です。
設計の話といっても抽象化~とか
依存性が~とかいう難しそうなことはしません。
あくまで設計をやったことない人向けに
設計やろうぜ
設計そんなむずくないよ
ていうのを言いたいだけの記事です。
なぜ設計しないのか
むやみやたらに設計っていいものだからみんなやろうよ!
なんて言ってもおそらく今までやってこなかった人は設計やらないです。
それで返答が大体
「設計なんてしなくてもプログラムは組めるじゃん。」
「設計って難しそうだし僕には無理かな。」
こんな感じだと思います。
確かに設計しなくてもプログラムは組めますし、
設計が誰にでも簡単にマスターできるタスクだとは思いません。
ただ設計するとメリットありますし、
簡単とはいいませんが思ってるほど設計は難しくないですよ。
設計のメリット
メリットの多くはチーム開発の時に発揮されます。
ただおそらく設計をしてこなかった人の大多数は
個人開発ばかりしてきた人だと思うので
今回は個人開発でも得られるメリットについて書きます。
コードの可読性があがる
読みやすいコードは自分も自分以外もみんなハッピーになります。
個人開発でも後々のメンテだったりアプデだったりでコード読むわけですから
大事ですよね。
では簡単に例を出してみます。
例えばこんなコードがあったとします。
class GodClass { void GameManagement() { //全体管理 } void PlayerManagement() { //プレイヤー管理 } void EnemyManagement() { //敵管理 } void InputManagement() { //入力管理 } /* 以降も何かの管理メソッドが並ぶ 大体行数として5000ぐらい */ }
さてまずこのGodClassは何するクラスなのかわかりますか?
ゲームの全体管理かと思えばプレイヤー管理してるし
敵も管理してるししまいには入力まで管理してる上
まだまだ何かを管理しているようです。
プレイヤー管理を弄るときはこのクラスを弄るんでしょうけど
じゃあこのクラスのどこを弄ればいいんでしょうね?
おそらくPlayerManagementの部分だと思いますけど
もしかしたら内部的に他のメソッドや変数とかとつながってるかもしれません。
ここを弄ったらそれが他のものとつながってないか
そして変更の影響が必要以上に広範囲になってないか
全てコードを見て判断するしかありません。
大体5000行くらいもあるコードの中から
PlayerManagementに関わるものを全て探し修正する必要があります。
1つでも漏れていたらそこが原因でバグになります。
つらいですよね?
では設計してみますか。
ざっくり簡単に設計して
コードに起こして
class GameManager { //ゲーム全体の管理 } class PlayerManager { //プレイヤーの管理 } class EnemyManager { //敵の管理 } class InputManager { //入力管理 } class SomethingManager { //さっきのやつで省略したやつ }
大分わかりやすくなったんじゃないでしょうか。
プレイヤー管理を弄りたければPlayerManagerというクラスを弄ればよさそうです。
設計図見てもPlayerManagerは他のクラスに影響は与えていなさそうなので
わざわざ他クラスのコードを見る必要もありません。
処理が追いやすい
ものすごい簡単な図です。
客が店で買うだけです。
ただこの図をみるだけでこの関係性がわかりましたよね。
一目で処理がわかるってけっこうでかいですよ。
設計むずかしい?
今回設計のメリットを超絶ざっくり伝えるために
超絶ざっくりとした設計をしてみましたけど
そんな難しそうに見えました?
そりゃ突き詰めれば変更に強くするために抽象化してとかありますけど、
設計初心者がやることじゃないので頭から一旦ぽいして大丈夫です。
しかも今回はパソコンで作りましたけど
意味さえ伝われば手書きでやってもいいわけです。
やり始めるのそんな難しいですか?
あとがき
今回は設計を超絶ざっくりやってみました。
細かいこと言えばもっとありますが、
やったことない人がやるならこのくらいでもいいと思います。
とりあえず難しく考えず
メソッド分割してそれを図にするところからでも始めてみませんか?
それでは今回はこの辺でノシ