オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena

「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

[nakag0711]

OOPコードの読みにくさだけはもうどうしようもない事実。しかしベタ書きコードが巨大化したときのどうしようもない保守性の悪さも事実であり…結局コードが巨大化するのが悪いのだが、OOPの方がいくらかまし

[erya]

コードを読まなくても大意がわかるようにオブジェクト指向があると思っていたけど。全部処理を追ってる時点でそれは何かおかしい気もする。浅はかかな。

[maeda_a]

オブジェクト指向の目的は『読みやすくする』というより『変更に強くする』事だと思うけど。小さいオブジェクトの先まで追いかけずにすむよう分離する「抽象化」が重要なのに、一言も出てこないね。

[toro-chan]

DDDもレイヤーで完全分離すると、どこが何を呼び出してるのか分からなくて複雑で読みにくい。システムが複雑なのだからどうやっても複雑で読みにくくなるのだろうと思ってる。その「複雑」をどうするかは難しい。

[opnihc]

OOPが何故生まれたかが分かるぐちゃぐちゃコードを思い出すと何だかんだいってOOPに帰着する。自分は筆者の域には達してない

[strawberryhunter]

悪いのはOOPすべてではなく、読みにくくなる主因はDIと継承。かといってラムダや匿名関数のようなものはさらに早期に破綻する。業務ロジックに関しては普通に構造化プログラミングで愚直に書くのが一番だと思う。

[Iridium]

問題は抽象化のための仕組みのせいで処理を追えなくなることなんだ。全クラスをインターフェースで始めるとかアホなので、必要のない抽象化はやめろ。本当に必要な場合だけ使ってくれ

[bearcub]

XXXFactory.createObject()みたいのはまだ耐えられたが、再コンパイルしたくないがためのDependency InjectionでImplを設定ファイルで指定とか言い出した頃には暗黒面に堕ちて行ってたと思う。その後は脱出したので知らん。

[srng]

全部のコードは読みにくいというか俯瞰にしくくなるのは承知の上で分業分離する仕組みなのでは。それぞれのクラスやその設計者が完璧な仕事をしているという前提で。先を見に行く状況な時点で隠蔽と抽象化効いてない

[sds-page]

DB正規化の話なら「適切にやろうね」で合意できるのに、オブジェクト指向の話になると原理主義批判しただけでオブジェクト指向一切やらない人間扱いされるのはなんでだぜ

[yojik]

データ指向プログラミングも全然出自が違う概念が混じって多少困難はある。ゲームプログラミング出自のもの(ECSとか)、Clojure界隈(データ指向プログラミング)とか / 個人的には過剰設計しなけれゃ別に難しく無い派だけど

[touhousintyaku]

Javaを知り尽くしたような人ですら自分が体験したことがあるようなコードの追っかけ辛さを同じように経験するんだったら、ああもうしゃあないかって思うしかないか

[yamato3010]

オブジェクト指向プログラミングについて

[tmatsuu]

「オーバーライドした別メソッドが呼ばれている」で深く頷いた。書いた本人は視界明瞭でわかりやすいのだろうが、第三者の立場でソースコードを読み始めるタイミングは特にきびしい。

[hatest]

オブジェクト指向やりすぎると何でも物同士で自動化するピダゴラスイッチみたいな複雑なものができる。ある程度は人の手を介する（素直にコード書いく）ほうがいい。オブジェクト指向原理主義者になるな。

[findup]

やたらと抽象化やインターフェース、デザインパターンをとにかく駆使した「玄人」な設計をするのが凄いみたいな風潮が一時期あったようには思う。巨大なクラス図を見て途方に暮れる感じの。

[royzumi]

何のルールもないのならばインターフェースから先は負えないけど、ちゃんとルールを決めればIDEの補助を得て追うのは簡単（補助を得なくてもできるけどね）

[odz]

例えばインターフェースと実装の分離は拡張に強くなる代わりにそりゃ処理追いにくくはなるので、適材適所でという話なら、そりゃそうねっ話ではある。

[sa-yama321]

オブジェクト指向のフィールドって、単に区分けしたグローバル変数使っているのと同じだからね。

[manaten]

必要のない抽象化がコードを読みづらくするんだよなあ。多くのビジネスロジックでポリモーフィズムは不要だし、DIのためのインタフェース化もほぼテスト時の注入だけに用いられていて難読化と釣り合ってない気がする

[gui1]

