オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 んじゃクロージャ出たから
オブジェクト指向で末端の人、要は上の誰かが作った仕組みやクラス使って自分はそこからオブジェクト弄るだけの人は可能な限りクロージャ使いまくった方がと思うんだよな
よく委譲処理でこのふたつどちらか選ぶ事あると思うんだが末端なら即クロージャ >>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
あ、そうだって認めたねｗ
つまり、お前はインターフェースに問題があるとしようとしていたようだが、
俺はインターフェースには問題ないという話への誘導に成功したわけだ ｸｿが余計なことをして
余計にｸｿなｺｰﾄﾞを生産するｻｲｸﾙが途絶えることはない SEが余計なことをして
クソコードを量産することになるのは
よくある話だな DIを使わないと結合部分に余計なコードが入り乱れて大変なんだよな なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの？
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。 ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね Banana Monkey Jungle Solution
まで読んだ 結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ 現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ アクセス修飾子について分かりやすい説明しているサイトない？
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか >>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない setget時にログ出したいときに一括でできるぐらいか？ >>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ
多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい >>816
色々サイトみてるけど不要論も結構あるんだよな
よくわからないけどありがとう 言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね？ それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔 今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。 セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う
設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ >>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる >>821
> セットなんちゃらって書く場面を考えると
セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更 いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん
本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな そこででてくるのがプロパティだよ
ageは属性かメソッドかといったら属性だろ？
一見属性にアクセスしているようで、内部では
いろんな処理を行って値を返す。
それがプロパティ >>825
盲点でも何でも無いよｗ
例えば、Configクラスであっても、いつの時点のConfigかわからんだろ？
一年前の設定がほしいかもしれない。 >>826
引数が渡せるプロパティじゃないとね
c#使いなんだけどｃ#は引数を渡せない 状態状態ってよく悪者にされるけどOOPの肝はのへんににあると思う
#include <iostream>
struct logger {
std::ostream *out;
logger() : out(0) {}
void p(const char *s) {
if (out) *out << s << std::endl;
}
};
void f(logger &l) {
l.p("foo");
l.p("bar");
}
int main() {
logger g;
f(g);
g.out = &std::cout;
f(g);
g.out = &std::cerr;
f(g);
return 0;
}
ログの有効無効なんかをこうやって切り替えるのって
そんなに悪いこと？ Delphiなら配列の構文で引数付きプロパティを扱えたりするが
そんなことするぐらいならpersonからはbirthdayだけ見せて
今何歳かなんて呼び出し側で勝手に計算しやがれって思うわw Nameも不変じゃないし身長体重性別だって不変じゃない
商品の値段も不変じゃない
不変のものなってまず無いだろう。
つまりは、オブジェクトの状態の過去のスナップショットを
オブジェクト自身に持たせるのが正しい設計かという話 >>831
だから>>824は時刻を引数で与えるよう提案しているわけだ。最初からそういう話
personクラスが中で勝手に現在時刻を取得してたりしたら複数インスタンスのageの基準がずれたりして
使い辛くてかなわんだろう >>833
その理屈だと結婚などでNameが変わることもあるから
Nameにも日時を与えるようにしないといけなくなる 本質は>>832に書いたとおり
> つまりは、オブジェクトの状態の過去のスナップショットを
> オブジェクト自身に持たせるのが正しい設計かという話 誕生日だけが提供されていたらコードのあちこちで年齢を出すメソッドが別々に書かれるかもしれない
同じ処理が複数で書かれてそれも同じ処理とも限らない
ロジックが散らばるのはよくないからクラスが持つべきではないかと思う 大小比較のアルゴリズム自体を引数で渡したり、
オブジェクト指向っぽくてエレガントに見えはするけど、
一般プログラマには可読性低いなー
と思ったり。
一昔前のオブジェクト指向設計が売りの会社たちは、
オナニー会社として、まるで奮わなかったもんな
やっぱ適正レベルってもんが大事だよね >>837
そこは、年齢に限らず単に時刻の差を計算する処理として
dateクラスのメソッドかグローバル関数であるべきでは C++はベターCとして、文字列いじるときとか楽できればいいんじゃね？
でもmallocとかメモリ管理が面倒だから、C#やJavaに流れるよね
要員確保できるもの >>839
間違っても年齢を出す処理はdateクラスに持たせるべきではない
誕生日から年齢を出すのは実は結構めんどくさい
日本での年齢は日本の法律にのっとって決まってる だいたいそういうのは業務共通クラスとしてstaticメソッドてんこ盛りで置いておくよね つーか簡単だろ？
日付クラス。もしくは日付補助クラスに
2つの日付の差を年で返すメソッドを追加する
Personクラスには、誕生日とageプロパティをもたせ
ageプロパティは、誕生日と今日の日付の差を
さっきの年で返すメソッドを呼び出すだけにする
テストは日付クラスのメソッドはそのまま年計算のメソッドのテストを書けばいいし
Personクラスのテストは、単体テストの観点から日付クラスが
外部モジュールになるので年計算のテストは不要（すでにやってる）
年計算のメソッドを期待したとおりの引数で呼び出していることの確認と
返り値をそのまま戻しているかを確認すればいい
特定の年月日の年齢が知りたいなら、誕生日プロパティと特定の日付から
日付クラスの年計算メソッドを呼び出して差を計算するか、
適切な場所があるならそこにメソッドをおけばいい >>841
> 間違っても年齢を出す処理はdateクラスに持たせるべきではない
理由ぐらい書けよな dateクラスに持たせるべきではないというのなら
年齢計算クラスに持たせればいいだけだな >>841
すまん、ならdateクラスは撤回する
国にも依るとなると尚更personにも持たせたくないな
単にグローバル関数にするか、いっそそれ用のクラスツリーをでっち上げて後々多態できるようにするか、かなあ >>843
じーちゃん132歳とか出るパターンじゃね？ 国によって年齢計算のアルゴリズムを変えたいというのなら
ストラテジーパターンの出番だなｗ 俺やったらageプロパティやageオブジェクト作るんじゃなくて
ageクラス作ってpersonのデリゲートメソッドにageクラスオブジェクト返すものを作る。これで年齢とはそもそもなんぞや定義はの面倒な過程の話にも対応出来る
だが書く途中でゲッターですませやとキレだすと思う ■ このスレッドは過去ログ倉庫に格納されています
