オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 手続き型言語で取り返しのつかない設計ミスって結構あったんだよ
そういう部分でオブジェクト指向には意味があると思うんだけどな
とりあえずデザパタどおりにしとけば何とかなる的な あんたあちこちで毎日こんなレスばっかかいてるね
いろんな人がいるなこの世には
543 名前：デフォルトの名無しさん[] 投稿日：2018/10/08(月) 00:05:22.29 ID:SHTmPUE+
と低学歴知恵遅れの底辺がいってもな
567 名前：デフォルトの名無しさん[] 投稿日：2018/10/08(月) 01:12:22.52 ID:SHTmPUE+
ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな
569 名前：デフォルトの名無しさん[] 投稿日：2018/10/08(月) 01:14:58.10 ID:SHTmPUE+
低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな
ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ >>571 は ID:SHTmPUE+ 宛
念のため
>>570
デザパタとか言うけどsingletonとか後論されつくしている通り
糞だぞ この必死さ
自己評価だけは高い低学歴知恵遅れで底辺にありがち
低学歴知恵遅れで底辺であるからこそそうであるといえることが、
同様のｻﾝﾌﾟﾙをみるにつけ、最近段々と経験から分かるようになってきた
残念なことにすぐに分かっちゃう 人間が持つ分類の概念が似ているもの、GUIとか、そのサブクラスで違和感なくロジックがdispatchできるものが適用範囲なんじゃね？
欧米人のように、複数のオブジェクトが協調しあうような高度、かつうまく行くようなクラス設計できるようなセンスの持ち主が日本のIT業界に割り当てられるとは思えんし、実際に出くわしたこともない
絵空事のパワポの達人にはよく出くわすけどな >>574
応用レイヤのclass設計で言うと見事と思えるものは海外にはある？ この必死さ
自己評価だけは高い低学歴知恵遅れで底辺にありがち
低学歴知恵遅れで底辺であるからこそそうであるといえることが、
同様のｻﾝﾌﾟﾙをみるにつけ、最近段々と経験から分かるようになってきた
残念なことにすぐに分かっちゃう 低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな
ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな >>576
オープンじゃないけど時価配信でObserverパターンになってるのはよく見るな
GUIだとDelphiだね、古いけど基本は同じだろう ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題 ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ
ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない
ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物
ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常軌を逸してる
ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪 だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる >>584
お前さんの今までのレスをコピペして遊んでいただけだよ ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない ID:B/yxkRYZ
ID:j/6nk0eH
ID:cRG95Xcq
ID:Kxio7RVg
ID:pq96CSzd
ID:k5h2WtG4
ID:IuTgmxg/
ID:R8M7QKDK
ID:mIq+f5AO
ID:SHTmPUE+
このｽﾚのｵﾚのﾚｽはｺﾚがすべてだ
ｵﾏｴみたいな内容のない低学歴知恵遅れと違って
たくさん有益なﾚｽをしてる
低学歴知恵遅れには理解できないし読めないのはわかる
知能に著しい欠陥があるからな 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる >>590
乙。暇だね。
これはあくまで親心で申し上げるが、頭の病院いったほうがいいレベルですよ。 ﾊﾞｶは自分がﾊﾞｶであることに気づけないからな
ｷﾁｶﾞｲには健常者がｷﾁｶﾞｲにみえるのと同じ いやなら別に病院に行かないでそのままひとり病んでてもいいけど
他人にはつくづく迷惑かけないようにね ﾊﾞｶは自分がﾊﾞｶであることに気づけない
つまりﾊﾞｶは一生治らない
まずﾊﾞｶはﾊﾞｶの自覚をもつことができない つかこんなにレスしてたんだ
ぱっとみノイズレスだと思って読んでなかった 病んでるのは間違いなくｵﾏｴだからな
低学歴知恵遅れで底辺になると発症する病気にかかってる まあｵﾏｴはｵﾂﾑの病院へいったほうがいいわ
ｵﾂﾑが壊れてる
間違いなく軽度の知的障害がある つーかいい子だからもうオナニーでもしてネナヨ
おじさんは忙しいんだから クラス単体のプログラムが出来るのは利点だと思う。
そのクラス同士のまとめが難しい ID:5FzXpRZO大発狂しちゃってるやん…
応酬見てると半角のほうがまだまともに見えてくる件ｗ
>>574
みたいに人種に原因を求めるのは実は面白いと思う
本人たちが従ってる働き方に既に問題があって
そこに疑問を持たないしどうしようとも考えない
足並みそろえて稲植えてたら収穫できるって発想
たがいの独立性や多様性をベースとした協調
直交性のあるもんを組み合わせるという日常
ってのはやっぱあちらさんに向いてるんだろうね 自由で独立した人間は因果関係に縛られないんだぜ
原因はこれだから結果は必ずこうなるとか思ってない 思い込みではなく分類
因果関係に逆らえないのはモノや動物のように扱われる
それ以外が人間 思い込みではなく分類というのは話が噛み合ってない
そういう分類があるという思い込みなんだから
思い込み or 根拠がある という話なんだから、
思い込みじゃないなら根拠を示すべき >>607
それはお前の思いこみだな
こんな糞レスへの反論なんてこれで十分なんじゃね？ いや、こういうのでいいんだよ
分類に根拠がないという意見と、OOPに根拠がないという意見は似ている >>611
だから分類の話はしてない。
> 自由で独立した人間は因果関係に縛られないんだぜ
> 原因はこれだから結果は必ずこうなるとか思ってない
↑これが思い込みだって話をしている どや？ 話をずらそうとしても、毎回戻されるのって苦痛やろう？ｗｗｗ 半角さんは逃げてこんなスレでも足りない知識でドヤしてるんだwww GUIみたいに誰もが抽象化のイメージがわきやすいクラスと、Webフレームワークのような、使う人が継承して使えばなんとなく便利なクラスでは、抽象化のやりかたそのものが学問になりそうだよな
一般人はおとなしく継承したクラスの中に、業務ロジックを構造化プログラミングしてなさいってこった >>617
GUIの座標とか描画とか、共通関数にするよりもスーパークラスに持たせた方が共通処理と分岐処理が別れて、分岐判断の引数とか減るだろ？
別にオブジェクト志向言語じゃなくても構造体でも出来るし、事実、WindowsだってCで書かれてるけどな >>618
いや別に分岐が必要な仕様じゃないんだけど >>619
分岐が必要な仕様じゃないってことは、
分岐が必要な仕様の場合は？ >>622
なんで不分岐が必要ない仕様とか言い出したの？
自分が都合がいい例にしたかった？ｗ >>623
いや、テメーで勝手に分岐が必要なブッサイクなクラス作っておいて
それはないなと
それにクラス構造で分岐しないでくんない？
読み辛い
はっきり言ってクソ
仕様書にどんな条件で分岐してるのか書きにくい
控えめに言って死ね >>623
こういう奴がパラダイムの違いを理解しないまま書くからOOPが害悪になるんだよな windowsでは普通にｲﾍﾞﾝﾄ分岐処理でもswitch文使う
それを隠蔽化するために仮想関数にして実現するどうかは作るﾔﾂのｾﾝｽで決まる >>626
それすげーやめてほしい
こっちはテメーが作ったただでさえうんこみたいな設計書に
そう書いてあるから見に行ったのに
そのとおり作ってないとか設計書ゴミ箱に捨てんぞ糞が いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。Windowsの低レベルプログラムは。 >>628
> いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。
オブジェクト指向で作らないからそうなる MFCのメッセージマップは嫌いだった。
switchのほうが100倍分かりやすい。 MFCが出てくる前は、Cでゴリゴリ書いてたのよ
MFCが曲者っつー話はさておき、
Cでクライアントプログラムを書くわけだが、Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる >>626
＞windowsでは普通にｲﾍﾞﾝﾄ分岐処理でもswitch文使う
pedzold では終始一貫して switch なのは、ちょっとどうかな、と当時でさえ思っていました
＞それを隠蔽化するために仮想関数にして実現するどうかは作るﾔﾂのｾﾝｽで決まる
今思うに、これは悪手なのではないかと >>631
＞Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる
それ、今でもよくわからないですね
::RegisterClass() ってコンストラクタに該当するのですか？なぜ ::CreateWindow() とは別に定義したのでしょうか？私はこの二つはラッピングしちゃってます… WindowsをCで書くわけにはいまさら中々いかないだろう。
かといってgcのある言語やインタプリタのようにアプリ寄りの言語で書くのは不可能だろ。
そうやってnative codeを出せかつOSの記述も(苦労するが何とか)記述可能な言語は
消去法でC++しかなくなる。DとかRustじゃ無理。
また、Windowsと言う位だから、上位には何らかのOOP GUI IFを提供しなければならない。
別にC++のOOP機能が優れていたからWindowsがC++が記述されたわけではない。
ここ勘違いしないように。 WindowsがOOそのものの思想、と言うのはハンドルまみれなAPI群があるので素直に同意できないけど、ウィンドウ周りは多少は頑張った感あるよね。
>>633
ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時にメモリが節約できるというメリットがあるかと。 シグナルが何とかならないかと思うけど
atomとかもう使いたくない >>526さんへ
示された所じゃなくて
その下に有ったリンク先を読んで解った事が有った
https://qiita.com/hiruberuto/items/26a813ab2b188ca39019
読んでいて何が自分に難しいのか?
関数型の場合
処理対象全域を考えて関数で並ぶように作らないといけない
副作用やその他の物を一時に頭に入れて整理し無いといけない
(リンク先にはそうではないと書かれているが自分にはそう見える)
けどオブジェクト指向の場合
対象となる処理を分割して個々に作っていく
分割して個々に作っていった物を連携させて
最終的にはその集合体が出来上がれば機能する
という方が自分に向いている
頭が悪い人間と言うのは広く色んな要素が一編に出て来る物の状態を正確に把握して
それを組み立てる
というのが苦手なのよ
関数型プログラミングは間違いなく
使える人が限られる
そういう物になるだろあなぁ
でもc++なんかでも標準ライブラリーに既にそれっぽいのが有るから
使える程度には理解しないといけなくなるんだろうねぇ
その程度ならなんとかなるかなぁ(笑)
何にしても参考になりました >>637
バカじゃん
テメー以外の奴が作ったときに
privateにされたらそれでしめーだろーが
そういう当たり前の想像力が欠落してるからテメーは何考えても
ダメダメのうんこちゃんなんだよ メソッド呼ぶたびにクソクラスの内部のウンコがどうなってるのか
ケツアナほじって掻き出さなきゃいけねーんだよ 標準ライブラリのprivateメソッドとか
もうソースコード読みまくりだからな >>635
＞ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時に
同じウィンドウクラスを使いまわすっていうのが、そういうことをやる機会があるかどうか、という点でいまいち、なんです
つまり現状のウインドウクラスにてウィンドウプロシージャを設定する、というのが疑問でして、ウィンドウプロシージャが ::CreateWindow() の引数だったら、使いまわす、ってことも検討したかもしれませんが >>637
foreach, map, reduce, filter などを使うことによって、
for ループやif分岐や一時変数を使う助長で古典的な書き方から脱却し
リストの要素間の多対応・変換を宣言的に記述し切っていく、
既存言語に拡張されつつある関数プログラミングパラダイムの
限定的でも美味しいとこ取り的な使い方からはじめても全然いいんジャマイカ あと、詳しく書くと長くなるので一言ずつ書くと
繰り返しではなく末尾再帰を使えるところでは活用する
クラスを設けて多様性をあらわすのではなく、クロージャーや部分適用で簡潔に表現する
遅延評価や関数変換を使って有効なところで使う
とか 関数型とオブジェクト指向は実は相性がよくて、
オブジェクト指向でオブジェクトとしての構造を
そしてオブジェクト指向の中で使う関数は関数型と
組み合わせて使うのが最強なんだ >>644
だからそれはレイヤやグレインの観点から上手くいかないんじゃないかって
上で書いたのに。
上手くいく方法があったら披露してよ 末尾再帰の話が出てきたから、知識の浅い人に説明しておくと
関数型は再帰で実装するから手続き型のループを使う方法よりも遅いという常識を
特定の条件を満たしている場合にループに変換することで、遅くならない
というもの。決してループよりも速くなるわけではない >>645
何ができたらうまくいくってことになるんだ？
俺にとっては開発が楽になることがうまくいくことだ
楽になってるのでうまくいっている >>644
あとcontinuationとかyieldとか使うと幸せになることがたまにあるぜよ >>647
何の言語で何をどう作ってんだか知らないが
上手く言っているなら方法論を披露プリーズ >>650
方法論ってなにがほしいのか知らんが、
関数型言語で作ったライブラリは状態を持たないから
汎用的な関数ライブラリになる。
それを便利にオブジェクトで使用する オブジェクト指向のメリットは説明できたかい？
定期的に貼らないと関係ないこと主張する奴がわくからな
これが説明できないならクソ オブジェクト指向のメリットは状態を
簡潔にわかりやすく持たせることができる
アルゴリズムならともかくシステムから
状態をなくすのは不可能なので
それをどれだけ直感的に扱うか不可欠になる
それが関数型に対するオブジェクト指向のメリット OOPのメリットを教えてくれる奴なんていくらでもいたよな
それでOOPが普及して
ふと気付いたらメリットが何だったのか思い出せない
ここでまたメリットを教えられても無限にループするだけだ >>656
そう。3歳の子供でも、リンゴとミカンの色や形
犬や猫の鳴き声の違いぐらいわかるだろう。
それぐれいオブジェクト指向は人間の思考と一致している 型クラス、クラスscope、オブジェクトscope,
同じ名前の多態(振る舞いの違い)、
継承によるあっちこっちに無難格納したソースファイルの
似たmethon部分の短冊のような共有による依存性のジャングル
これらについて理論的、科学的に有効性を述べないとだめだよ そう、そしてそれらがある程度規模の大きく複雑な
アプリケーションレイヤのソフトウエアの構造表現として
どう有効なのか理論的、科学的に述べないと… 確実にメリットがあるなら人には教えないで独占する
それが理論的で合理的
確実ではないギャンブルなら人に教える ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな たまに見るけど100%でない=0%の人の思考はどうなってんだろうね 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる ■ このスレッドは過去ログ倉庫に格納されています
