憂鬱本系オブジェクト指向プログラマの話かな？

OOP 悪書

なぜかホットエントリ入りしていた．釣りタイトルのせいか，そもそもOOPが炎上しやすいネタだからか．

中味は明らかな間違いも多いし，それ以外の部分についても賛同できない部分が多数．少なくとも初心者は絶対にコレを参考にしない方が良い．まるで憂鬱本を読んでるような気分になる．*1

先に追記部分から．

1/22追記
この「オブジェクト指向について」でも書いてますが、基本的にぼくの「オブジェクト指向」はランボーのOMTに従っています。世の中でよく言われている「オブジェクト指向」もOMTを源流のひとつとして熟成され ただよってるものだと思います。

そこでランボーはオブジェクト指向とは「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」と呼んでます。

オブジェクト指向方法論OMT―モデル化と設計

オブジェクト指向方法論OMT―モデル化と設計

どっと疲れた．

そりゃ90年頃ならそういう話もあったけどさあ，その後の30年間ずっと知識をアップデートしてないのか．*2 これも源流の一つかもしれないが，「他の全てのオブジェクト指向はOMTから派生した」なんて考えは完全に眉唾．



最初に戻って

そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。

……もうのっけから酷い．酷すぎる．

コピーとかは実装の話でプログラミングパラダイムとしてのオブジェクト指向の話じゃないし，実装についてはJavaとC++でも全く違うし，同じJava処理系でもVM実装によって大きく変わる．*3 *4 OOP言語全般としても，どちらかといえばリソースは贅沢に必用で，省メモリが目的じゃないし．どこの悪書を参考にしたんだろう．

そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。

その例えは一体なにを言いたいのか．むしろニュートン力学にたとえるべき奴では？

ニュートン力学が大昔の物理学であっても，今だバリバリの現役．力学の講義で，一番最初に説明されるような奴だ．

じゃあ現代的な考え方ってなんなのとなるけど、それはどちらかというと関数型になるんじゃないでしょうか。

それも大昔からあるよね．ガラケーどころか黒電話級の古さ．きしだ氏はオブジェクト指向は「古いからダメだ」というのに，LISPはさらに古いのに「現代的だ」という．いくらなんでもおかしくないですか．

関数型は実装としてはメモリをふんだんに使う仕組みになるので、昔は実用には厳しかったものの、

ここもいろいろ疑問なんだが，反論できるほど詳しくしらないからパス．できうるなら，ぜひ専門家の意見を聞きたい．*5 *6

サーバーサイドにはオブジェクト指向があまり向いていないので、いかにうまくオブジェクト指向で書こうとしても「しっくりこない」「わからない」ということになっていくと思います。

サーバーサイド関係なくOOPが分からない人はいたし，サーバーサイドでもOOPはバリバリ使われてるし，きしだ氏の観測範囲が狭すぎるだけでは．

しかしいま、ユーザー端末もWebブラウザベースで作ることが基本になり、ブラウザの中では状態はDOMとしてすでに閉じ込められているので、アプリケーションとしてオブジェクトの状態を考える必要性は薄くなってきています。

DOMは非常に原始的な設計で，それを使ったコーディングは煩雑になる．「状態」としてはそこにあるけれど，「使い難い」という致命的欠点がある．その欠点を改善するのもOOPの得意とする所だ．

そして最後に取り上げるのがこんな本かという感じですが、

導入部を見ただけでも，非お勧め本．

オブジェクト指向をきちんと使いたいあなたへ

オブジェクト指向をきちんと使いたいあなたへ

ではJavaで書いたプログラムは，オブジェクト指向が目指した「開発の効率性」や「変更容易性」は実現できているのでしょうか．残念ながら，Javaプログラムは開発スピードが遅く，ちょっとした変更にも苦労している，というのが多くの現場の事情だと思います．

