箱庭ハーブblog

元平日プログラマの趣味の小部屋

オブジェクト指向って本当に必要?

オブジェクト指向プログラミング、OOP、Oop、oop、構造化プログラミング 、クラス図、code、Code、C#、Java、java、コーディング、.NET、.Net、.net

2012/08/02
文章が読みやすくなるように修正しました。

2013/09/11
文章を大幅に改訂しました。



月曜辺りから何か記事を書こうかなーと思いつつ、結局何も書いていないこの感じ。
というわけで今回はオブジェクト指向についてグダグダと。



【現場の スパゲッティOOP'sプログラム】

会社で作業をしてて気づいたことなんですが、オブジェクト指向とか害悪以外の何者でもない
・オブジェクトのようなオブジェクトじゃないような塊がいたるところにある
・古い慣習の考え方が染み付いているので、変なところでstaticな関数を定義して使う
・Factory関数やその他いろいろな関数が、どのクラスに所属するべきなのかを考慮されてない
・クラスの所属関数がいい加減なために起こる、多すぎるPublicメンバ
・関数名が摩訶不思議(SetしないSet関数、Newしてる非ファクトリ関数、GetしないGet関数)

【どうして スパゲッティOOP'sプログラムになるのか】

【OOPが分からない】

OOPが問題となる要点としては、以下の点が感覚的にわからないからでしょう。
・メンバ(処理や変数)をどのクラスに所属させるべきなのか
・そのメソッドは何をしているのか
  ・Get関数とFactory関数のどちらを自分が書いたのか
  ・GetHogeと書いたが、ほんとうに取得している値はなんなのか
・新規のクラスが別のクラスを必要とする時、継承すべきか、メンバとして持つべきか
・Publicメンバを減らそうとする気概が重要であるとわかっているか

例を見てみましょう
1、あるクラスは、Initialize関数で自分を組み上げていきます。
2、Initialize() する前には予めプロパティに必要なパラメータをセットする必要がある。
3、Initialize() 内では、パラメータを元に生成処理が行われる

実際には、以下の通りです。
・Initialize() なんて名前ではなく、SetHoge() なんて名前です。
・複数SetHoge()に分割されています。これらは正しい順番で呼ぶ必要があります。
・2の通りなので、SetHoge() とは別経由でプロパティに値を設定する必要があります。
・そのクラス内部で定義されてる識別子名は、実際の処理と乖離した処理内容です。
・インナークラスが定義されており、多態性の恩恵を受けていない継承を利用しています。
・プロパティをPublicで公開しているが、明らかに公開不要です。

これらが、オブジェクト指向を中途半端に理解する弊害で発生します。

【継承の作法を復習】

多態性の相互作用(インターフェース)を設計したい時のみ、使う。
逆に「インターフェースで使いたい」という感覚がわからなければ、使う意味がない

【OOPの考え方】

以下、オブジェクト指向の復習
オブジェクト指向は、人によっては様々に言われます。
「構造化プログラミングと相反するものではない」
「構造化プログラミングとは全く異なる概念だ」
「部品を作るのがオブジェクト指向だ」

1、オブジェクト指向は1まとまりの部品を作ることか?
機能を一まとまりしようとする考え方。
機能をひとまとまりにする考え方は非常に強力で必須な考え方です。
しかし、オブジェクト指向特有の考え方ではありません。
構造体で実現できる内容であり、構造体はC言語から存在します。
オブジェクト指向の要点の一つにカプセル化があります。
カプセル化とは機能をひとまとまりにするだけではありません
アクセス修飾子、公開するメンバをよく考える、ということが含まれます。
よって、オブジェクト指向は1まとまりの部品を作るという理解では、不十分です。

2、オブジェクト指向と構造化は対立する概念か?
構造化プログラミング自体が何かを理解してないとこの問いには答えられません。
構造化プログラミングは、
「メインルーチンとサブルーチンで考えて、ルーチンを部品化しよう。
条件処理はIF文とWhile文とFor文で処理しよう」指向です。
処理の流れを階層フローチャート(※1)(厳密にはPAD図)のようにイメージします。
これに対してオブジェクト指向は、プログラマと言うよりは上流工程向けの概念です。
こんな部品、こういう関係、こういう協調動作、を作るのかな?
と想像した内容をそのままプログラムで実現しようと言うものです。
プログラムをユースケース図のように捉え、
クラス図に落とし込んで構築することで、
想像した設計とプログラムの制御構造を一致させようと言うのが主目的です。
要約すると、それぞれ

構造化は 【階層・部品化されたフローチャート】
オブジェクト指向は 【アクターとその協調動作】

と捉えて設計とプログラムコードの意味を一致させようとします。
どちらもソフトウェアとどう捉えるかという考え方の相違です。

オブジェクト指向は構造化に対してわかりやすいとは限りません。
本質的に(if、for、while、サブルーチン)とは相容れないものと言えるでしょう。
また、場合によって使い分けられるべき手法であると言うことです。
WindowsのGUIを作ろうと思ったらオブジェクト指向で設計開発した方が効率的です。
多彩な条件で分岐するプログラムの詳細を作ろうとしたら、構造化のほうが直感的です。

って、長く愚痴を言ってしまったけど、全く役に立たない知識ですね、はい!



(※1)
よかったら、【おまけ フローチャートは素直すぎる】をも読んでください。



【おまけ フローチャートは素直すぎる】

フローチャート図は、それ自体が問題を孕んでいます。
フローチャートは、余りにも構造化プログラム言語で表現出来ることを素直に表すので、
スパゲッティプログラムも再現できてしまうのです。

ゆえに、フローチャート図はそれ自体が技量に左右される図なのです。
一方PAD図は、どうがんばっても構造化プログラミング指向な設計に仕上がるので、
とても扱いやすいです。
コメント
PAGETOPへ

コメント送信

お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード

パスワードを入れておかないと、コメントの再編集ができません!

フリーエリア

takemori
Unityと戯れてます
Twitter : @takemori_kondo

iOS
coming soon...

Windows
Html Editor - Nazuna
Managed DirectX サンプル集

beginning since
2006.08.17
renewaled on
2011.06.03

最新コメント

[2013/06/14 ミューネ]
[2012/08/30 ノートPC]