オブジェクト指向について

オブジェクト指向でコーディングするとinterfaceやAbstractなど記載量とファイル数が増え、工数が増大すると思います。例えば、セッション管理、DBアクセス制御など、通常Frameworkとしてまとめる基板部分についてはオブジェクト指向で開発する意味はあると思いますが、業務ロジックなどについては、開発者のレベルを下げる意味でも、オブジェクト指向で開発しないほうが効率的と考えますが、皆様のご意見をお聞かせください。

No.9 回答者： maia55jp 回答日時： 2013/08/18 21:16

>業務ロジックなどについては、開発者のレベルを下げる意味でも、

製造者だと思うのですが、本来、interfaceやAbstractなどは、設計段階で抽出等を
行ってFrameworkと同等な扱いにすべきです。製造段階で発生したものは設計に差し
戻し共通化すべきです。

>オブジェクト指向で開発しないほうが効率的と考えますが、
そう思えるようなプロジェクトだと、しないほうがいいかと思います。

本来、詳細設計ですべきことが製造段階まで落ちてきているようですので、仕様書の
ないクラスやinterfaceやAbstractなどが散乱してる筈で、後々のメンテナンスや修正
の地獄が見えてますね。

まぁ、現実、仕様はソースなんてもの多々あり、理想でしかなかったりしますが・・・

No.8 回答者： wormhole 回答日時： 2013/08/18 10:16

#7の方が言い尽くしてしまってますが

>あくまで、オブジェクト指向から見られる、抽象化プログラミングには、現状業界でもてはやされるほどの効力が無いのではという、問題提議ですので、

あなたの思われている抽象化プログラミングの効力とは何なのでしょうか？
質問文を読む限り抽象化プログラミングの効力の話など出てきてはなかったような。
質問文に書かれてる内容を要約すると
・interfaceやabstractクラスのためにファイル数が増えるので工数が増大する。
・低いレベルの開発者のレベルで開発した方が効率的。
だと思うんですが。

もし、あなたがそれを他者を納得させようと思ってるのでしたら、
・抽象化プログラミングでのデメリット(ファイル数が増えることによる工数の増大)が、得られるメリットよりも大きいこと
・低いレベルの開発者のレベルで開発した方が効率的な例
を示さないといけないと思いますけど。

私としては「ファイル数が増える=工数が増大」というのも安直だと思いますが(たぶん他の方もinterfaceやabstractクラスでファイル増えたからといって、工数が増大するとはとらえてないと思う)

>「コレクション・・・」という話ではありません。

必要な開発者のレベルを下げるためには有用な技術の使用を禁止するという姿勢なら、コレクションの禁止もありえるのでは？(コレクションに限った話ではなく)


そういえばフレームワークはオブジェクト指向での開発はOKで、業務処理ではオブジェクト指向で開発しないというのはどういう状態なんだろう。
フレームワーク側でセッション管理やトランザクション管理を受け持つようなつくりの場合、業務側はフレームワーク側で用意している基底クラスを派生させて業務処理メソッドを実装するとか業務処理用のinterfaceがあってそれを実装するとかいう事になると思うんだけど、それは業務処理側もオブジェクト指向で開発してるって事だとだし。

No.7 回答者： hanabutako 回答日時： 2013/08/17 13:22

Age of Empiresというゲームを知ってますか？

Empire Earthでもいいんですが。
なんというか、そういうのですね。

時代をすすめるのにはそれなりのコストがかかり、時代が進んで使える強い武器にもそれなりのコストがかかるけれどそれだけ敵を倒しやすくなる。時代を進めていなくても、人海戦術的に頑張れば後の時代の敵を倒せる。
どちらがいいでしょう？というような。

時代をすすめるにはそれなりのコストがかかるので、時代を進めずに敵を倒しに行くという戦略はあるものの、敵の時代が進んで、それなりの武器を手にされてしまったら一気に形勢逆転します。
コスト・採算管理もそういうものだと思います。

スキルがなく人件費が安い人を集めるのは小さなプログラムの開発の時代にはなんとかなるでしょうけれど、大規模プログラム開発の時代になったらそれでは戦えないでしょう。

※表現についてお気にされる内容があるかもしれませんが、充実した内容の議論にしたいためとご理解ください。

あと、このスレッドは議論というより、オブジェクト指向を生半可にしか理解していないオブジェクト指向無用論者への説得に見えます。大学の情報系の学生ならボスなり先輩なりと毎日議論ができて (というか、彼らから説得されて) 段々と理解が進むんでしょうが、そういう環境にない人がオブジェクト指向を理解するのは難しいでしょう。社会人になったら、分かる人は分かる人としか仕事しないですから。

