オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>650
方法論ってなにがほしいのか知らんが、
関数型言語で作ったライブラリは状態を持たないから
汎用的な関数ライブラリになる。
それを便利にオブジェクトで使用する オブジェクト指向のメリットは説明できたかい？
定期的に貼らないと関係ないこと主張する奴がわくからな
これが説明できないならクソ オブジェクト指向のメリットは状態を
簡潔にわかりやすく持たせることができる
アルゴリズムならともかくシステムから
状態をなくすのは不可能なので
それをどれだけ直感的に扱うか不可欠になる
それが関数型に対するオブジェクト指向のメリット OOPのメリットを教えてくれる奴なんていくらでもいたよな
それでOOPが普及して
ふと気付いたらメリットが何だったのか思い出せない
ここでまたメリットを教えられても無限にループするだけだ >>656
そう。3歳の子供でも、リンゴとミカンの色や形
犬や猫の鳴き声の違いぐらいわかるだろう。
それぐれいオブジェクト指向は人間の思考と一致している 型クラス、クラスscope、オブジェクトscope,
同じ名前の多態(振る舞いの違い)、
継承によるあっちこっちに無難格納したソースファイルの
似たmethon部分の短冊のような共有による依存性のジャングル
これらについて理論的、科学的に有効性を述べないとだめだよ そう、そしてそれらがある程度規模の大きく複雑な
アプリケーションレイヤのソフトウエアの構造表現として
どう有効なのか理論的、科学的に述べないと… 確実にメリットがあるなら人には教えないで独占する
それが理論的で合理的
確実ではないギャンブルなら人に教える ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる
ｵﾏｴも含めてな たまに見るけど100%でない=0%の人の思考はどうなってんだろうね 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる 1bit思考の中で最悪なのは、需要と供給
買う方が100%自己責任と思ってるから売ってる側は罪悪感0 その論点から起こしてだね、
オブジェクト指向の有効性を非論理的、寝技的に布教しようとするのは
いくらなんでももう、無理があるよ ここの議論でもそうだけどカプセル化とかインターフェイスに対するプログラミングとか
ここの要素について話すのは意味があるが
「オブジェクト指向」って言葉でまとめると途端にクソ議論になる。
その意味ではやっぱり失敗だろう。 >>672
その辺はポジティブな意味合いが強いからな
ただメリットがあるからってデメリットがどうなるかは別問題として カプセル化とかは「学習コスト」だから100%ネガティブ
コストを消費する代わりに何かメリットがないとポジティブどころか中立にもならねえ 今になって思うのは、オブジェクト指向にまつわる説明で特徴的な何々は何々であるだから何々があるはずだ的な事は製作者側の考え方の根本だったんだろうな。
ここに共感してないから触ってても疑問がつきまとう。
それでもってこういう考え方をする奴は布教的な奴が多い。こういう奴らは本当本当に嫌いだわ。人のその後に対する考えなんてみじんも無い。
例えばウェブ上で人気の言語的なランキングで上位に入ってる言語と周りを見渡して実際触られる言語の食い違いがひどい。
他の奴の意見見てると大体同じ感覚で変な笑いがでる。 オブジェクト指向の宗教的側面と、Rubyの宗教的側面がかけ合わさって
ドン引きするレベルの狂信者が出現した
もはや言語は死につつあるのに狂信者は毎日板を荒らし回ってる >>674
学習コストはなんにでも適用できる
一般的すぎて無視できる
プログラムを作るにはカロリーを消費すると
言うようなもの、そらそうだで終わり カプセル化してしてデータを閉じ込めることこそ
オブジェクト指向の真髄、データに対する責務を
集約する事でプログラムを作りやすく堅牢で
メンテナンスしやすくできる >>678
コストがあるから見返りにメリットが必要だったんだが
コストを無視するならもうメリットがあってもなくてもいいぞ >>680
一般論過ぎてオブジェクト指向の話になってないやん 赤信号なら止まると良いぞと言ってるようなもの
当たり前やん オブジェクト指向テクニックを使うと外から壊されにくい
堅牢なデータ構造を作ることができてプログラムの
完全性を保証できる、オブジェクトを組み合わせて
より大きなプログラムを作れるっていうのが
オブジェクト指向のメリット 当たり前すぎるってあれだよな
反証不可能ってやつ
反証したい勢力と対立煽りするくらいがちょうどいいんだよな データ隠蔽が有害っていうのは嘘だ
データは隠してなんぼ、オブジェクトを使う側に
データの存在を意識させないようにする事で堅牢な
プログラムを構築できる 大規模開発はオブジェクト志向が、
とか喧伝する低偏差値信者もおとなしくなり、
一歩下がって、そんなに良いものだったっけ？と振り帰られる雰囲気がでてきたのは良いこと
いつまでも熱狂信者の思惑通りにはいかないよ
時がたてば、本当にコストペイするものだけが生き残る >>685
テストもできないのが不味い
結局使用する側が状態を意識しなくてもいい造りなら問題はおきない
でもinitメソッド連発で呼ばれると死ぬだろ現実
initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ
ってのが呼ぶ側の主張 >>687
> でもinitメソッド連発で呼ばれると死ぬだろ現実
> initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ
どんな場合でも初期状態に移行すればいいだけでは？ >>691
別スレッドでアクセスさせなければいいだけ >>690
でも実際はハードに近い部分のinitだったりするとそうはいかないケースがあるよね？
って可能性が想定できないなら君は設計を語るレベルにないんじゃない？ >>694
自分の都合がいい条件じゃないと当てはまらないと
認めているようなもんじゃないかｗ >>695
いやいや、この場合そういうケースがあることを説明できればいいよね >>696
じゃあそういうケース以外には当てはまらないってことでいいよね
例外中の例外なんてどうでもいいわ メソッド呼ぶほうが呼び出し順にナーバスな設計というのが糞
内部を隠蔽できてねーやんというだけのこと >>697
問題はオブジェクトが状態を内包しちゃってることなんだけど？ んでそれを踏まえて
お前のクソクラスは息してんの？
って話
レアケースだから死ぬわってお前
言ってるように聞こえるけど
バカなん？ >>689
うるせぇエビフライぶつけんぞ
,.、,､,..,､､.,､,､､..,_ ／i
;’｀;、､:、. .｀ﾞ:.:ﾞ｀’’’:,’.´ -‐i
‘、;: …: ,:. :.、..; .;;.‐’゛￣ ￣
ヽ(´･ω･)ﾉ
| /
UU >>700
オブジェクトが状態を内包するか
オブジェクトの外に状態を置くかの違いでしか無いですね >>703
だからその一点でクソだって言い続けてるじゃん
カプセル化がどうとかバカの妄想だろ
テメーの状態がわからねーのが一番のリスクなんだよ
何がカプセル化だよ
早く死ねよ localなデータを局所に隠蔽するべきなのはソフトウエア工学上、
当然のことでカプセル化の専売特許ではない。
ほぼすべての最近の言語はlocal scopeを持っている。
だがオブジェクト指向のカプセル化によるデータの内包とアクセサは
他の言語の持つモダンな階層的scopeに管理工学的にはるかに劣る。
ここ勘違いしないように。 まあ、forループの回数カウンタなんかローカルで充分だしな。 >>704
ようするにテストはプライベート変数を見たいってだけですよね？
テスト以外では必要ないですよね
カプセル化バンザイですよね？ どれくらいのアクセス度がいいかはそのクラスのそれぞれによるところはある。
STLのvectorなんて見方によってはかなりオープンだけれどあれはあれで適切な開け方。 内部の状態が心配なら
ちゃんとｸﾗｽに内部の状態を（ｺﾝﾎﾟｼﾞｼｮﾝなら当然再帰的に）ﾀﾞﾝﾌﾟする関数ぐらいつけてんだろうな
つけてないならお話にならない
外部で状態を管理して
外部で構造体を監視するのと
そう変わらない >>710
テストだけではないな
その関数が同一の結果を返す条件を固定したい
っていうかできねープログラムなんてぶっちゃけクソもいいとこだろ 仕事関係なく趣味でソフト作ったやつの意見は尊重できる。仕事だけで横文字多様してる奴のはフィルター推奨だな。 本当にそれは状態として動的に管理すべき対象なのか
十分吟味してないだろ >>716
ん？
じゃあ、クソインスタンスがどんな状態でメソッドを呼んでも絶対同じ結果返すんだな？
その時点でメンバ変数いらねーけど >>717
日本語読めるようになってからレスした方が良いよ >>713
お前は現在時刻を返す関数は一生使うなよ
クソなんだろ？ Haskellでいう副作用なら標準入出力、ファイルio、時間、ランダムなどが副作用なるな
モナド並にリッチなシステムをオブジェクト指向で組んで副作用を過敏排除するなら楽しそうやんけ >>713
> その関数が同一の結果を返す条件を固定したい
引数Aにaを入れる、引数Bにbを入れる、引数Cにcを入れる
引数A、B、Cで関数funcを呼び出す
メソッドAでaを入れる、メソッドBでbを入れる、メソッドCでcを入れる
メソッドfuncを呼び出す
関数の引数に値を入れる代わりにオブジェクトに入れるだけの違いでしか無い >>719
現在時刻しか返ってこねーだろ？
テメーのは指定してもいないのにサマータイム返すクソだろ >>721
でも入力値は使用する側が意図的に入れるものだけど
メンバ変数は何になっているかわからない
この差がデカイ >>713
>その関数が同一の結果を返す条件を固定したい
同じ条件で違う結果が返ってくる関数ってハードウェア乱数発生器とかしか思い浮かばないんだけど、具体的にこんな関数ってのある？ >>714
結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。
簡単な事を冗長的にフレームワークのようにしたコードが多くてただの社内での点数稼ぎなんだろうと伝わってくる。そして少し環境を変えてシステムを構築し直す時に問題が出て来るのって大抵そういうコードだったりする。 >>723
> でも入力値は使用する側が意図的に入れるものだけど
> メンバ変数は何になっているかわからない
変数に文字列入れたって、それがどういうフォーマットで入っているかなんてわからんだろ
文字コードは何なのか、内部エンコーディングなのか
文字列の最初に文字列長情報がついているのか
文字の終わりは\0なのか
変数に数値入れたって、それがどういうフォーマットで
入っているかなんてわからんだろ
32bitで保存されているのか、64bitなのか
変数に入れようがメソッド呼び出そうが
ある一定の手順の操作を行えば、それで状態は確定するんだよ >>725
> 結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。
あぁ、プロの将棋を素人が見ても、凄さを理解できないのと同じだな
んで、何やってるか理解できないから、直すこともできない 凄さを理解されなくても半分諦めてるプロって
ラノベ主人公でよくあるやつじゃん 素人とプラグラマーに根本的な差を感じてる奴はちょっと怪しいな。 素人だからこそ言い切れる。プログラミングって9割はツールを使いこなせるでしか無いよ。
将棋に関してもたぶん君は将棋について詳しくない人だと思うな。 ま、分かったじゃあそう思っとけ。このご時世どんなに賢ぶってもそんなに凄いプログラマーが日本に溢れてないのが透けて見えてるんだけどな。 俺もオブジェクト指向を中途半端にかじった中途半端な優等生が、
これ見よがしに作った自社製フレームワーク(全然便利ではない)しか
見たことないわ
作ったのは一流大卒の大手ベンダーの開発推進チームなんだが、
日本人ってその程度だと思うよ
Stringクラスって便利ー！ぐらいのほうが幸せになれるぞ 中途半端な優等生の成果物がその程度なんだから、
三流大卒のおまいらの成果物なんて推して知るべくだよな プログラミングセンスと学力ランキングは比例しないんだよなぁ むしろ個人の性格の方がそのまんま実装に現れて来るからな。 学力ランキングを批判するだけなら良いぞ
だが、学力の対案は性格っていうのがダメだ
おかしな対案を出すより何も出さない方がマシ >>736
分かる必要がないよね。
どうせ関数型だって内部メモリの構造なんてわからないんだから >>733
大手企業のフレームワークは派遣さんがアホなことをしないようにあえて機能を制限してる
生産性が多少犠牲になっても非常識な派遣さんがやらかしてしまうリスクを減らすことが重要と考えたんだね
そういう意味ではオブジェクト指向の基本であるカプセル化は非常に役に立っていると言える >>741
なら派遣を使うことがリスクなのでそれをやめればいいと思います。
本当のリスクは・・・無理なコスト削減なのでは？
コスト削減のために、無駄なコストをかける。
うーん、馬鹿なのでしょうね 既存のフレームワークにケチつけたい人は
それ以上のものを作れる人なの？
それとも、作れないし作ったことも無いけどケチつけたい人なの？
煽りじゃなくて純粋な疑問
ぜひ、小学生のような瞳をしてそっと教えて欲しい それを教えないのが正義っていうのが情報隠蔽、カプセル化 >>742
派遣さんを切ったら中抜きで稼いでる人達が困る
派遣さんは使う、でもバカな真似はやらせたくない
このバランスが大事 最近は中抜きはまだまともな行為だと思えてきた。
バカがクソみたいな意見押し通してくるよりマシだ。
そういう意味でベイシックインカム賛成。 >>747
結局、中抜きで困るからっていうのが本当の理由なのね（笑） >>740
え？グローバル変数使わなければ戻り値か引数が全てだけど？ ■ このスレッドは過去ログ倉庫に格納されています
