クラス設計するときは親子関係を高さで意識する

私は一応プログラマです。しがないプログラマです。

プログラマの端くれなのでたまには本業の話を。

今までいろんな人（プログラマ）を見てきましたが、できる人ってあんまりいないイメージです。

できるっていうのはコーディングが速い人ではなく上手な人です。

（そういう私もできる人ではないほうの一人ですが。）

結構感じたのがオブジェクト指向を理解できていない、というかどう作ったらいいかがわからない人が多いのかなという印象です。

継承とか実装とか概念はわかるけど使い道がよくわからない、みたいな。

アラフォープログラマでもうまく作れない人が多い。

クラス設計を含めて任せたら「あぁ、こう作ったんか・・・」というパターンが多いです。

これはこの業界の形態というかあり方が原因でもあるかなと思います。

いわゆるSIerの会社ではプロジェクトの製造工程だけに出向という形で放り込まれることが多くて、ある程度形が出来上がったシステムにロジックだけを埋め込む作業が仕事になります。

他のクラス設計が必要な部分はすでに作られてあるので極端な話、担当する処理が一つのソースファイルで完結するようなものを量産するだけです。

出向する期間も3ヶ月とかで終わるので、そもそもシステム全体を考えて作る機会が非常に少ないといえます。

自分で勉強して何か作っている人なら身についてそうですが多くの人は努力をあまりしていません。

まぁそりゃそうですよね。疲れて家に帰ってから何かするのって精神的なエネルギーがいりますから。

それはさておき、ここでは私なりのクラスの考え方を載せてみます。

参考書とかに載っているように概念というものは一つかもしれませんが、イメージの仕方は一人一人違うと思っています。

自分なりのイメージの仕方を確立できればある程度のクラス設計はできるようになるのかなと思います。

（でも難しいんですよねクラス設計）

なお、できる人向けではありませんのであしからず。

クラス設計を任せるとよくある形

他の人にクラス設計も任せて作ってもらうと、大体出来上がるのが「親クラスに共通メソッド置いただけ」というものです。

安西先生「まるで成長していない・・・・・・」

クラスの利点を使えてないというものです。

継承する意味がないんですね。

正直に言います、昔の私がこれ(*ﾉωﾉ)

私なりのクラス設計の解釈

私の解釈ですがクラスというかオブジェクト指向の利点は「タテの共通化」にあると考えています。

タテというのはそのまま縦ですが、私は高さの「縦」を意識します。

あくまでイメージ的なものでタテは親クラス子クラス／親メソッド子メソッドの関係です。

いわゆる継承です。

逆にヨコはユーティリティクラスのような単純な共通メソッドの関係です。前述のよくある形はヨコの関係になります。

このタテを共通化できたら継承したクラスでは記述するメソッドを限定できます。

タテのイメージ

クラス図というものがありますが私はほとんど使ったことがありません。

（勉強不足ともいう）

多くの人はクラス設計する時にクラス図をイメージするのでしょうか？

これはわからないのですが私はクラス設計するときに紙のようなものをイメージします。

親クラスの紙をペロンと1枚置いた状態で、少し小さいサイズの子クラスの紙を重ね合わせるんです。

メソッドは紙にぼんやり乗っているイメージです。

で、重ね合わせた紙を上から眺めると子クラスを含んだ処理が見え始めます。

こんなかんじ。

子クラスを親クラスの上に重ねると、

子クラスのイメージができます。

緑部分が子クラスに実際に書いた処理です。

重ね合わせるイメージをすることで子クラス全体のイメージができます。

厳密にいえば紙ではないんですが私はとりあえずなにかを重ね合わせるイメージで親子クラスを考えています。

なんにせよ

実際にはこの親子クラスをどう呼ぶかの部分も非常に重要で難しいところですが、

親子クラスだけでも上手に作れている人をあまり見ないのでここで記載させていただきました。

イメージの仕方は人それぞれですので自分なりのイメージを確立することが大事かなと思います。