オブジェクト指向でなぜつくるのか

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向という言葉はプログラミングをやっている人で知らない人はいないと思いますが、これを使いこなせているかどうかは別でのようです。
プログラミング初心者なら、はっきり言って使わなくてもよいと思います。
しかし、プロのプログラマーでも(私の観測範囲の中で)その認識は色々であるように思います。classをごりごり作っていくのがオブジェクト指向と思いがちですが、classを作らなくても関数化によって再利用性を高めたプログラミングもオブジェクト指向と呼んでいて、私もそれでいいと思っています。
少なくとも、関数化するということはそれによってスコープの限定が出来るので、デバッグもしやすくなります。

note.mu

この記事でも書かれていますが、オブジェクト指向のプログラミングの一つの要素であるカプセル化(スコープの外から見えるものを限定する)やポリモーフィズム(引数や戻り値の型を共通化する)は上手く使えば、読みやすいもしくは簡潔なプログラムが書けます。これは大きなメリットです。しかしオブジェクト指向とは必ずしも関係ないらしいです。

ところでカプセル化とかポリモーフィズムってどーなんよ？あれはわりと大きいメリットじゃねーの？
あの辺は大事なんだけども、実はオブジェクト指向そこまで関係なくて、わりと一般的なプログラミング概念なんで

オブジェクト指向の書籍ですがUMLについても大きくページが割かれています。

UMLは言葉は知らなくても、そのシステムの概要や動作を説明するときに役に立ちます。UMLについては特に勉強したわけではありませんが、感覚的に動作や関係性を表現しようとすると、UMLに近いものになっていたりします。
例えばエアコンパイの図はコミュニケーション図になります。

s51517765.hatenadiary.jp

似たような図に状態遷移図がありますが、状態遷移図は一つのオブジェクトの状態変化を表しています。
例えば、自動水やり機の土壌抵抗検出結果のGreen → Yellow →Red →Greenのようなものです。
s51517765.hatenadiary.jp

UMLには13種類の図があります。

統一モデリング言語 - Wikipedia

すべてを使う必要は必ずしもないですが、こういったものがあることを知っておくと、ブログでシステムの説明をするときに適切な図を選択することが出来ます。適切な図を選択できれば、その図を描くときの着目点も調べやすいです。個人でブログに書いている分には図の多少の使い方間違いも気にする必要もないし「伝わればいい」という割りきりで書くことが出来ます。
名前と使い方が一致していなくても、図をみればなんとなくどのような場面で使うものか分かると思います。

オブジェクト指向またはオブジェクト指向ぽいプログラミングをすると、関数と関数、もしくは変数との関係が複雑なプログラムが書けます。これを図で説明するものがUMLです。

まとめ

「オブジェクト指向でなぜつくるのか」という書籍から入って、オブジェクト指向をどのように使うべきか？という観点でまとめました。
qiita.com
依存関係ぐるぐるで結局書けない、というのがたまにあるんだよな。引数と返り値が悪いんだろうけど。

※アイコン変えました