> あくまで、オブジェクト指向から見られる、抽象化プログラミングには、
> 現状業界でもてはやされるほどの効力が無いのではという、
> 問題提議ですので、「コレクション・・・」という話ではありません。

知識がない人、扱えない人にレベルを合わせた開発をしたほうが効率がいいという問題提起かと思いました。でも、そういう所では知識・技術がある人は働きたがらないでしょう。

抽象化に効力がないんじゃなくて、出会いがないんだと思います。
それなりの知識や技術がある人は、それを活かせる人たちと働きます。
そういう会社なりチームなりに相応の知識・技術が無い人は採用されません。
だって、技術者たるもの、自分のスキルアップも兼ねて、自分より優秀な人と働きたいですよね？

自分から見ると、オブジェクト指向が扱えるというのもコレクションが扱えるというのも本質的には同じだと思います。それを知っていれば使えるし、知らなければ使えない。
コレクションを使えば5分で書けるプログラムを、コレクションを知らないために1時間かけて書く。
オブジェクト指向を理解し、設計しておけば、自動テストを走らせることも含めて10分でできる修正が、オブジェクト指向で設計していなかったために影響範囲の理解に2時間かかり、修正に1時間、ちゃんとしたモジュール化がなく、自動テストが書けなかったために手動で逐一テストしてテストに5時間かかる。
より強い武器にはより大きな学習コストがかかるだけで、本質的には、変わらないです。

> ロジックの切替についても、単純にコーデシングし、メソッド切替で対応することで、インターフェイスを理解した開発者を雇うよりも費用工数面で、現実社会に適していないでしょうか。

よく言われるヒューリスティックとして、「オブジェクト指向を理解していない人の書いたプログラムはif文やswitch文がやたらと多い」というのがありますが、これはその典型例のように思います。こういう場合こそちゃんとinterfaceを切って、dynamic dispatchしたほうが変更時にメインロジックを触る必要がなくなり、効率がいいです。
そこのところをよくわからないなら、先の投稿でリンクしたPDFファイルをご一読ください。メソッドで切り替えるということは、改変の依頼があった場合、どのメソッドで切り替えたら良く、その影響範囲がどの程度かを調べるのに多大な労力が必要ですよね。

コストについては後述します。

> また、業務と言うのは殆どの場合、例外や改変というのが、担当者が変わると頻繁に発生します。

そういう場合こそプログラムがちゃんと疎結合していないと変更が影響する範囲をリストアップするのに多大なる時間と労力を要しますよね。モジュール化がちゃんとしてあればモジュール内だけ見たら変更できますが、モジュール化がちゃんとしてないプログラムは最悪全部のコードを読まないと修正出来ません。

また、こういう場合こそ例外・改変に柔軟な対応ができるように、最初から設計に織り込んでおかないといけないと思います。

> システムの世界でそこまで高いレベルの事を実現するメリットとはなんでしょうか。

開発に携わる側からすれば、
帰れる。儲かる。
でしょうね。

安物買いの銭失いって知ってますか？
頭数合わせみたいな素人がよってたかって作った不具合多めで、改変が難しいシステムなんて、開発が長期化して掛け算で人件費かかり、違約金を払わされ、結果的に高くつくと思います。納期を守れない、不具合が多い、(モジュール化が悪く、修正箇所の発見に苦労して修正が遅いので) 不具合対応も悪いとなったら、そこ以外に頼めない場合を除き、わざわざそこに仕事を頼まないですよね。

初学者でループ、関数呼び出しで学習に行き詰まる人というのは多々いると思います。これらは抽象化のための仕組みの一つで、トレーニング無しに理解することは難しいでしょう。しかし、彼らの底上げをするのではなく、そこにあわせてプログラムを書くべきとなってしまったら、main関数に全部のコードを書き、ループも使わないということになると思います。自分にはそのほうが効率的だとは思えません。


| プログラミング言語の歴史とは、モジュール化の歴史です。

と先の投稿で書きましたが、これが何を言っているのかわかりましたか。プログラミング言語が進化し、より高度なモジュール化ができるようになったことで、人々はより大きなプログラムを少ない不具合で書けるようになって来ました。また、言語がサポートしてくれることで、高度なモジュール化を実現するために書かないといけないコード量が減りました。あなたが批判しているオブジェクト指向というのは先の投稿でも書きましたが、その歴史の上にあります。

オブジェクト指向が主流になる前に人々が熱く議論していたのは構造化プログラミングでした。
http://ja.wikipedia.org/wiki/%E6%A7%8B%E9%80%A0% …

