実は「オブジェクト指向」ってクソじゃね?これデスマーチの原因じゃね?
■ このスレッドは過去ログ倉庫に格納されています
カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約(頭文字にアンダースコアを付けるなどの命名規則)で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 構造体とサブルーチンで十分です。勘弁してください。 どういうことなの・・・
8ビット機のBASICしか知らない俺に誰か優しく教えて Cしか使わんからオブジェクト指向が全くわからん
この先食いっぱぐれないようにするには勉強した方がいい? フレームワーク使ってれば、あまり気にせんで済むやん >>8
8ビット機のBASICが最強なのにオブジェクト指向だのなんだの言って
適当な理屈をこねくり回してクソが出来た
これがデスマーチの原因 プログラムが小規模のうちは恩恵がない
大規模になっても恩恵がかならずあるとは限らない
複雑さを整理する知恵の一つ デスマーチって大げさだよねぇ
物理的に終わらない仕事量ってだけで人増やせば解決する問題じゃん オブジェクト指向ってのは手段の1つで、手段が目的になるのは感心しない。 そんなものは昔から変わらない
BASICの「定義せずに使える変数」と同じで
便利なものは馬鹿が使うと危険なトラップになる ハードに近い方ならいいんでは
ガチガチのソフトだと厳しい >>38
関わる人数が増えるほどシステムの品質はおち効率は落ちるぞ マトモにオブジェクト指向設計できる人が少ない
というかほとんどいない
これはデータ中心設計とか言ってた頃からそうだけど
マトモにモデリングできる人が本当にいない
モデリングの結果が正しいか検証できる人もいない なんかそれぞれの物には特有の条件や特徴があって
それを一つの塊みたいにプログラムする感じ? >>36
だよな
WinアプリならC++でWindowsAPIを直叩き
GUIはもちろんリソーススクリプトを直書き
リソースエディタを使うやつは根性なし
男ならこれが基本 >>38
少数精鋭に特化してけばデスマーチは無いのよ
問題は精鋭がいないことなのよ 超頭良くて整理整頓が得意な人が使うと有用
それ以外の人が使うとスパゲッティ モデリングが正しく出来ない奴がオブジェクト指向設計したら必ずゴミになる
でも何が正しいモデリングが分かって無い奴が大半
だからクルマクラスはタイヤクラスとエンジンクラスとかに分割してとか無批判に考えちゃうし美少女ウンコの問題で結論が出なかったりする
関数型プログラミングのほうがはるかにましだわ やたらめったらクラスを作ったり、親の親の親の変数を参照したり、1つのフォームを何個もの部品に細分化しまくる
1画面はともかく数十画面のマルチモニタがないと1つの処理を把握できないのはクソ それはあとから見て改修が難しいプログラム組んだやつがクソなだけでは S: 平均的な C プロジェクトの長さをおぼえているかな。だいたい6ヵ月だ。
家族を抱えた人間がまともな水準の暮らしを維持するには短すぎる。で、
同じプロジェクトを C++ でやったらどうなる? 教えてあげよう。1〜2年だ。
素晴らしいね。たった1つの判断ミスで、
安定した仕事が確保されるんだよ。
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html >>46
いや、システム全体を体系的に分割すること
巨大なシステムでも合理的にモジュール分割され、モジュール間のやり取りが明確になっていれば、
あとは小さくなった各モジュール単位で開発ができる…はず… javaはもちろんのこと、PHP等の他言語もクラスの概念を取り入れてるし、
OOPは別に悪い考えではないやろ。
要は使う人のスキルの問題ですわ。
変数のアクセスしたければput_xxx()、get_xxx()メソッドがあるし、無ければそもそもアクセスするなって事やし。 賢い人間が一人で作るにはオブジェクト指向は最高だ
アホな他人のコードはオブジェクト指向だとイライラの元 >>45
そうこれ
例えば昔からあるモデリングアプローチのUMLで言うと
ユースケース分析やるのは良いことなんだけど
その成果をアクティビティのフローチャートやクラス図に落とした時点で全部台無しになってるのが大半
結局えいやでモデリングしてて結果後から矛盾が出来てしまい肥大化するというパターン >>13
俺も同じだわ。Cとアセンブラしかわからん。
頭のいい人が考えた言葉はマジで理解出来ない。
年齢とかやる気次第だけどたぶん手遅れ。
古い製品のリニューアルとかローカルなIOやUARTで完結する仕事やってるけど、
何でもかんでも産業用イーサに繋がる製品が増えてるからいずれ干される。 ド素人が設計した中身ifだらけのクラス
モデリングの時点で間違ってる、つうか設計してないやんw >>60
結局Perlみたいなものだな
しかも追加要件が出たらどうせゴチャゴチャになるのがオブジェクト指向設計
関数型プログラミングのほうがはるかにましだわ >>58
お前>>1一切読んでないだろw
無ければそもそもアクセスするなって隠ぺいしてるデータがあるから大規模改修に耐えられずデスマーチが発生するって書いてるよ
まさにその通りだと思うけどね >>38
作業をこなすのなら人数をかければ問題がない。
プログラミングが作業をこなす程度のものならね。
だけど、それは仕事じゃないね。 隠蔽されたデータにアクセスするインタフェースを作る
インタフェースを作ればそのインタフェースでアクセスを管理できる
そういうもんでないの? リーナス・トーバルズもC++みたいなオブジェクト指向言語はウンコ以下だって言ってたな オブジェクト指向なんて発想的には分割コンパイルなんだからC言語やってたらわかるはずなんだけどなあ 人間の能力には限界がある。
見えすぎることは有害
オブジェクト指向は人を救ってるんや >>64
細かい理解を省くと、構造体に関数を持たせたものと考えて差支えはあるがイメージはできるはず。 entityクラスだけは意味がわからん
privteで書いて外向けにpublicのやつ
publicだけでいいだろ 多態とかはやり過ぎると客からの要求仕様変更に対応できなくなる恐れがある
あんまり構造を綺麗にしすぎるのも問題だ >>73
構造体に関数ポインタで似たような感じにできるしな
継承はさすがに無理だが オブジェクト指向設計が生きるのは、一からシステム開発する時くらいだな
システム改修とかなった時点で過去の設計思想とか無視されるし CとC++とC#の違いがわからん
右に行くほど新しいってのはわかる システムレベルで継承に継承重ねまくったシステムの中のソースも継承されまくって直すと継承先全てに影響するから全部試験し直しになるので誰も親クラス触れないのが普通。
親クラスだけの修正で済むとか生温いわ。 >>71
それをやってると追加要件でて改修し始めたらぐちゃぐちゃになるのよ >>80
改修に使えるドキュメントってないもんなwww
俺も作らん Win32の世界なら
ATLやWTLくらいの薄いラッパーのほうが書きやすいし効率もいい >>81
Cは構造化言語
C++はオブジェクト指向言語
C#は.NET上で動くCライクのオブジェクト指向言語 >>65
うちのシステムで、継承の親クラスのexecuteでif文大量に使って全子クラスの処理まかなってるのあるぞ
子クラスは変数セットとexecuteを呼び出すだけ
画面追加の度にif文増やして全画面回帰テストする気かと >>83
部品化なら関数で十分だろ
オブジェクト指向アプローチの部品化はゴミよ Aというデータを入力してAというデータを出力するモジュールを省略すると動かない、ふしぎ!! >>76
なんとなくわかりました。
データの参照とか隠蔽が複雑なサービスを実装する時に便利というか、
検証とか管理の事を考えると実質的にそれでしか出来ないってことですか。 オブジェクト指向がクソとは思わないけど、これがすべてと言われるようになって久しいのがな。
栄枯盛衰で次が模索されてる時期に来た感じはある。 >>77
public変数でいいと思うよ
ただフレームワーク側でgetter setterが用意されてること前提の場合は諦めろん 学校で教科書読んでせいぜい文法を知ってるレベルの人材が
「Javaが使えます」とか言い出すこと、そしてそれが通用してしまう環境が悪い S: それ、本気で信じてるね。実際の C++ プロジェクトの経験はある?
どうなるかって言うとね、まず第一に、いろいろワナを仕掛けてあるから、
よほど小規模なプロジェクト以外は一発では動かないようになっているんだ。
たとえば演算子のオーバーロードがそうだ。たいていの場合、プロジェクトの
終わり頃にはほとんどのモジュールで
演算子をオーバーロードしている。 >>92
時と場合で使い分ければいいんでないの?
仕様変更がバシバシ入るのが確定な使い捨てツールやシステムに
オブジェクト指向でしっかり設計してとか逆に非効率だろう
天才なら考えられるあらゆる仕様変更に柔軟に対応する設計を
さらっとやってしまうんだろうが、現実問題、そんな人はまず居ない >偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
偏差値の高低で教科書の内容が違うの? 確かに継承しまくってるとソース追って全体を把握するのが面倒とかあるな さぁ実験です\(^^)/
directX
DXライブラリ
Siv3D
3つのチームにそれぞれ1つずつ配布してゲームを作ってもらいます。
どのチームがいち早くゲームをリリースできるでしょうか? オブジェクト指向設計は本当にキッチリ効率的に設計出来れば良く、大きなPJになればなるほど有用なハズなのに、大きいPJになればなるほど効率的な設計は難しく天才が必要になると言う矛盾
・そもそも天才は少なく破綻
・途中や仕様追加の段階でアホか入って破綻
ってのが多すぎる。個人でやる程度なら問題ないんだがなww
常駐させる場合のJavaのメモリ管理も同じような事がある。キッチリメモリ管理・メモリの使い方の特性を把握してチューニングしないと地獄を見る。 ■ このスレッドは過去ログ倉庫に格納されています