オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 オブジェクト指向とは何で
何が良くて
何が悪くて
そしてどうしたらよかったのかとか
纏められるといいんだけれどもねえ 目的指向というよりも
手段指向というか方法論指向で始終しちゃって
明後日の方向に愚民を導いて
混乱をもたらしたのは
なんともむなしい 日本の失われた20年とちょうど時期が重なる
日本のITの暗黒時代 >>441
手強いよ
さらに誰に金もらってるのか
特定の言語や商品の悪評を流すことを目的としてるから 260はいい記事やったけど402はイマイチやったな。てか全部読んでないけど 邪魔する奴の中に
単純に自分を有利にしておきたいから他人が自分の居るレベルまでこれ無い様に邪魔をする
という奴も居るからな
相対的な位置で報酬は決まるから他人を蹴落とす
というのを息をするようにやる奴がかなり居る
全体が進展するより停滞させて自分だけ有利にしようとする下劣な奴が結構居る
教育を変える必要が有るのに今のままでいい
とか言ってる奴もそういう連中 >>412
stackoverflow.comって初めて知ったわ。
teratailよりいい？ >>448
teratailなんて比較対象にすらならない まさか日本語版とかいうゴミ見てるんじゃないだろうな…まさかな… 英語版なんて読めないよ・・・
コードはなんとなくわかるが質問文が >>444
その時期に書かれたコードでOOPを正しく実践してるものなんて見たこと無い
OOPが悪いのではなくOOPじゃなかったから悪いということになるな 海外でHelp me, Stackoverflow. You’re my only hope.って書かれたTシャツ着たやつ見るくらい >>454
今なら正しくOOPを実践してるコードばかりなの？
そもそも正しいOOPってどんなものなの？
第一デザパタは前の方がさかんに取りざたされていたじゃない。
振り返って今だからこそ分かるんじゃじゃないの？
世に流布していたOOPはくそコードを量産した元になったと。 我々はね、間違うのよ
だいたいのことを間違うの
OOPだから糞コードになったんじゃなくて
OOP関係なく、糞コードにしかならないの
その一点についてすら自覚が無いの main関数から始まるc++はオブジェクト指向か？
（オブジェクト指向をちっとも理解してないものの意見です） >>459
C++はオブジェクト指向（をサポートした）言語だよ
Cと違って継承や多態の機能が標準であるでしょ？
今からふり返ると中途半端な部分もあるけど
ただそのC++を使って書いたコードが
オブジェクト指向らしく書けているかは別の話
OOPとOOA（D）の違い >>458
OOPの弊害について議論して来たのに
「OOP関係なく、糞コードにしかならない」と言われると、
OOPは糞コードの元となる害なかった無関係だと暗にほのめかしているようで
論点をすり替えてずるくごまかされたような印象を受けるよ OOPが原因で糞コードになるんなら
どうすればいいか一目瞭然じゃん
よかったな世界が平和になって 本当はいいものとなる筈だったのに、
ボタンを掛け違えたのか、変な使い方が一人歩きして普及しちゃったというか
なんというか、、、
最近は継承を廃止したり
他のパラダイムも併せた言語がどんどん出てきて
より良い解はいっぱい出て来るでしょう んなもん使い方しだいにきまっとろうが
基本的に依存が込み入る元なので
十分静的に設計し尽くしてよほど律して使用するならともかく
変なテクニックを披露するため乱用したら害だろうな
悲惨だわ 関数型の弊害の話をしたら必然的にオブジェクト指向の弊害の話になると思うの これがオブジェクト指向を吹聴していた者たちの反論か…
科学的工学的有効性のかけらも無い >>469
アアン!?
何ガン飛ばしてんじゃコラァ!
みたいなやり取りばっかだよねｗ >>467
オブジェクト指向と関数型に何の関係があるんだ？ >>472
プログラミングパラダイムという同じ上位概念を持つ
関係があるやろ >>473
その理屈だと、むしろ無関係なもの探す方が難しいなw クソとか言っている人間の方がよっぽど
>科学的工学的有効性のかけらも無い
と思うけど べつにオブジェクト指向の概念は関数で実装しなくてもいいんだよ？
メッセージでもいいしな。 OcamlやF#のようにオブジェクト指向と関数型パラダイムを合わせて持つ言語もあるが、
内容は覚えていないけど本質的・理論的にはこの二つのパラダイムは相反するものだと聞いている。
確かに局所的、ミクロに上手くかかれた関数型の呼び出しは
型クラスのような複合構造の使う余地はもはや無く、自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
相反するのもうなずける話だと思っている。
OcamlやF#は詳しくないがどのレイヤでオブジェクト指向と関数型を使うかが分かれるんじゃないかな
numpyで関数の返り値が気がつくと内部クラスのオブジェクトになってた、みたいな。 >自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
この辺が気になる
オブジェクト指向プログラミングの場合は
クラス内に操作対象(変数)を封じ込めてクラス外からアクセス出来ないようにして
グローバル変数が各所からアクセスされることで無限のアクセスパターンになるというのを避けている
というのが肝なんだと自分は思ってるんだけど
関数プログラミングは難しくてさっぱり且つ入門もまともにやった事ないんだけど
状態なんかを副作用?とか呼んでなるだけ外に出す
という方法で対処する
みたいだそうなんだけど?
その辺どうなんだろうか?
少し上の方にその話になりそうな流れが有って少し期待してたんだけど
違う方向に流れたようで残念だったんだけど >>479
俺の書ける範囲で述べると、
身近な局所変数＞一層外側のブロックの内部変数＞。。。＞大外側の大域変数
というスコープ階層は知ってるよね？
これに加えて関数呼び出しの階層
特に相似的階層構造の再帰で自然に繰り返しの表現（最終的には末尾再帰を
最適化で単純なloopに変換したコードが生成されるのだけれども)
この論理的（≠物理的）関数呼び出し階層構造では、
各階層における引数リストと返り値リストの相似的階層構造が
型クラスとその継承や委譲による階層構造のようなランダムで管理しにくいﾈｯﾄワーク構造としなくても
管理しやすい入れ子のスコープおよびエクステントの階層構造としてメモリ上に構築し自然に
アクセスできるイメージ
これで伝わるかな… >>480
lexical scope・extentと
関数呼び出し階層のネスト・木構造
で複雑なデータ構造の関連性が自然に細分化できる
同時に処理の細分化も速やかにできる
勉強している人にはこれで伝わると思う
型クラスとかアクセサでカプセルかとか継承とか全いらない 関数型というかHaskellのええ所は>>260でいうパーツの切り分けが強制的になる所もあるよな
全てパターンマッチのワンライナーで関数が細かくブツ切りで出来るから後の編集しやすい ただまぁ万能ではなく、
別の弱点(副作用のｱﾙ処理の扱い、学習コスト含む)
もあるので俺はfunctionalﾏﾝｾｰではないけれど 多態性についても文句あんだよねおれは。
あんあもの動的言語ではそもそも意識する必要も無い空気みたいなもの
それを変に応用して話をややこしくして…
まあ別途機会があれば書くかもしれないけれど。
かかないかおもしれない。
あどオブジェクト指向とその変な一時的流行で迷惑したのは
非科学的で誤ったオブジェクト指向論を信条として、それを宗教のように吹いてまわり
周りに強制し、反論すれば非難。でも自分ではたいしたソリューションのためのソフト開発できない
みたいな工程論・方法論者が跋扈して
開発者を煩わせたこと 書籍も全部一色だったし
MSが金出してただろうししゃーない
雑誌社も何の根拠もないのにオブジェクト指向マンセーだったよね
本当に技術を見定める能力があればそれが詐欺であると気づいたんだろうな
多くの人間はそうでは無かった 本当に有効な機能だけ自律して使えば有効な面もあったかもしれないけど
人間てそんなに器用じゃないし
群衆や社会問題って
チコちゃんの言う氷河期からそんなものだったのかもしれない 今でもオブジェクト指向からDNNやAiにステージを移して
同じようなことが続いている でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
ソフトウエアの構造を表現している。そしてすごいスピードでreviseする。
べらぼうな才能と手間と時間をかけてクラスベースOOPでソフトウエアを表現しようとしている
あれは(個人的に好きではないけど)見事だとうなってしまう。
優秀な者が活躍して、採用したパラダイムが茨の道に密だとしてある水準まで力強く構築しようとしていると思う。
翻って上のレスで揚げたような日の本のオブジェクト方法論指向論者は
なんと
プアーなことか
同じOOPでも同列にみなしてはいけないんだろうな ちなみにpythonの言語仕様自体は
涙なくして語れないほどのクソだと俺は思っている
なんか文句あるか？
＿＿_
／ ＼
／ ─ ─ ＼
／ （●） （●） ＼
| （__人__） | ＜かかってこいよ
,.ﾞ-‐- ､ ｀⌒´ ,／ おらー
┌､. / ヽ ー‐ ＜.
ヽ.X､- ､ ,ﾉi ハ
⊂＞'">┐ヽノ〃 / ﾍ
入 ´／/ ﾉ } ,..,.._',.-ｧ
／ ｀ｰ''"´ ,' ｃ〈〈〈っ<
/ __,,..ノ ,ノヽー'"ﾉ
{ ´ / ｀`¨´
/´¨`'''‐､._ ,'＼
∨´ ｀ヽ、 ﾉ ﾞヽ
∨ ヽ _,,..-'" ｀ヽ
∨ 〈-=､.__ }
ヽ、 } ｀`７‐-. /
ヽ ﾘ /′ ノ
/′ , { / ／
{ ! ,ﾉ ,/′
! / / `‐-､
! ,/ ﾞー''' ｰ---'
', /
{ }
ﾞY ｀ヽ､
ﾞｰ--‐' pythonにprivate変数はありません。
pythonにswitch文はありません。
pythonのクラス関数はselfを第一引数に
命名規則は決められたものを守りましょう
インデントはスペース4つ
括弧の書き方でsetになったりdictになったりします
一列の文字数は79文字以内
（一部言語仕様でないのも書いてるけど）利点でもあり欠点でもあるな >>181
まとめると：
Python のオブジェクト指向はクソ >>490
一番クソなのは初期の段階でブロックとlexical scopeを配慮して言語設計しなかったこと
今でも引きずっている ID:LmyRE988
↑なんでこいつすぐポエってしまうん？ >>493
飲んで2chにポエﾑ書くことくらい大目に見なよ >>492
blockは無いし頑なに追加しようとしないけど
lexical scope な言語ではあるだろ
何か勘違いしてるんじゃない？用語の意味わかってる？ >>495
・関数の大外のfile scopeの変数を外部から参照させることが出来ない
classにする必要が無くてもclass objectを作ってclass変数とし無ければならない
・関数の内側は平坦なlocal scopeのみ、また外側の変数は参照のみ、更新できない（かった<3)
・block(てきなもの)がnestしてもscopeがnestしない
したがって関数bodyがでかくなると見えなくて良い遠くの変数を隠せない
>>492
で配慮していないと一言で言おうとしたのは
具体的にはこういった欠点 >>495
モダンな言語なら必ず備えているコードのlexicalな階層構造と
変数のscopeの階層の明確な対応が出来ているとは
とても言いがたい さて、三連休だ、旅行に行ってくるわ。
あばよ、ﾉｼ だから一言blockが無いで良いじゃん
lexical scopeは関係ない
それにpython 3だけで大抵の言語のシェアを上回ってるのに、
未だに2の批判するのも意味分からん >>496
＞>>495
＞・関数の大外のfile scopeの変数を外部から参照させることが出来ない
これ意味分からんかったわ
どういうこと？ >でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
>よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
>ソフトウエアの構造を表現している。
numpy、tensorflowがオブジェクト志向？
そんな気は全くしないんだが、定義が全く違うのかな？ それと pythonでnonlocal や global を使いたくなるケースは
根本的に設計間違ってるから、クソコード撒き散らす前に設計見直した方が良いよ >>501
numpyやtfの中のコードの事だろ
使う側は手続き型で書ける
tfは計算グラフを構築してから実行するから宣言型かもな >>501
そいつはここで気持ちよくポエりたいだけだから
レス返しても有益な情報は得られないよ
ポエ逃げしたいだけの人種だから >>503
まとめると：
・numpy や tf は C/C++ で書かれ内部はオブジェクト指向で設計された
・それらライブラリのAPIを Python は手続き的に利用している
つまりスレ的には、「Pythonのオブジェクト指向はクソ(>>181)」であると、
Python信者が認めたわけだ numpyの中身は知らんがtensorflowのどこがオブジェクト指向？
ホントにコード読んでんのかよ。。
なんか胡散臭い奴しかいねーな。。 >>506
数式を表現するのにオブジェクト指向なんていらん
行列演算したいだけなのにオブジェクト指向なんて強制されたらクソだわ
あ、数式使わないドカタの反論は不要なのでよろしく
ドカタには分からん世界があるんだよ >>508
Python信者からも賛同意見を頂けるとは嬉しい限り
・次世代言語12 Go Rust Swift Kotlin TypeScript
http://mevius.2ch.net/test/read.cgi/tech/1530664695/963/
>> 失礼な！！Python は FORTRAN/COBOL/BASIC に代表される
>> 伝統的な手続き型言語の正当な後継スクリプト言語、
>> 次世代の純粋手続き型言語です
>>
>> 関数型？オブジェクト指向？
>> そんなのは飾りです、偉い人にはそれが分からんのですよ（必死 >>480さんへ
479です
自分は関数型に関しては完全に素人なのでなかなかに難しいです
単純に受けたイメージだとなんか凄くモノリシックに大きくなってしまいそう見えてしまう
関数型って何時もどういう風に制御するのか解らないなぁという感じで
基本的に難しい物なので自分には理解できないという感じなんだろうと思いつつ
今回は状態を通して何か掴めるかな?
と思いましたがそんなに甘くない感じですね
何にしても回答どうもです
関数型ってオブジェクト指向プログラミングシステムより更に難しいそうなのでオブジェクト指向より使える人が増えないような予感がします・・・ >>502
そもそも nonlocal やら global などという
スコープ宣言に限定した予約語が存在するのは
Python が(歴史上、おそらくは)唯一の存在である、
という事実を忘れてやいませんか？
言い換えると、スコープに関して Python2 以前の
新規リリースの時点から「根本的に設計を間違えていた」のがPythonなわけ
で、根本的解決を採用せず、行き当たりばったりに
nonlocal やら golobal といった泥縄式対策を採用したのがPython3 ゴローバルってなんかカッコええやん。
ゴローさん風味が出ててさ。 nonlocalってセンスがウケるなｗ
いっそのことnonglobalも用意したらどうかｗｗｗｗ オブジェクト指向のスレでなんで延々と特定言語の言語実装の話してんの？
バカなの？ OOPの結果としては
クラスライブラリとかは文句なしに使いやすいと思うんだけどね
String, Map, List, Set, Threadなんかは十分使いやすいよね？
その点を否定するやつはさすがにおらんやろ？ やっぱりクラスライブラリは使いやすいよね
文字列をポインタで操作してたCの時代に戻りたくない そうなんよね
その点で見ればOOP大成功に見える
ただ、自前でクラスやクラスライブラリを書けつったときに
とたんにゴミの山になりかねないという >>516
何と比べて？
別に同じ機能の関数あればええで >>516
使いやすいが、そこまで一般的なインターフェイスにするまで
いろんなソフトウェアの歴史があってこそなわけだ。
ユーザー定義でそのレベルのものを用意しようとすると途端に何も進まないか
クソインターフェイスをひたすら強要される現場となる。 クラス単体はオブジェクト指向だけど結局それを使うところでは手続き型にしてしまう。 ならC++のﾒｿｯﾄﾞをすべてｽﾀﾃｨｯｸで書けばいい
そうすればﾒﾝﾊﾞ変数も不要
ｽﾀﾃｨｯｸのﾒｿｯﾄﾞは当然ﾒﾝﾊﾞ変数にはｱｸｾｽできない
手続き型なら、入力の構造体と出力の構造体を関数を別で渡す程度で済むﾊｽﾞ
ｵﾌﾞｼﾞｪｸﾄの状態を常に外側で管理する必要があることになる
MS-WindowsのAPIは
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗをひとつのｵﾌﾞｼﾞｪｸﾄとみなして
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗを経由して操作や設定を行ってる
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗも一つのｵﾌﾞｼﾞｪｸﾄで入力も出力もできるｼﾛﾓﾉになってるからな UNIXｸﾛｰﾝのｼｽﾃﾑ関数にもwriteやreadがある
readやwriteはﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀを経由して
なにかしらに読んだり書いたりする関数だからな
つまりﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀをｵﾌﾞｼﾞｪｸﾄとみなして
読んだり書いたりしてるとみなしてると考えて差し支えない
ｺﾚはC++のようなｵﾌﾞｼﾞｪｸﾄ指向言語で継承して実現できる内容と同じとみなせる オッカムの剃刀の逆を地で行ってるなｗ
オブジェクト指向の何がダメか腑に落ちた気がするよ。ありがとう。 全部スタティックにするってそれ
スタティックおじさんじゃねーか！ >>511
モノリシックに大きくなってしまうという印象は杞憂。
むしろ関数呼び出を一行ずつ言い切りみたいにつらねた宣言的書き方に近づく
リスト = 関数 リスト;
リスト = 関数 関数 リスト;
...
見たいな感じ。
状態は、本当に必要なもの以外は自然に登場してこなくなりその分複雑さを低減できる感じ。
どうしても状態管理が必要な処理は、
副作用の排除された純粋な言語の場合モナドみたいな物を持ち出さなければならないかもしれないが
副作用も許容している言語では、手続き的書き方をして状態を管理する形になると思われ、
どうしても必要な状態管理の煩雑さを関数型パラダイムで根本解決できるとはｵﾚ的にはちょっと考えにくい。
難易度に関して言えば確かに学習コストは若干かかるけど、
いまはJavaやC++にもStreamやfoldなど関数型的なプログラミングのための機能が大急ぎで(かなりあせっている感じ)
取り入れられつつあるのであんまり肩肘張らないで、
ttps://qiita.com/stkdev/items/5c021d4e5d54d56b927c
https://ubiteku.oinker.me/2017/05/08/purpose-of-functional-programming/
といった導入的な情報などを参考にｍ日々の設計・開発の
局所的なコーディング範囲でもいいから使えるとことから使っていけば技術的な視野が広がるんじゃないかと思う。
ちなみに俺はそのサイトとは何の関係もないし、functionalﾏﾝｾｰではない ミドルウェアは天才が書くから天才の好む言語で書く
クライアントコードはアホが書くからアホでも分かる手続き型で書く
開発者の能力に応じて分業可能にした功績はある
だいたい天才とアホが同じ言語使ってたのが頭おかしい発想だった アホはひらがなだけ使え
漢字を使うと他のアホが読めなくなる いやレイヤーや粒度によって向き不向きな言語、パラダイムがあるってだけだろ。
天才とかアホとか関係ねーわ。
まあそういう判断しかできない奴は例外なくアホだろうけれど。 まあ例外なくアホとかいう恥ずかしい書き込みをするような奴は例外なく知的障害者だろうけど。例外なく、なｗ >>516
それらlibraryレイヤははよく練り上げられてまぁ使いやすいと思うよ。
でもよく考えてみてよ、納品を決められ短期間に仕様の策定からQAまでこなさなければならない
アプリケーションソフトウエア開発とそういった長年同じような機能のライブラリが繰り返し作り
直されてきたものは同一に論じることは無理でしょ。
それにレイヤが全然違うじゃない。
下から見れば数百個程度の機械語＞言語の文法レベル＞ｱﾙｺﾞﾘｽﾞﾑのライブラリレベル
＞それらを組み合わせ具体的なあるぴにための処理を折りませたアプリレイヤ＞…
レイヤによって全然特性が違うんだよ。適した表現手段は当然違うと俺は思う。
つまりｱﾙｺﾞﾘｽﾞﾑのライブラリレベルに適した表現手段が必ずしもその上位にある
複雑な応用レベルの表現には適しているとは言いがたいのではないかということ。(ここ伝わりにくいと思う)
これは今でも俺も日々とても悩まされている問題。でもまそれはしｚでんげんしょうみたいなものでしょうがないいんだよ。
誰も悪くないし。
本当に問題は、オブジェクト指向の名の下に非科学的非合理的で変な表現手段が流布し
（一部の人間が意図的に拡散させ）ソフトウエア開発の技術的水神をを後退させ混乱させてしまったこと。
俺はこの一点を問題視しているんだよ。
また飲みながらのポエムで悪いな。 >>533 誤記多いなｽﾏｿ
しｚでんげんしょう → 自然現象
技術的水神 → 技術的水準 >>533
大変申し訳ないが今後一切のポエムは不要ですんで分かってください >>535
そんなことよりポエムでもいいからなんか内容を書けよ
なんかむかついたのかｗ だからねえ、凡人プログラマがいきがってOOを語るなっつーの
それなりに名が売れてる人以外、講釈垂れ禁止にしたいよね ■ このスレッドは過去ログ倉庫に格納されています
