「オブジェクト指向」は万能じゃないよ！
「オブジェクト指向のメリット」はなんでしょう？
設計屋さんは「現実世界に近い設計ができること」と言うでしょう。
プログラマーは「インスタンス間が独立していて修正が簡単なこと」と言うでしょう。
前者は「オブジェクト指向分析設計」のメリットで、後者は「オブジェクト指向プログラミング」のメリットです。
ところが、この2つのメリットをごちゃまぜにして、「オブジェクト指向は素晴らしい！」と喧伝されるようになってしまいました。
これは、20世紀末までオブジェクト指向が使われておらず、そこからオブジェクト指向を使う方向へIT業界が大きく舵を切ったため、オブジェクト指向そのものメリットを強調しなければならなかった、という悲しい歴史が原因です。
オブジェクト指向はこれまでの考え方と全然違うため、「変わりたくない人達」を説得するために「オブジェクト指向はすごいよ！」と言ってきたわけです。
ただ、「オブジェクト指向○○」の「○○」が抜けてしまっていたため、「結局オブジェクト指向って意味分からん」という状況になってしまいました。
そういう経緯があるため、「オブジェクト指向」という言葉だけがどんどん広まり、でもどんなものなのか調べてみたけどよく分からない、ということになっているわけです。
「オブジェクト指向」との付き合い方
なので、まず「オブジェクト指向」という言葉は忘れてください。
次に、「オブジェクト指向プログラミング」や「オブジェクト指向分析設計」を個別に勉強しましょう。
勉強した上で、便利な道具として使ってください。
「オブジェクト指向プログラミング」も「オブジェクト指向分析設計」も万能なアイテムではありません。状況によって使える部分、使えない部分があります。それらをうまく活かして使うようにしましょう。
また、本や会話の中で「オブジェクト指向」という言葉が出てきたら、どちらの意味か考えるようにしましょう。著者や話者が「どっち側か」が分かるとより理解しやすいかもしれません。
これから学ぶべきこと
正直、本コンテンツの内容を理解できていれば、結構レベルは上がっていると思います。実際「ポリモーフィズムって何？」というレベルのプログラマーも多々いますから。
でも、もちろんこれより上のプログラマーもたくさんいます。なので当然、もっともっと勉強する必要があります。
そしてできれば、皆さんには「オブジェクト指向分析設計」も学んでもらい、「両方できる技術者」になってもらえればと思います。
そのためのとっかかりになりそうなポイントを上げておきます。
まずは「UML」を学びましょう。
UMLは、クラスや処理の流れを図に書く時の「書き方」を決めたものです。
オブジェクト指向分析設計でもオブジェクト指向プログラミングでも、重要なのはクラスの相互関係です。その関係を図にするとき、必ずこのUMLを使って書くので、これが読み書きできないとお話になりません。
なので、まずはUMLを学び、これを「オブジェクト指向表記」的に使えるようにしましょう。
次に「デザインパターン」を学びましょう。
デザインパターンは、「頻繁に使われている」クラスの相互関係を図にしてまとめたものです。
特に「GoFデザインパターン」と呼ばれる23のパターンについて勉強してみてください。
デザインパターンはオブジェクト指向プログラミングの知識が必要なため、このコンテンツで学んだことを再確認することができるでしょう。
また、デザインパターンを覚えることで、オブジェクト指向プログラミングの「よくあるパターン」を知ることができ、応用力が高まることでしょう。
そこまで学んだら、「オブジェクト指向分析設計」について学んでください。
これに関しては、座学よりも、実践を積んだり、様々なプロジェクトの設計図を見るのがいいでしょう。
というのも、前ページで説明したように、オブジェクト指向分析設計では「仕事」「情報」を抜き出してそれをまとめてオブジェクトと見なしていくのですが、その「仕事」や「情報」は作ろうとしているITシステム次第だからです。
どんなシステムを作ろうとしているのか、ひいては何を目的に作るのか、というところから「仕事」や「情報」を見いだしていきます。そのため、必ず「目的」が存在する、実際の開発現場から学んだ方が確実でしょう。
プロジェクトごとに「現実社会」と「クラス設計図」を見比べて、どのようにして設計していけばいいのか学んでいってください。
最後に
長文を御読了頂きありがとうございました。
これからも学ぶべきことはたーっくさんあります。
でも、その「学ぶため」にも、毎日のハードワークをこなさなければならないのがIT業界の現実です。
そのハードワークを消化するときに、このコンテンツがお役に立てれば幸いです。
（完）