つまり，クラスを使ったプログラミングをするだけでは，オブジェクト指向の良さは出てこない，と言うことです．オブジェクト指向の良さが実感できない，という意味でオブジェクト指向は，開発の現場にちっとも広がっていません．
（中略）
Javaを使った開発現場でよく見かけるのが，「データクラス」と「機能クラスを分離する設計スタイルです．データクラスは基本的にgetter/setterだけのクラス，処理ロジックは～

初心者向けに噛み砕いて説明しているにしても酷すぎる．

「実現できているのでしょうか」の質問に対しては，「十分に実現できた」が答だ．*7

その上で「日本の開発現場にはレベルが低くて，その使い方が間違っていて，実力が発揮できてない所も多い」というのが事実だとしても，それは各開発現場の問題だ．言語やOOPの話じゃない．

「OOP言語で書いただけではオブジェクト指向にならない」という話はC++の頃から既に常識で，今更むしかえすほどの話ではない．



いまOOPで，お勧めするならこっちじゃないのか．

オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

第1章　オブジェクト指向設計
第2章　単一責任のクラスを設計する
第3章　依存関係を管理する
第4章　柔軟なインターフェースをつくる
第5章　ダックタイピングでコストを削減する
第6章　継承によって振る舞いを獲得する
第7章　モジュールでロールの振る舞いを共有する
第8章　コンポジションでオブジェクトを組み合わせる
第9章　費用対効果の高いテストを設計する

https://gihyo.jp/book/2016/978-4-7741-8361-9#toc

OOPについて噛み付くなら，この程度の考え方には目を通して理解してからにしてほしい．たぶん見えてる世界が完全に一世代違うから．



「業務アプリの業務部分で、オブジェクト指向なんか使わないよね」

https://kmaebashi.hatenablog.com/entry/20090427/p1
一利ある．


そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。

そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、オブジェクト指向を駆使してクラス設計をして……という作業はまず入ってこない。

「単純なWebアプリでは必要ない．」，「底辺のプログラマーは使わない．」は，その通りだと思う．きしだ氏が紹介している図書も，そういう底辺初心者向けに書かれているようだ．

実際にはOOPはその裏でバリバリ使われまくってるし，ちょっと高度なことをやると基礎知識でしかないのだけど底辺プログラマーは気付かない．自動車を運転するだけのペーパードライバーやタイヤ交換くらいなら必要なくても，自動車を作るためにはもっと高度な知識が必用になるようなものだろうか．*8

つまりは「ペーパードライバー級の人間でエンジニアと呼んでいいか」という問題かな．

https://b.hatena.ne.jp/entry/s/nowokay.hatenablog.com/entry/2021/01/21/004148

  • id:gachapining プログラミング初心者に React の説明をしていたんだけど、OO なライブラリで new でてくると説明にかなり困ったなー
  • id:Clock0311 まあそうなんじゃねえかなという気がしつつ、では初学者に@article = Article.find(params[:id])を読み書きしてもらうためには何を理解してもらえば良いのか、その最小セットとは…と思い悩む。
  • id:n314 使うだけの人は必要なくて、部品を作る人は必要なんじゃないかなあ。昔は部品を自作する必要があったとか。でも何かを突き詰めるには結局自作する必要があるような気もする。
  • id:smatsubara 知ってて使いません、と、知らないので使えません、は全然違うけど。でも、必須ではないよ、という主旨ならこのコメントは見当外れかな。

「知らなくてもできる仕事はあります」は事実だけど，若い人に「知らなくて良いよ」というのは欺瞞だ．


遅かれ早かれ使うだけでも基礎知識は必用になるし，作る側になるとさらに重要になる．

  • id:sds-page あの頃みんな「携帯電話にカメラなんて不要だろ」って思ってたけど今じゃスマホもカメラで選ばれるようになったって話かな？

ほんまや．

  • id:rryu もはやオブジェクト指向がゴールではなくその先があるというのは分かるが、結局不要になるわけではなく構造化プログラミングやcomplex typeのように基礎の一部になるだけだと思う。

