オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 これがオブジェクト指向を吹聴していた者たちの反論か…
科学的工学的有効性のかけらも無い >>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を語るなっつーの
それなりに名が売れてる人以外、講釈垂れ禁止にしたいよね そしたら日本にいないぞ
>>540 も >>541 も 論外、対象外だし
おれはそもそもOOの講釈をたれたことは無いので自由だ。 日本人がプログラミングで実績残せないのはなぜだろうと思うけど
(まつもとゆきひろとか神レベルを除く)
講釈垂れは、１億円程度の案件でも沸いてくるんだわ
しかもたいていＦランとか専門卒の地頭の悪さを自認できない語り部
俺のガンダムはさー、とか言い出す小学生と変わらんのよ そういう非論理的揚げ足取り未満のレスが着き始めると
ああ、OOP信者はねた切れなのかあるいは
そもそも何か問題のある人たちだったとつくづく思う 細かいところの揚げ足取りで、議論になり得ないのも底辺の特徴ね
なので2ちゃん５ちゃんみたいな底辺８割の落書きでOOのメリットデメリットが議論できるわけがない
数年前はちょっと期待してたけど そうだけどそれでも決して悪いことではないと思う。
別に理想の場をもとめて誰もきているわけじゃない
しかしその一方、これもひとつの社会の縮図で
そのなかで自分も生きていくことには変わりは無い が、しかしだ。
オブジェクト指向ってのは実はクソだったと思う。
そして講釈をたれて変なオブジェクト指向を吹聴していた奴らはクソだった。
これは変わりない。 新しいものを無条件に礼讃するのはヲタの特徴だからしかたがない
問題なのはそれを実業に持ち込むバカと語り部がいることなんだよ
この業界は敷居が低いからヲタの比率が高くなりがちで、困るのは自己顕示欲が大勢な新しモノ知ってるぞヲタ このスレはレッテル張りばかりで中身のないレスが多いな 日本のIT産業産業全体にいえることじゃん。
いま世界で絶賛ぼろ負け中だけど。
やITに限らない、はば広くぼろ負け中。絶賛衰退中。
OOP現象も同じだと思うんだよ。
純粋な技術的問題じゃないんだよね、社会的問題というか、人の問題というか。
CMMIもISO9000も 俺もこの業界に長くいて新三大嫌悪感があるのが、多重請負、ISOとか監査もの、OOやDIの語り部
どれもこれも欧米被れというか、日本人が背伸びして、品質と生産性を落としてるだけだわ
そういえば技術じゃなくて社会的な問題かもね 腹黒い奴がどう他人を操るかの手法として利用されてきたか側面はあると思う
洩れの周りでの話だけれど、OOPのカプセル化、getter/setter、
継承による(後付の)コード再利用性による開発量削減・コスト低減を社内でうたい始めた奴は
実は自分ではコードは書けず無論設計は出来ず、マネージメントもできず、忖度と口先でしのいできて
くいっぱぐれるまえにJavaの流行を察知して社内OOP論者になり、布教に励み
それが下火になるとCMMI,IPISOの流行にのってQA論者に衣替えした それにさんざだまされてうっかりJava信者になって
いまも問題点に気がつかず変なコード書いてる、あるいは部下や外注さんに強要して
迷惑がられている奴ら多数
これを暗黒時代と言わずしてなんというのだろうか んなこたどうでもいい。
結論
オブジェクト指向はクソだった
都市伝説みたいな迷信だった。
沢山の人がだまされた
以上。 つぎに
関数型はクソだった
って言うｽﾚが建てば一過言あんだけれどもな… OOPに批判的な奴は最初から一定数いたよな
ちょろい奴を操る手法もまあ腹黒いが、批判を無力化する手法の方がもっと腹黒い 俺の会社では語り部は淘汰されたけど、糞コードは負の遺産として急には捨てられなくて困ってる
ロジックをトレースしづらいだけの継承とか、呼び出し順が分かりにくいだけのテンプレートメソッドとか、背伸びしまくりの知ったかぶりOO OOPって、それじゃあ全然ﾀﾞﾒだったかというとそうでもなくて
頑張ればそれを使って(向いてないレイヤ・アプリでも)何とかソフトウエアを構成できたんだよ。
それはgotoを乱用してもがんばれば何とかソフトウエアを構成できたのと実は大差ないことだと
俺は思っているんだけれど。
それが厄介ごとの元。
上手くいかなかったときはOOPの理解が足りないからだとか、
低学歴には無理ｗとか批判されて、
そう、自分ではまともなコードををかけない奴に批判される
一体OOPは何のための手法なんだろうか ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな ■ このスレッドは過去ログ倉庫に格納されています
