オブジェクト指向ってクソじゃね?
■ このスレッドは過去ログ倉庫に格納されています
カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約(頭文字にアンダースコアを付けるなどの命名規則)で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>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やデザインパターンやユニットテストや
フレームワークまで高級言語の仕様に含めなきゃいけない インターフェースを決め打ちにしたテンプレート作る間抜けな作りと
大してかわらないからな 使用者との合意の無いインターフェースほどクソなモンは無い
独りよがりで考えたものは全部クソなので誰にも見られないうちに捨てて欲しい 逆に言えば使用者との合意のあるインターフェースは問題ない
ということになってしまう。 >>795
あ、そうだって認めたねw
つまり、お前はインターフェースに問題があるとしようとしていたようだが、
俺はインターフェースには問題ないという話への誘導に成功したわけだ クソが余計なことをして
余計にクソなコードを生産するサイクルが途絶えることはない SEが余計なことをして
クソコードを量産することになるのは
よくある話だな DIを使わないと結合部分に余計なコードが入り乱れて大変なんだよな なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの?
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。 ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね Banana Monkey Jungle Solution
まで読んだ 結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ 現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ アクセス修飾子について分かりやすい説明しているサイトない?
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか >>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない setget時にログ出したいときに一括でできるぐらいか? >>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ
多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい >>816
色々サイトみてるけど不要論も結構あるんだよな
よくわからないけどありがとう 言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね? それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔 今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。 セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う
設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ >>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる >>821
> セットなんちゃらって書く場面を考えると
セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更 いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん
本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな ■ このスレッドは過去ログ倉庫に格納されています