オブジェクト指向ってクソじゃねぇかよPart3
■ このスレッドは過去ログ倉庫に格納されています
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/ 熱いsmallalk談義
内容は理解出来ないけど
その熱さは良いよ だから言ったじゃん
ピュアオーディオとか純喫茶とか純文学の話になってるだろ
それに連なる『純オブジェクト指向』だ
ここで純オブジェクト指向と目されるSmalltalkを持ち出してピュア談義してるだけだ
オブジェクト指向≒Javaと見做されてる昨今では「Javaはクソ」≒「オブジェクト指向はクソ」となるのが普通だ
そこにわざわざ純オブジェクト指向なる概念を持ち出すから話がややこしくなる
平たく言うと、Javaの開発案件がたちまちクソの山になるのはそれがオブジェクト指向だから、っていう話だ
それも、数値にしがたい負の感情を産み出す母体になってる
オブジェクト指向にメリットはなく、代わりに数値化できないデメリットが業界で拡大再生産されてる
その根幹原因がJava≒オブジェクト指向にある
クソなんだからメリットが生産されるわけじゃない
デメリットが生産されてんだよ
「現状のオブジェクト指向が上手く行かないのは、それが純オブジェクト指向じゃないから」
それを延々話してるんだよ
その「純オブジェクト指向」なる状態が、あり得ないものか、未だに存在してないものか、そもそも存在出来ないものかは知らないが、
現状の実態たるJavaの話から乖離して、延々と架空の話を続けてるだけだろ
現実を見たくないからわざわざSmalltalkなんて引っ張り出して来てるんだよ
それだけクソってことだろ まあでもJavaってオブジェクト指向だからクソなんだろ？ JavaのWrite once, run anywhereに代わる新しい標語を考えよう！
まず俺からな。
Java -- Motor of all fails -- 予測変換で間違えた！
では改めて。
Java -- Mother of all fails -- オブジェクト指向は糞の山を作りやすいというのがメリット DBから取ってきたデータをただの構造体としてしか使ってない
Java現場ばかりなんだがそれをオブジェクト指向と言うのか >>7
Smalltalkが純オブジェクト指向？Self見てから言えよw >>14
いわないんじゃない？
せめてO/Rマッパーを使ってオブジェクトに変換しないと
でもO/Rマッパー使うの常識だよね？ >>18
使ってるけど、getterとsetterがあるだけのオブジェクトをサービスでごにょごにょしてる
サービスにロジックがある >Javaの開発案件がたちまちクソの山になるのはそれがオブジェクト指向だから
有る意味それは合っている
でもそれはあくまで
オブジェクト指向を効果的に使うのが難しいからで
オブジェクト指向そのものが駄目な訳ではない
効果的に使うのが難しいのは
どの様に効果的に使うか?
という方法論やセオリーが十分教範として出来上がっていない
と言うのが原因だと自分は思っている
そういう教範がそのうち出来るだろう
と思っていたけど
現実には未だもって出来ていないみたい
その辺が効果的に使う事を難しくしている
自分も完全には理解していないけど
部分的に使うだけでも効果が有って
これを完全に使いこなしたら
どれ程の物なんだろうか?
と有る意味期待をしている
自分はこのスレを通す事で
オブジェクト指向プログラミングの何が解り難いのか?
という部分がはっきりして
何らかの教範が出来る材料になればいいんじゃないかなぁ
って期待している >>20
え？これだけ書いて何も中身ないじゃん
お前という人間がクソ何だな
技術者辞めて農業でもやってろよ >>20のまとめ：
・オブジェクト指向は効果的に使うとすばらしい
・オブジェクト指向を効果的に使うのは難しい
・オブジェクト指向を効果的に使えるような方法論が必要だ
いや、オブジェクト指向なんて使わなきゃいいじゃん。
オブジェクト指向を使うために出てきた問題の解決方法をひねり出してイキる、まさにマッチポンプ。>>1の通りじゃんｗｗ リファクタリングを考えるなら現状オブジェクト指向しかない。 静的型付けの方がリファクタリングはやり易いけど
オブジェクト指向は関係なくない？ そりゃTDDやってるからな
テスト駆動だとリファクタリングが開発の1フェーズだよ 928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く 955 デフォルトの名無しさん 2018/11/22(木) 01:49:36.77 ID:ROOr0q+m
>>954
＞違うという理由を人に聞く前に
＞そうだという理由を述べるのが筋だろ
ならばシステムをオブジェクト単位に分ける必要性について答えておこうか。
>>951
＞オブジェクト単位に分ける工程が完全に削除できるんだから
戦神のベルトが倉庫を圧迫。仕分けましょう【DQ10】
http://okirakudq10.com/archives/53537205.html >>31
> ならばシステムをオブジェクト単位に分ける必要性について答えておこうか。
システムを複数のファイルに分ける必要性と同じでは？ ここまでオブジェクト指向のメリットなし
ﾋﾟﾛﾘﾝ♪
鉄山靠をマスターしました!←New
鉄山靠マスターしたわ OOPのやり過ぎで手続き型のアルゴリズムを書けない体質になってしまった
OOPなら5分で書ける処理をレビューに出したら仕様書に無いクラス作らないでっていわれてさ
手続き型で書き直そうとしたら4重ループにif分岐だらけの複雑なアルゴリズムになって頭が大混乱して手が止まっちゃった
結局それは破棄してOOPで書いたコードにロールバックしてメソッドを地道にインライン展開してテストを繰り返して1日かかってようやく完成した
俺みたいな頭が悪い人には手続き型は難しすぎる
OOPで物事をシンプルに簡単にわかりやすく整理しながら作らなきゃ先に進めない 例えばポリモリフィズムやるとしてもそのオブジェクトが
どこでどんな風にその多数のメソッドを利用しているか、どういう制約の元でどういうことを行うものとして
設定してるかがしっかり把握されてるクラスなんて
あんまりないわけよ。
てか実際はほとんど変更不能なほどガチガチに暗黙の仮定が置かれてるのにドキュメントがなかったり
コードから把握するのが困難なコードばっかりだったりする。
こういうのが当たり前の状況では役には立たんな。
そして信者が次にいうのはそういう風に作った奴が悪いって話になる。
一理はあるが上記のような暗黙の仮定が注入されやすいというのはオブジェクト指向だからってのは多いにあると思ってる。 具体的にはメソッドの呼び出し制限が不明だよね
init呼ぶ前に呼んでおかないと駄目
init呼んでから出ないと駄目 オブジェクト指向の問題じゃなくて静的型付けの問題だろう 話をまとめると、オブジェクト指向をやるには
しっかりテストしてないとだめということかな？ オブジェクト指向じゃないプロジェクト
例えばCOBOLなんかだと、
どこでどんなふうに関数が使われているか
わからなくても、大丈夫って話をしているようだ
それが何故なのかさっぱりわからないので
理由を教えてくれ >>36 >>37 呼んじゃいけない状況にそもそもならないように作る
呼んじゃいけない状況で呼んだら例外を投げる
呼んじゃいけない状況を属性やドキュメントコメントに書く
オブジェクト指向はこのへんしっかりしてるから良いね
メインルーチンでグローバルの初期化関数を呼ばないとダメ
関数の呼び出し順序が暗黙に決まってる
入力範囲が決まっててそれに従わないと未定義処理
決まりごとがドキュメントコメントになってなくて分厚いマニュアルから必死になって探さないといけない
このように間違えようとしたら間違えられるのにわかりやすい説明がコードエディタから見れないという悪い構造はむしろ非オブジェクト指向の方が多い > init呼ぶ前に呼んでおかないと駄目
> init呼んでから出ないと駄目
ファイルをオープンする前にリードしたらだめ
だから手続き型は大変なんだ >>40
>どこでどんなふうに関数が使われているか
>わからなくても、大丈夫って話をしているようだ
こんな話は一切してない。
オブジェクト指向的な言語でクラスメソッドにガツガツ詰め込むようなことすると
関数的なものよりも思った以上の暗黙の仮定を置いてるコンテキストでしか動作しないものが
出来上がりやすいと言ってる。 >>41
コードのみで必要情報を示せないからドキュメントに逃げてるだけ。
「ドキュメントも完備しててすばらしい」←あるべき姿
「ドキュメントがないと使い物にならない」←オブジェクト指向の現実
オブジェクト指向によって、ドキュメントがないと使い物にならない状況を生み出す（マッチ）
ドキュメントを必須不可欠のものとする（ポンプ）
無理にオブジェクト指向に拘らなければ存在しなかった問題なのだ。
まーたマッチポンプｗ 手続き型の反対は宣言型だが、オブジェクト指向は宣言型ではない。 228 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ﾜｯﾁｮｲ e3bd-rVsz [60.146.119.215]) sage 2018/11/24(土) 08:38:58.23 ID:radxgJ6W0
蠍ｽﾚから来た
ﾗｸﾞあるのは事実だから､支える技術本まで買ったが､内容薄すぎていまいちだった
早い話､負荷ﾃｽﾄをやっとらんだけやろ
開発用サーバでテストプレイヤー分だけの負荷かけるだけなら、そらヌルヌル動くわな
ping値数msec差の問題よりも、任天堂ハードの処理速度のが問題
せめて提案者は自身の環境くらい書けよ
高スペックPC+有線IPoEとかならあきらかに鯖のメモリ解放失敗とかやろ
実際の環境でって、仮に一部のバトル用サーバ切り離して(できるかしらんが)テストしたところで小負荷なら同じことやろ >>44
逆なんだよね
分厚いドキュメントが必要なのは非オブジェクト指向の方だよ
守らなきゃならないルールを表現するためにいろいろな言語機能が発達したんだよ
例えばカプセル化やインターフェースね
だからオブジェクト指向はドキュメントにそれほど頼らなくても開発できるんだ >>42
でも引数にオープンしないと手に入らないものが必要だろう？
でもオブジェクト指向言語は違うよね？ オブジェクト指向オンリーは害悪だが用法容量を守れば便利 オブジェクト指向はクラスの中にコードを書く、というのが神髄である。 クラスはオブジェクト指向の必須要素ではない。
神髄とやらはオブジェクト指向と関係なかったｗｗｗｗｗ >>43
> オブジェクト指向的な言語でクラスメソッドにガツガツ詰め込むようなことすると
> 関数的なものよりも思った以上の暗黙の仮定を置いてるコンテキストでしか動作しないものが
> 出来上がりやすいと言ってる。
お前が言った所でなんの信頼性もないよｗ
まず、そんなことにならない。
お前が下手なだけ オブジェクト指向への批判は、
「それと同じことを非オブジェクト指向でやっても
同じことが起きるよね」で全て反論できる そりゃそうだ
それを言語仕様レベルで規定しているから楽なんだろうが 611 名無し三等兵 (ﾜｯﾁｮｲ 7fe7-t9Bb) sage 2018/11/22(木) 12:46:59.97 ID:vFEoyYoC0
>>587
「ちんちん」の語源の1つの説に、
支那の娼婦が幼児語で「入れて入れて」と言った言葉を
当時の出羽守が有難がって日本に広めたという
かなり眉唾物な故事がある。
その説に依るなら「チンポかシコシコする。」は
当然のように入れた側の所感とその転用じゃな。
591 名無し三等兵 (ｽｯｯﾌﾟ Sd1f-hEn1) sage 2018/11/22(木) 12:26:55.61 ID:9IvK1JXqd
>>587
シコシコするは他動詞なので、所有者の意思とは無関係にチンポが自立行動するのであれば「イライラする」「ムラムラする」という自動詞を用いるのが正しい
644 名無し三等兵 (ｱｳｱｳｶｰ Sa87-dVyK) sage 2018/11/22(木) 13:18:34.11 ID:UNLN7beIa
>>587
「胸がドキドキする」
胸は心臓の意味で、行為者として心臓が使われているので｢心臓が拍動する｣は日本語としておかしくない。
「チンポがシコシコする」
チンポはそのままの意味で、受け手側としてチンポが使われているので｢チンポはシコシコされる｣又は｢チンポをシコシコする｣が正しい。(50字) 正方形クラスは長方形クラスを継承するべきだろうか？ オブジェクト指向＝人工知能、という新定義はどうだろうか？
オブジェクト指向と称するものの多くは、人工知能と称するものの多くは、中身が空っぽだったりする。
この現実世界にあるあらゆる概念（名詞・動詞・形容詞）をプログラミングで表現する、
それが人工知能でありかつオブジェクト指向である。
異論があるなら何なりと！ Javaなどのガベージコレクション（メモリ管理自動化機能）も、簡易な人工知能ではないのか？ ユークリッド幾何学（真か偽か不明か）の殆どはMathematicaで処理できてしまう。
しかしながらこの現実世界はそのようには出来ておらず、人工知能に出来ることはせいぜい近似値計算。
213 デフォルトの名無しさん 2018/09/24(月) 08:23:13.39 ID:Kxio7RVg
物理は大半が近似でなく、すべて近似
すべて仮説だからな、当然そうなる
近似でなければ物理学は完成してることになる
人間の認識が限界がある以上、現在の科学的方法論では、科学が完成することはない
科学はひたすらその近似の精度をあげていってるだけだからな
で、こっからが重要になるが、観測値に解釈は入らない
定量的な観測値そのまんま
物理にwhyはない、ｺﾚ常識だからな
光の速度がなんで光速度なの？ とか頭悪いｺﾄいってるのと同じなﾜｹ
観測値が光速度、それ以上の意味はないし解釈もへったくれもない
沸点はただの観測できる定量的な値の一つだからな
物理の場合、仮説をたててその他の条件となる観測値を組み合わせて関係式を作ろうとする
見方をかえれば、沸点を条件とみることもできる
頭悪い日本の文系は、自然言語処理とｺﾚが全く異なるｺﾄが分からない
自然言語処理は、自然科学とまったく異なるただの 形 而 上 学 だからな
はっきりいってな、日本の文系がやってる自然言語処理はｵｶﾙﾄに近い
その認識がないかぎり、これからも進展はない
だから今までずーっとほとんどなんの進展もなかったﾜｹだからな
日本の文系は世界的にみても哲学的な側面でもものすごい頭悪い部類といっていい
AIでﾑﾀﾞに騒いでるｱﾎとある意味そっくりだからな >>41
＞決まりごとがドキュメントコメントになってなくて分厚いマニュアルから必死になって探さないといけない
英単語を辞書式に沢山覚えていても、コトバの意味を理解していないとどうにもならんよな。
0. 外国語、特に英語、の教え方
｢読み書きは出来るが会話ができない｣というのは間違い。｢読み書き｣も出来ない
Decorative artとは、絵画、彫刻、建築を除いた家具、食器、絨毯、藍掛け、花瓶、タイル、
ドアのノッカーなど美術品と見做せるものの総称
表裏は日本語だと｢おもて｣と｢うら｣だが、漢文では｢外側｣の｢内側｣であり、｢裏｣は｢なか｣である。
コインの場合、英語ではhead & tailで、誰かの頭部の像がある方が日本語の｢おもて｣だが、tailが｢うら｣とは奇妙
http://hiroomikes20120501.blogspot.com/2014/12/20141212.html 俺はオブジェクト指向の神だ。
おまえらにはオブジェクト指向はまだ早い。
ビジュアルベーシックでもやっておれ。 >>53
下手なだけで済ませるだけいいなら別にオブジェクト指向いらんけどね。 >>65
意味不明。
下手だから、オブジェクト指向を使っても使わなくても
同じ規模のものを作ればひどいことになるって話をしてるんだが 使っても使わなくても酷いならなぜ使うのか。やはりマッチポンプでは…
>>58
平行四辺形…ひし形…
バカみたいだな。
単なるコーディングがつまらんから、って哲学的探求で遊べるように細工しただけ。
実質的な価値はない。 「下手なら」使っても使わなくても酷いって言ったんだけど？
下手じゃないならオブジェクト指向のほうが良いってことだよ 上手ならオブジェクト指向なんか使わなくてもうまくやるよ センス無い人でもOOPなら努力次第でそこそこ良いコードが書ける
でも手続き型は脳のスペックが高くないと理解不能
あれは高学歴理系がパフォーマンス追求するときに使うものであって下々の凡人が使うようなものじゃない
非OOPは難しすぎる > 非OOPは難しすぎる
難しいと言うより大変なんだよな。
非オブジェクト指向で、オブジェクト指向的なことをするための
暗黙的なルールができるから、ドキュメント化されてないルールを守る必要がある 言語の進化っていうのはアセンブラの時代から
一連のコードのパターンに対して、それを明確に示す概念
名前や文法を作ることでもあった
例えば、比較命令 + 条件分岐 に対してループという名前をつけたように
そうやって名前をつけることで、一言で他の人と理解の共有が
できるようになった。
オブジェクト指向でも、一連のコードのパターンに対して
継承や多態性などという言葉ができたわけだが、
これらを使わないと、一言で説明できず
一連のコードを全て説明しなければいけなくなる OOP
思考停止すればかなーり楽なんだよな
グチャグチャのソースになって
手が付けられなくなるけど >>74
そういう人が書いた非OOPは
もっとぐちゃぐちゃ 非OOPでグチャグチャのコード書くのは
意図的にやるなど、逆に大変 手続き型だと複雑すぎて脳の容量をすぐにオーバーして思考停止しちゃう
オブジェクト指向だと簡単に理解できるから、ここがああなって、そうすればどうなるのね、なるほどなるほど、てな具合で思考がスムーズになる >>76
手続き型は全然難しくない
C++,Javaを初め流行のOOP言語は手続き型の上に成り立っている
それから、手続き型はOOPの対義語ではない >>79
継承など使う必要は全然ない
どうしてもpropertyに共通関数を使いたいならmixinでも使っときな >>80
いやめちゃくちゃ難しいよ
OOPと手続き型で同じ要件のコード書いて比較したけどOOPのが圧倒的に早く書けて高品質だった
実験が示す事実なんだから受け入れよう >>82
C++やJavaについて言えば
OOP言語のクラスscopeや継承などのOOP言語固有の書き方以外は
すべて手続き型記述になるはずだが >>83
でも事実としてOOPのほうがずっと書きやすいんだ
実際に比べたのだから疑いようがない
不思議だね C言語でもこれとか使えば
オブジェクト指向は簡単なんだろう
C 言語によるオブジェクト記述法 COOL ver.2
http://www.sage-p.com/process/cool.htm >>83
ということはクラスなどOOP固有の機能がOOP言語の書きやすさに大きく影響しているのだろうね さてどれどれ
http://www.sage-p.com/process/cool.htm#6
6. 集約の記述、継承の記述
集約の記述
継承の記述
多重継承の記述
重複継承の記述
動的継承の記述
絶句（大爆笑） >>85
それは、言っては悪いけど、
あなたがまだ初心者で
ソフトウエアの基礎分かってなくて
手続き型だろうが関数型だろうがOOPだろうが
まだまとまった規模のソフトウエアを開発したことがなくて
とんど初心者の感触的な意見で物事を決め付けて
語っているから oopのが圧倒的に簡単というのはなんか危険な匂いがするな。。
確かにちょっとしてGUIを用意するっていうのならoop系統のフレームワーク使って
てきとうに組むってのが一番楽なのかも知れんが。 >>67
いや、継承するべきではないという明らからしい結論が出ているのだが、これに即答できないなら、設計に関する書籍の一つも読んだことが無いのだから、議論の前にサーベイが必要かも。 >>90
それは、言っては悪いけど、
あなたがまだ初心者で
OOPの基礎分かってなくて
動的型だろうがライブプログラミングだろうがイメージベースだろうが
まだまとまった規模のソフトウエアを開発したことがなくて
とんど初心者の感触的な意見で物事を決め付けて
語っているから つまり
雑魚でも業務システムを安全に組めるのがOOP
玄人にしか使えないのが手続き型
ということですね >>94
人の問題と、技術の問題を別々に考えると、
人は玄人の方が凄い（当たり前）
技術はOOPの方が凄い
ってことにならないか？ >>95
雑魚にも使えるからと言って、玄人にも使いやすいかというと、そうとも限らないと思う 玄人もみんなOOP使ってる
アンチOOPは一部の変な人しか居ない
組み込みなど仕方なく手続き型を使うことはあるけど
好んで使う人は滅多にない
統計が示す事実なので受け入れよう >>96
そうとは限らないけど、オブジェクト指向に限っては
玄人にとっても使いやすいね メソッドの呼び出し順番がわからないのは玄人仕様なのか？
単に欠陥品にしか見えんが >>102
だからメソッドの呼び出し順番ってなんですか？って
聞いてるんだが？OpenCLを例に教えてください オブジェクト指向以外でプログラム書けと言われてもどう書けばいいかわからない ■ このスレッドは過去ログ倉庫に格納されています