抽象化不要と本気で言っているとしたら、goto文を自由に使えないプログラミング言語や規約も現場を知らない学者が言い出した役に立たないことだと感じるのではないでしょうか。抽象化不要という質問者にとっては、関数やサブルーチン、変数のスコープなんかも、プログラムの実行順や変数の参照の自由を妨げ、真のプログラマーの開発を妨げる邪魔なものに感じられることでしょう。いやいや、高級言語だって邪魔じゃないですか？あなたが思った効率的なレジスタ割り当てをできず、プログラミング言語とその処理系を通してしかCPUに指示できないんですよ。OSもあなたの行いたいリソースの割り当てを邪魔する邪悪な存在です。
というわけで、抽象化を否定する質問者にふさわしいプログラミングは機械語を書き、ストレージへのアクセスも直接デバイスに命令を送って行うこととお見受けしますが、いかがでしょうか。

閑話休題
そうそう、保守を依頼しようがしまいが、最低でもJavaDoc相当のものや、各メソッドの使い方がわかるようなテストくらい書きましょう。プログラム全体で使われるようなライブラリーについては、使い方をある程度詳しく書いたドキュメントがあったほうがいいでしょうね。あとは、クラス図やシーケンス図相当のものがあったほうが理解の助けになるとは思います。

と、長々と書いて来ましたが、
確かにオブジェクト指向はそれを使える人と仕事をしないと無用な知識かもしれませんね。でも、世界にはオブジェクト指向を仕事で当たり前に使っている人々がいるということを理解してください。質問者がオブジェクト指向を理解しないでも仕事を出来るのは、オブジェクト指向への理解が当たり前となっている職場で働いていないからというだけです。

No.6 回答者： thunder-bird 回答日時： 2013/08/17 08:22

大変失礼ですが、オブジェクト指向云々の前にプログラム開発について疎い方だとお見受けしました。

くだらない話はこれ位にしてクローズされる事をお勧めします。

この回答への補足

趣味プログラマーではなく、仕事としているプロのプログラマーです。
ですので、コスト、採算管理を考慮したうえでの何がベストかを考えるための質問内容になります。

補足日時：2013/08/17 09:45

No.5 回答者： wormhole 回答日時： 2013/08/16 16:15

>これについても「全員大八車で配送する/徒歩で対応する」ことで対応可能であれば、そうするべきであると思います。

その例えだと、車だと1日で配達できても、車が運転できない人がいるなら車での配達はせずに大八車or徒歩で数日かかりの配達にすべきという主張になってしまいますが。

開発者のレベルを下げられる実装にする代わりに作業量を増やすことになっても、その方が開発効率がいいんですか？
なんだかコレクション使えない人がいたらコレクションも使う事も禁止されそうな。

この回答への補足

ご意見ありがとうございます。

>開発者のレベルを下げられる実装にする代わりに作業量を増やすことになっても、その方が開発効率がいい
>んですか？
>なんだかコレクション使えない人がいたらコレクションも使う事も禁止されそうな。

あくまで、オブジェクト指向から見られる、抽象化プログラミングには、現状業界でもてはやされるほどの
効力が無いのではという、問題提議ですので、「コレクション・・・」という話ではありません。

補足日時：2013/08/16 20:16

No.4 回答者： hanabutako 回答日時： 2013/08/16 00:36

オブジェクト指向は所詮、便利な道具です。

使うべき所で使い、使う必要がない所では使わない。ただそれだけです。そもそも、質問者は何のためにオブジェクト指向を使っているのですか？質問を見る限り、オブジェクト指向を使っているのではなく、オブジェクト指向をよくわからず使わされているようにお見受けします。

プログラミング言語の歴史とは、モジュール化の歴史です。モジュール化とは、関連するものを密に結合し、関連しないものを疎に結合するということです。オブジェクト指向とはその歴史の1ページで出てきた技術に過ぎません。

業務ロジックの実装でオブジェクト指向など不要とおっしゃっていますが、普通に考えてロジックが複数種類あり、それを入力などによって切り替える必要がある場合、呼び出し元についてはインタフェースを切り、各業務ロジックごとにその実装を作る形で実装したほうが良くないですか？

例えば、これを読んでどういう時にオブジェクト指向が必要なのかちょっと考えてみてはいかがでしょうか。
http://www2.ocn.ne.jp/~yamagu/object/OCP-J.pdf

> 開発者のレベルを下げる意味でも

他の人の意見と同じくですが、開発者のレベルを下げるためにある技術を禁じるのは有害でしょう。

例えば、あなたが配送業をしていたとしましょう。
トラックを運転できない人がいるから、すべての荷物の輸送でトラックを使わないということをしますか？自転車にも乗れない人がいるから、全員大八車で配送するようにしましょうなんてことをしますか？

