オブジェクト志向言語を使っていても、オブジェクト志向設計ができているとは限らない。

私の職業はプログラマです。
オブジェクト志向言語の経験は浅いのですが、復帰前後で、試行錯誤をさせてもらえる期間があり、
なんとなく、ようやくオブジェクト志向言語について、考え方の感覚がつかめてきました。

そこで思ったのは、オブジェクト志向言語を使うなら、オブジェクト志向的な設計をした方がいい、ということ。

よく新米プログラマが、アスキーアートと見まごうばかりの深いIF文を書いたり、
全部コミコミのながーーいonClickイベントメソッドを書いたりしますよね。
長くやってると、
「あー、ここ、関数分けた方がいいなぁ」
なんて分かってくる訳ですが、

同じように、オブジェクト志向言語に慣れてくると、
「これ1クラスにまとめた方がいいんじゃない？」
「共通の親クラスを作った方がいい、」
など、理解しやすくメンテや拡張がしやすくなるコツがわかってきます。

プログラミングを効率よく手戻りなく行うために、設計により思考を整理することが必要になります。
思考のポイントが、これまでの手続き型言語（関数志向とでもいうべき？）とオブジェクト志向言語では違うので、
設計手法や、それを書き表すための文書の内容も異なってきます。

その時、UMLなどのオブジェクト志向設計手法を使わずに、機能（関数）ごとに定義する設計方法を使って設計し、オブジェクト志向言語でプログラミングするという、不一致な状態で進めていくとどうなるかというと、
オブジェクト単位に直すために、もう一回データ構造やら処理の流れを整理しなおさなきゃいけなって、
設計が二度手間になります。

そうなるとまぁ、関数志向的な設計に引きずられて、手続き言語的に組むしかなくなって、オブジェクト志向言語の能力（便利なところ）を半分くらいしか引き出せなくなっちゃうんですよね。

そして、その設計に大きな影響を与えるのが、設計書のフォーマット！！

カプセル化など、書くべきことを書く欄がなかったり、「いや、そこまで書くの？？」という欄があったりと、
言語仕様とマッチしないことが多々あります。

書くことって、考えること、伝えることとリンクします。
そのため、書きづらいフォーマットは、誤解を招くなどの弊害があるんですよね(^^;;

もし、システム開発関係の会社さんや、IT部署の方が見ていらっしゃったら、
「開発言語と仕様書のフォーマットがマッチしているか？」
チェックしていただけると、下々のプログラマが救われるかも知れません。
よろしくお願いいたします_:(´ཀ`」∠):_

そういうのって、往々にしてCOBOLなど古〜い時代から使われていて、
フォーマットを決めているのが、その世代で現役だった上長が決めているので、なかなか「今は違う」が、分かってもらえないんですが……

書くことは考えることなので、
「俺、もう現場行かないし。」
という方にも、ぜひ聞きかじりくらいはして、知識のアップデートをお願いいたします。（自戒）

また、
「俺、Javaできるから、オブジェクト志向については分かってる。」
ってドヤってるプログラマの方でも、中には継承とか一切使っていない、
「手続き型言語を、そのまま移植しましたね？」
という、オブジェクト志向の考え方ができない方もいますので、もう一度UMLやデザインパターンあたりをかじってみると良いかと思います。（自戒）

考えること（設計）は、書くこと（プログラミング）に影響しますし、
書くこと（仕様書）は考えること（設計）に影響します。

JavaやC#など、オブジェクト志向言語がアプリケーション開発のメイン言語となって久しいです。
言語が新しくなっても、アタマが古いままでは使いこなせません。
オブジェクト志向言語を使うなら、オブジェクト志向設計で。
強くお勧めします。