エンタープライズサーバー側のＤＢがきれいにできておればそんなにひどいことにならないはず。リポジトリをちゃんと構築できる方法ならどれでも大差ない。好きにすればいいと思うよ(´・ω・｀)

[trace22]

そもそもオブジェクト指向の必要性ってもっと低レベルでデータと操作を一元化することで不正なデータ変更を防ぎ品質を向上を目指す、では。コードを読みやすくするためなんて話あったっけ？勘違い奴多いのはそう。

[kanetann]

GoTo的な意味で読みにくくするのはIDEでカバーしたいところだけど、WEB+DB PRESSに続きが書いてるのか、めっちゃ気になる... https://www.amazon.co.jp/dp/B0BPHDVCSV/

[el-condor]

コードの可読性では、責務分割が適切なOOPコード>>長大トランザクションスクリプト>責務分割が不適切なOOPコード、ただし実際問題として「適切な責務分割」はそんなに簡単ではないよね、というのはまあそうかなあ。

[katsyoshi]

これが例のビアバーでの話か

[dhrname]

ダール・オブジェクトクラスの継承(連接)による「抽象概念のダイクストラ階層」は「構造化プログラミング　第3部　第7章　概念の階層」を参照https://archive.org/details/Structured_Programming__Dahl_Dijkstra_Hoare/page/209/mode/2up?view=theater

[aike]

モデル化する対象がオブジェクト的かどうかによる。業務システムの計算処理はOOPに向かないし、Webはオブジェクト的な部品としてDOMがありフレームワークも充実してるので自作オブジェクトが必要になることが少ない。

[daichirata]

GoFとかコテコテのOOPの話であってエッセンス自体は大事だと思うので、適当にこれ読んでOOPはクソとか言い出すと結構やばい気がする。

[fa11enprince]

Webのプログラミングでフレームワークより上の層に関しては全くその通りだと思う。OSにベッタリとか例えばネイティブのゲームプログラミングだとちょっと事情が違う気がする。でも僕らが普段書く層は大体その通りかな

[rck10]

"密結合"してた古のモジュール達が変更や修正に弱すぎ、究極の"疎結合"を目指した結果が"抽象化"のような。"ドメインロジックを全部契約DTOに突っ込む"のは現実的ではないので、ドメインモデル貧血症は仕方ないような。

[carrier_pigeon]

I/Fとかパーツ化はマイクロサービスも同じ。良いところとある程度の複雑さはトレードオフ。ただJavaのガチ小クラス主義が実世界で使いにくいのはわかる。Rubyぐらいの緩い粒度でいいしクラス設計は人による。

[suikyojin]

逆では？オブジェクト指向があるから、プログラムが巨大化可能になり、巨大化したから複雑に読みにくくなったのでは？オブジェクト指向のような指針が無いと、無秩序に複雑化して巨大化に耐えられなかったのでは？

[hope_ring]

大体同意だなぁ。無理にやる必要はなくて構造化プログラミングの基本を愚直にやるのがよい。ただ大規模システムで書き方を統一するためのインターフェースは有効だし、GUIアプリはオブジェクト指向で組まざるを得ない

[tivrsky]

"その根底には、コンサルが自分たちの開発ツールを売るために業務アプリ屋さんに手法を売っていたというオブジェクト指向ビジネスモデルにあって" なるほど、それなら腑に落ちる

[zyzy]

「構造体に色々放り込めば、各データ（第一級オブジェクトの関数含む）が階層化されていてアクセスしやすい」くらいがオブジェクト指向（というか構造化なのだが）の使いやすい落とし所でそれ以上は邪魔なのかもなぁ

[l-_-ll]

"一生懸命おっかけたメソッドが「そいつは残像だ」ということで実際はオーバーライドした別メソッドが呼ばれているということもあります"

[NOV1975]

良い設計のためのOOPのはずが言語仕様を学習しないバカでもserviceクラスに業務処理書くくらいはできるというIT土方の道具に帰結したからねえって話ではある

[uzusayuu]

Bjarne Stroustrup Interview about C++を思い出した http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

[quick_past]

どんな道具でも使いようだし、オブジェクト指向だってなんだって、利点欠点はあるものなので。書く側が汚く書けば、どんな環境やパラダイムでも汚れまくっていく。

[rryu]

これはFizzBuzzエンタープライズエディションみたいに規模に関わらずフルスペックの抽象化を適用するのが良くないというだけで、C言語でも必ずFILE型みたいに作ったら読みづらくなると思う。