しないですよね。トラックを運転できる人には拠点間の荷物の輸送をしてもらい、自転車に乗れる人は拠点から遠くの配達、乗れない人には拠点から近いところの配達をしてもらうのが現実的ではないでしょうか。
この場合、業務上必要ならトラックを運転できる人を雇うなり、今いる人にトラックの免許をとってもらうなりするのではないでしょうか。また、自転車すら運転できない人については、業務の効率化のために辞めてもらうこともありえますよね。
自転車すら運転できない人のために全員が徒歩で配送するとしたら、効率悪すぎでしょう。

ソフトウェア開発でも同じです。業務に必要な道具 (例えばオブジェクト指向) をちゃんと使いこなせる人はインタフェースのデザインなど、その知識がないと出来ないことをしてもらい、それができない人はそれができないなりの仕事をしてもらうだけです。

この回答への補足

ご回答ありがとうございます。

さら議論を続けたいと思います。
※表現についてお気にされる内容があるかもしれませんが、充実した内容の議論にしたいためとご理解ください。

>>>>(1)
>業務ロジックの実装でオブジェクト指向など不要とおっしゃっていますが、普通に考えてロジックが複数種
>類あり、それを入力などによって切り替える必要がある場合、呼び出し元についてはインタフェースを切
>り、各業務ロジックごとにその実装を作る形で実装したほうが良くないですか？

業務ロジックを統合出来るレベルというのは、殆どの場合は実業務のコア部分のみではないでしょうか。ロジックの切替についても、単純にコーデシングし、メソッド切替で対応することで、インターフェイスを理解した開発者を雇うよりも費用工数面で、現実社会に適していないでしょうか。
また、業務と言うのは殆どの場合、例外や改変というのが、担当者が変わると頻繁に発生します。
その点について、業務運用方法を手順化するべきという話しもあると思いますが、それが出来る企業と言うのはどれだけあるのでしょうか。私が関わったところはありませんでした。大企業であっても、予算の都合、そのルール化に掛かる費用から適切なレベルは実現できていないと思います。


>>>>(2)
>例えば、あなたが配送業をしていたとしましょう。
>トラックを運転できない人がいるから、すべての荷物の輸送でトラックを使わないということをしますか？自転車>にも乗れない人がいるから、全員大八車で配送するようにしましょうなんてことをしますか？

これについても「全員大八車で配送する/徒歩で対応する」ことで対応可能であれば、そうするべきであると思います。
システムの世界でそこまで高いレベルの事を実現するメリットとはなんでしょうか。


>>>>(3)
>あと、オブジェクト指向による抽象化プログラミングをした場合に、第3者基幹にそのプログラム保守・改変を依頼するとき、単純プログラムに対して、どの程度のドキュメント資料が必要になるとお考えでしょうか。


以上について皆様のご意見をお聞かせください。

補足日時：2013/08/16 11:54

No.3 回答者： yoratomi 回答日時： 2013/08/15 20:24

私の持論ですが、一人でしこしこ作っているレベルだと、クラスとかオブジェクト指向なんてのは、めったに使わないで、関数ベースでがしがし書いていったほうが、楽で早いかと。

で、一回作りきっちゃって、「あ、あとあとこれってクラス化したほうが便利じゃんっ！」って時に、クラス化させたほうが、簡単な楽な気が。
私は、あくまでサンデープログラマですが、クラスはそうやって作ってます。（苦笑

「まぁ、最初っから全部見通して、作れよって話なんですが、個人レベルの小さなソフトだと、クラス化のメリットも少ないと思いますよ。」という言い訳の元、一番最初にJAVAを諦めた。（苦笑

個人的には、一度クラス化してメモリ関連でえらい目にあったので（まぁ、参考にしたソースがクラスだったので流用したらorz）、オブジェクトを作るにも、極小の時間と、極小のメモリを消費しているってわけです。

逆に大規模プロジェクトで、大勢で作っていくと、下手なグローバル変数は作れないわけで、その辺をきっちり管理されないと、どえらい目にあるので、クラス化は必須かと。

No.2 回答者： teketon 回答日時： 2013/08/15 14:15

オブジェクト指向でやるかどうかは、抽象化レベルやサービスの粒度による話なので

どうでもいいですが、開発者のレベルを下げてはなりません。
技術レベルに相応しいタスクを割り当てるだけの話です。

No.1 回答者： wormhole 回答日時： 2013/08/15 12:58

オブジェクト指向など関係なく、同じような業務処理もコピー＆ペーストで済ます方が開発者のレベルも下がって工数も減るという意見に私には思えますけど。

>開発者のレベルを下げる意味でも、

これについては賛成しかねます、
無能な開発者分は他の開発者の負担になるだけなんで。