「嫌われるオブジェクト指向」のパターン

OOP

憂鬱本なんかの屑本を鵜呑みにして、失敗している人が多いからでは．類書は他にも多数．*1

憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection)

憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection)

いちばんやさしい オブジェクト指向の本 (技評SE新書 007)

いちばんやさしい オブジェクト指向の本 (技評SE新書 007)

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

上記三冊はダメ本の例．
出る前からなんだけど，たぶん下の本もダメ本．*2
Java・オブジェクト指向の壁を突破する 抽象化プログラミング入門 (豆蔵セミナーライブオンテキスト 3)

Java・オブジェクト指向の壁を突破する 抽象化プログラミング入門 (豆蔵セミナーライブオンテキスト 3)


まともなのはこちら => http://d.hatena.ne.jp/JavaBlack/20070522/p1

15,16，オブジェクト指向の問題点

  • クラスが増えすぎる
  • 機能が複数のファイルに分散しがち
  • デバッグし辛い
  • オブジェクト脳になりすぎて、『サブルーチン的』な解決策に目が向かない

どれも「OOP」の欠陥じゃないように思う．十中八九「おれおれオブジェクト指向」に踊らされているんだろう．哀れな話だ．


他に失敗しそうなパターンというと，

こういうプロジェクトには関わりたくない．

関連：
http://d.hatena.ne.jp/JavaBlack/20070504/p1
http://d.hatena.ne.jp/JavaBlack/20060702/p1
http://d.hatena.ne.jp/JavaBlack/20060315/p3

http://en.wikipedia.org/wiki/Object-oriented_programming

  • リスク回避のため枯れた技術しか使おうとしない
  • 標準化プロセスという名目で工夫の余地を与えない

そういう所に入った若手は腐るか、やめていくか。そうやって若手の未来を奪うことで、年寄りは生活の糧を得ている。正しい姿とは思えないな。
http://d.hatena.ne.jp/masayang/20070803/1186199686

  • もとハード主体であった電機メーカーのソフト開発ってのは悲惨である。プロセスが基本的にハードウェアの開発手法から派生しているためだ。ハード開発の経験者がマネージャーだからだ。怒涛のウォーターフォールなのだ。
  • 丸投げも仕様書作成ができればいい方で、パワーポイントで四角と線で絵を書いてお仕舞いなんてこともあった。ドキュメントまで外注に書かせ、さらに実務を行う社内のエンジニアも契約だったりする。

http://remote.seesaa.net/article/16215845.html

部長の怒号、
「当部門を背負って立つ重要プロダクトだ！」
「なんとしても出荷しろ」
じゃあ、なんで社内数人で、丸投げなんだと..
勿論、結果は無残。出荷停止。契約破棄。億単位の金と時間が徒労に終わる。
http://remote.seesaa.net/article/16759278.html

追記

http://d.hatena.ne.jp/LazyCoder/20070806/1186417299

オブジェクト指向って技術者を設計者と実装者に二分する性質を含んでる気がします…。

本物のオブジェクト指向にはそんな意味は全くなかったんですよ．どうやら「このままでは立場がなくなるぞ」という危機感を持ったレガシーな設計者の皆さんが，そういうデマを広めたみたいですね．*3

「クルマのたとえ話」とかは本当に意味わかりませんでした。

あれは本当に単なるたとえ話にすぎず．専門家からはあまり役に立つとは思われていません．

オブジェクト指向の入門書では、「謎のたとえ話」から始まるものが多いように思います。
典型的な例は、はじめにでも挙げた、「哺乳類を継承して犬と猫を作り、『鳴く』というメッセージを送ると犬なら『わん』、猫なら『にゃあ』と鳴く」って奴でしょう。他にも、ちょっとWebをぐるぐるすると、清原選手をオブジェクトにしてみたり、箪笥をオブジェクトにしてみたりなどなど、およそプログラミングとはかけ離れた説明が蔓延しています。
こんな説明を読んで、なんだかわかったような気分になれる人は、どっちかというと思考力に欠ける人なんじゃないかと思います。「わけわからん」という反応のほうが技術屋としては正常でしょう。
いい加減、こういうわけのわからないたとえ話はやめたらどうかと。
あんなもん、わかったつもりの半可通と、理解できない挫折組を生み出すだけではないかと。
http://kmaebashi.com/programmer/object/naze.html

で、「プログラミング言語C++」を読んで、なんとなーくソースの書き方がわかってきて、「リファクタリング」という本を読んで、

あとやはりGoFは重要ですよ．順番としては言語解説書=> GoF本 =>リファクタリング，かな？C++の人だと「C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)」あたりもいいかも．

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)

  • 作者: ハーブサッター,アンドレイアレキサンドレスク,浜田光之,Herb Sutter,Andrei Alexandrescu,浜田真理
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/10
  • メディア: 単行本
  • 購入: 20人 クリック: 383回
  • この商品を含むブログ (100件) を見る
参考書一覧：http://d.hatena.ne.jp/JavaBlack/20070522/p1

ようするに、たとえ話はほどほどにして、動いてるソースを見たほうが良いんじゃないかなぁと。

これは全くその通りです．コードを理解せずにOOPは理解できません．
ただし，良いコードは探すのが難しいんですよね．

*1:「俺は分かってるぜ〜」みたいなことを言ってる奴の何割か，下手すると過半数が，こういう屑本で染まった「おれおれオブジェクト指向」の専門家だから達が悪い．

*2:そもそも「抽象化プログラミング」なんて専門用語あったっけ？"Abstract Data Type"ならわかるけど．

*3:古典的なオブジェクト指向の概念は80年代には既に固まっていた．JavaとGoFが登場して今ある形のオブジェクト指向がほぼ完成したのが95年．ちなみにUMLが登場するより前のハズ．
あの手の「おれおれオブジェクト指向」が出てきたのがそれ以後，おそらく90年代後半〜2000年前後だが，それ以前から発展・進化してきた「オブジェクト指向」とは何の関係もない類似品でした．まるでカルト教団が「我こそが真なるXX教の預言者である．今までの奴らは邪教に過ぎない．」とやってるようなもんです．