そういうニュートン力学なんかと同じ意味でや「スマホのカメラ機能」と言ってるなら同意できる．

  • id:toro-chan 関数型が新しいって言われると、苦笑いしかない。とっても古くからあるのに。。Lispさんの立場。。
  • id:queeuq つかみの部分が私の知ってる歴史とだいぶ違うので続きを読む気がゼロになった/異世界でこれからも頑張ってください。
  • id:tettekete37564 のっけから全然違くて先が読めない。メモリやりくり云々とかの時代的にオブジェクト指向は超贅沢な設計法だった。201x年頃までの iOS アプリの開発に使われていた ObjC も Cocoa フレームワークもどストライクの OO なんだが
  • id:zenito9970 のっけから全然違うやん(´･c_･`) メモリ効率がどうのなんてのはあくまで各言語での実現方法の話であって、OO自体にはそんなの含まれてないで(´･c_･`)
  • id:deep_one 「オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています」え？そう言うもんじゃないぞ？私の知ってるオブジェクト指向と違う。
  • id:w1234567 SmallTalkは昔からクロージャがあったのにラムダ式を関数的構文って呼んじゃう時点で筆者の視野の狭さを感じる
  • id:greenT オブジェクト指向と関数型は対立せんだろ…GoFデザパタの一部(command)とかが関数型の登場で不要になったというならわかる。関数型が流行ったのはメモリ効率ではなく並列処理のためでは

とにかく，きしだ氏は非常に視野が狭く，知識や経験が乏しいと思う．

歴史認識にも間違いが多いしオブジェクト指向も関数型言語も，どこまで理解しているやら大いに疑問だ．一歩間違うと完全に static おじさんだ．「（自分の狭い観測範囲では）オブジェクト指向など糞の役にも立ちません！」な人になってる．



「酸っぱい葡萄」なのでは．とっても美味しそうなのだけど，彼等には手が届かない．

  • id:murlock 識者の間でも意見の対立しがちなオブジェクト指向とかいう闇の概念。初学者が理解しようとしても無理なのは当然で、せいぜい理解した気になっている対立意見を持った識者が再生産されるくらい。

これはたしかにある．

せめて Mets本くらいは読んでからにしてほしい．憂鬱本や「なぜつくるのか」を読んで，変に洗脳されちゃった初心者は哀れだった．


  • id:ed_v3 言語とかチームの規模とか作るものとかによって何が良いかは全然違うのでこの手の主観的な記事はてきとーに読むのが良いってことを影響を受けやすい初学者の皆さんには言っておきたい。謎。

*1:この本のこと．

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

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

  • 作者:Tucker
  • 発売日: 1998/05/31
  • メディア: 大型本
何故か絶賛する人は多かったけど，筆舌に尽くしがたい歴史的な悪書・糞本．

*2:そもそも，その世代だとカモノハシ本を知らないのはモグリ．

オブジェクト指向プログラミング入門 (アジソン ウェスレイ・トッパン情報科学シリーズ)

オブジェクト指向プログラミング入門 (アジソン ウェスレイ・トッパン情報科学シリーズ)

*3:初期にはpicoJavaとかあったんですよ．

*4:コピーも普通にしてるよねえ？ https://gihyo.jp/dev/serial/01/jvm-arc/0005

*5:emacsなんかは，昔はメモリもさることながらCPUパワー的にも厳しかった．

*6:スタックマシンの研究なんかも見た事はある．当時でも完全に廃れた代物．

*7:よくみると「実現できているのでしょうか．」と「残念ながら，」の所で論理が飛躍していて文章が不自然になっている．その間に「もちろん実現しました．」の一文を補足して段落を変えるくらいでちょうどいい。
「～は実現できているのでしょうか．もちろん実現しました．
しかし残念ながら，長年技術を軽視してきた日本の開発現場では使いこなせるプログラマーが不足していたために，javaを導入しても今まで通り開発スピードが遅く，ちょっとした変更にも苦労している，というのが多くの現場の事情だと思います．」

*8: たとえるなら自動車エンジンの基礎の基礎も知らない人による，「ガソリン車だけど，軽自動車だから軽油を入れた話」みたいなことがIT業界でも起きてるのだよ．日常的に．