オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>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
え？グローバル変数使わなければ戻り値か引数が全てだけど？ んじゃクロージャ出たから
オブジェクト指向で末端の人、要は上の誰かが作った仕組みやクラス使って自分はそこからオブジェクト弄るだけの人は可能な限りクロージャ使いまくった方がと思うんだよな
よく委譲処理でこのふたつどちらか選ぶ事あると思うんだが末端なら即クロージャ >>714
仕事は範囲が限られているからね
その仕事でやらなければならない範囲だけ出来れば
後は何が出来ようが出来まいが関係なくなるからね
一言で言えば視野が狭い
横文字を多用する人は狭い世界で通じてそれでokになっちゃってる
多種ではないし世界が兎に角狭い
実際ゲームなんかでは敵クラスを作って敵が増えるたびにオブジェクトを生成する
ってやると感覚的に凄く簡単 >>752
どんな話題が面白いの？
このスレ的にはオブジェクト指向のメリットが説明できなければ
終わりなんだけど 逆でしょ？説明されれば終わりなのがいやだから
答えが出てるのに、同じことをくり返し聞く >>756
え？メリット出てる？
見たことないよ
毎回、バカが長文書くだけで
品質向上なのか工数削減なのか、それが起こるロジックが全くの謎 犬がワン、猫がニャン
→なにそれ美味しいの？
大規模じゃないとメリット説明しにくいよ
→説明できないって、大規模なプログラムを経験して体で覚えろと？
要するに、簡単には説明できないよ
→だったら学習コストとの天秤では？
俺の中ではこんな感じ 品質向上だし工数削減にもなる
馬鹿はそこでなぜか品質向上と工数削減のために
追加作業が増えるとダメだと話を聞かない >>753
関数ポインタと汎用のvoidポインタ渡すインターフェイスより明らかに良いとは思うけど、
ガベコレない言語では上手くいかんだろ。
その場合は継承させるしかないっていうc++の選択は間違いじゃない。 ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない だいたいわかる
低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる >>762
全く解消されてないだろ。。
キャプチャーしてる変数の寿命を考慮してなきゃならんし、こんなん使わねーわ。 型の問題と寿命の問題を分離しない
OSとGUIを分離しない
フルスタックな環境を作る密結合指向って感じ >>769
その設計にオブジェクト指向が関与していると疑われている
その問題の解決にオブジェクト指向は全く寄与しない、と宣言すれば疑いは晴れる >>770
いや、どう見ても設計の機能分けの問題
オブジェクト指向の前にレイヤーってあんだろ？ オブジェクト指向信者もDI信者も同じ臭いがするね
【Java】DIコンテナって本当に便利か？
http://mevius.5ch.net/test/read.cgi/tech/1219242206/
次は何を担ぐのやら
外国で流行って育っていくのだから、それなりのメリットはあるんだろうけど、なぜか仕事では恩恵にあずかったことはない 設計のセンスの無い奴はどんな流行が来たって糞な設計しか出来ないんだよなぁ
センスがある奴はなんとなくどんな流行のスタイルでもこなして来るからなぁ どーでもいーけどコーディングの事設計てゆーのいーかげん恥ずかしくね？w は？
設計はコーディングじゃねーよw
四角い箱描いて矢印や電線で繋げて遊ぶ奴だぞ。 ある一定以下に対して理解できるような教範が出てこない
だから一部の人しか使えないようになってる
結局は出来る人の間で持て囃されるだけになってしまう
この何か新しいやり方を創造するのと一般に使えるようにする
というのは本来両輪なんだけど
普通以下の人達が使えるようになる教範を作る
というのはかなり難しい上に
それをやる人には余りメリットがないから
なかなか出てこない
だから
オブジェクト指向プログラミングにしても
関数型プログラミングにしてもその他の技術にしても
広く(普通程度以下)使われるのは難しいし
このスレのタイトルみたいな感想を持つしかなくなる
後は自分が出来るけど他の人が出来ないままのほうが出来る人には得だから妨害する
みたいなのが居るくらいだろうかねぇ あー電線繋げては遊ばないわ、危ないしw
点線の間違いだわ。 >>772
DIはほんと便利
めちゃくちゃ開発が楽になった 少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない 少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない 日銀短観のDIは便利
池沼あげのDIはtraitsなみにｳﾝｺくさい 今時DIも使いこなせない人材とか組織にとってのリスクでしか無いよ
あっちこっち結合しまくったクソコードを社内リポジトリにばらまくとか悪夢そのものじゃん DI使っても結合しまくったくそコードはくそのままだ
業務分析の時点でコケて役割分担がぐちゃぐちゃなんだからDI導入したって解決しない >>785
DIを使わないから業務分析の時点でコケて役割分担がぐちゃぐちゃになるのでは？
設計者にDIを学習させてDIを使う前提で設計させればそのあたりの分担がキレイになるように意識して設計するようになるよ cのたくさんの構造体にいっぱい変数や関数ﾎﾟｲﾝﾀもたせて
それ入力にして処理するのと同じ DIはたしかにきれいな設計になるが、めんどくて工数がかかる。
作業者にはYAGNIのほうが優先度高いから勝手に採用できない
だからそういうのはトップエンジニアが最初に管理方針としてきめとくもんだ
末端のプログラマーに責任押し付けるのは酷 今のDIはめんどすぎる
既存コードをいじらないで中身をすげかえる
もっと楽な方法はないものか DIは言語自体に組み込まれるべきもの
高級言語はどんどん高級になるべきだが
ガベコレ搭載あたりで停滞してしまったからね
本来はDIやデザインパターンやユニットテストや
フレームワークまで高級言語の仕様に含めなきゃいけない ｲﾝﾀｰﾌｪｰｽを決め打ちにしたﾃﾝﾌﾟﾚｰﾄ作る間抜けな作りと
大してかわらないからな 使用者との合意の無いインターフェースほどクソなモンは無い
独りよがりで考えたものは全部クソなので誰にも見られないうちに捨てて欲しい 逆に言えば使用者との合意のあるインターフェースは問題ない
ということになってしまう。 ■ このスレッドは過去ログ倉庫に格納されています
