実は「オブジェクト指向」ってクソじゃね？これデスマーチの原因じゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：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が最強なのにオブジェクト指向だのなんだの言って
適当な理屈をこねくり回してクソが出来た
これがデスマーチの原因 プログラムが小規模のうちは恩恵がない
大規模になっても恩恵がかならずあるとは限らない
複雑さを整理する知恵の一つ デスマーチって大げさだよねぇ
物理的に終わらない仕事量ってだけで人増やせば解決する問題じゃん オブジェクト指向ってのは手段の１つで、手段が目的になるのは感心しない。 そんなものは昔から変わらない
BASICの「定義せずに使える変数」と同じで
便利なものは馬鹿が使うと危険なトラップになる ハードに近い方ならいいんでは
ガチガチのソフトだと厳しい >>38
関わる人数が増えるほどシステムの品質はおち効率は落ちるぞ マトモにオブジェクト指向設計できる人が少ない
というかほとんどいない
これはデータ中心設計とか言ってた頃からそうだけど
マトモにモデリングできる人が本当にいない
モデリングの結果が正しいか検証できる人もいない なんかそれぞれの物には特有の条件や特徴があって
それを一つの塊みたいにプログラムする感じ？ >>36
だよな
WinアプリならC++でWindowsAPIを直叩き
GUIはもちろんリソーススクリプトを直書き
リソースエディタを使うやつは根性なし
男ならこれが基本 >>38
少数精鋭に特化してけばデスマーチは無いのよ
問題は精鋭がいないことなのよ 超頭良くて整理整頓が得意な人が使うと有用
それ以外の人が使うとスパゲッティ モデリングが正しく出来ない奴がオブジェクト指向設計したら必ずゴミになる
でも何が正しいモデリングが分かって無い奴が大半
だからクルマクラスはタイヤクラスとエンジンクラスとかに分割してとか無批判に考えちゃうし美少女ウンコの問題で結論が出なかったりする
関数型プログラミングのほうがはるかにましだわ やたらめったらクラスを作ったり、親の親の親の変数を参照したり、１つのフォームを何個もの部品に細分化しまくる
１画面はともかく数十画面のマルチモニタがないと１つの処理を把握できないのはクソ それはあとから見て改修が難しいプログラム組んだやつがクソなだけでは S： 平均的な C プロジェクトの長さをおぼえているかな。だいたい6ヵ月だ。
家族を抱えた人間がまともな水準の暮らしを維持するには短すぎる。で、
同じプロジェクトを C++ でやったらどうなる？ 教えてあげよう。1〜2年だ。
素晴らしいね。たった1つの判断ミスで、
安定した仕事が確保されるんだよ。
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html >>46
いや、システム全体を体系的に分割すること
巨大なシステムでも合理的にモジュール分割され、モジュール間のやり取りが明確になっていれば、
あとは小さくなった各モジュール単位で開発ができる…はず… javaはもちろんのこと、ＰＨＰ等の他言語もクラスの概念を取り入れてるし、
OOPは別に悪い考えではないやろ。
要は使う人のスキルの問題ですわ。
変数のアクセスしたければput_xxx()、get_xxx()メソッドがあるし、無ければそもそもアクセスするなって事やし。 賢い人間が一人で作るにはオブジェクト指向は最高だ
アホな他人のコードはオブジェクト指向だとイライラの元 >>45
そうこれ
例えば昔からあるモデリングアプローチのUMLで言うと
ユースケース分析やるのは良いことなんだけど
その成果をアクティビティのフローチャートやクラス図に落とした時点で全部台無しになってるのが大半
結局えいやでモデリングしてて結果後から矛盾が出来てしまい肥大化するというパターン >>13
俺も同じだわ。Cとアセンブラしかわからん。
頭のいい人が考えた言葉はマジで理解出来ない。
年齢とかやる気次第だけどたぶん手遅れ。
古い製品のリニューアルとかローカルなIOやUARTで完結する仕事やってるけど、
何でもかんでも産業用イーサに繋がる製品が増えてるからいずれ干される。 ド素人が設計した中身ifだらけのクラス
モデリングの時点で間違ってる、つうか設計してないやんw >>60
結局Perlみたいなものだな
しかも追加要件が出たらどうせゴチャゴチャになるのがオブジェクト指向設計
関数型プログラミングのほうがはるかにましだわ >>58
お前>>1一切読んでないだろｗ
無ければそもそもアクセスするなって隠ぺいしてるデータがあるから大規模改修に耐えられずデスマーチが発生するって書いてるよ
まさにその通りだと思うけどね >>38
作業をこなすのなら人数をかければ問題がない。
プログラミングが作業をこなす程度のものならね。
だけど、それは仕事じゃないね。 隠蔽されたデータにアクセスするインタフェースを作る
インタフェースを作ればそのインタフェースでアクセスを管理できる
そういうもんでないの？ リーナス・トーバルズもC++みたいなオブジェクト指向言語はウンコ以下だって言ってたな オブジェクト指向なんて発想的には分割コンパイルなんだからC言語やってたらわかるはずなんだけどなあ 人間の能力には限界がある。
見えすぎることは有害
オブジェクト指向は人を救ってるんや >>64
細かい理解を省くと、構造体に関数を持たせたものと考えて差支えはあるがイメージはできるはず。 entityクラスだけは意味がわからん
privteで書いて外向けにpublicのやつ
publicだけでいいだろ 多態とかはやり過ぎると客からの要求仕様変更に対応できなくなる恐れがある
あんまり構造を綺麗にしすぎるのも問題だ >>73
構造体に関数ポインタで似たような感じにできるしな
継承はさすがに無理だが オブジェクト指向設計が生きるのは、一からシステム開発する時くらいだな
システム改修とかなった時点で過去の設計思想とか無視されるし CとC++とC#の違いがわからん
右に行くほど新しいってのはわかる システムレベルで継承に継承重ねまくったシステムの中のソースも継承されまくって直すと継承先全てに影響するから全部試験し直しになるので誰も親クラス触れないのが普通。
親クラスだけの修正で済むとか生温いわ。 >>71
それをやってると追加要件でて改修し始めたらぐちゃぐちゃになるのよ >>80
改修に使えるドキュメントってないもんなｗｗｗ
俺も作らん Win32の世界なら
ATLやWTLくらいの薄いラッパーのほうが書きやすいし効率もいい >>81
Ｃは構造化言語
Ｃ＋＋はオブジェクト指向言語
Ｃ＃は.NET上で動くＣライクのオブジェクト指向言語 >>65
うちのシステムで、継承の親クラスのexecuteでif文大量に使って全子クラスの処理まかなってるのあるぞ
子クラスは変数セットとexecuteを呼び出すだけ
画面追加の度にif文増やして全画面回帰テストする気かと >>83
部品化なら関数で十分だろ
オブジェクト指向アプローチの部品化はゴミよ Aというデータを入力してAというデータを出力するモジュールを省略すると動かない、ふしぎ！！ >>76
なんとなくわかりました。
データの参照とか隠蔽が複雑なサービスを実装する時に便利というか、
検証とか管理の事を考えると実質的にそれでしか出来ないってことですか。 オブジェクト指向がクソとは思わないけど、これがすべてと言われるようになって久しいのがな。
栄枯盛衰で次が模索されてる時期に来た感じはある。 >>77
public変数でいいと思うよ
ただフレームワーク側でgetter setterが用意されてること前提の場合は諦めろん 学校で教科書読んでせいぜい文法を知ってるレベルの人材が
「Javaが使えます」とか言い出すこと、そしてそれが通用してしまう環境が悪い S： それ、本気で信じてるね。実際の C++ プロジェクトの経験はある？
どうなるかって言うとね、まず第一に、いろいろワナを仕掛けてあるから、
よほど小規模なプロジェクト以外は一発では動かないようになっているんだ。
たとえば演算子のオーバーロードがそうだ。たいていの場合、プロジェクトの
終わり頃にはほとんどのモジュールで
演算子をオーバーロードしている。 >>92
時と場合で使い分ければいいんでないの？
仕様変更がバシバシ入るのが確定な使い捨てツールやシステムに
オブジェクト指向でしっかり設計してとか逆に非効率だろう
天才なら考えられるあらゆる仕様変更に柔軟に対応する設計を
さらっとやってしまうんだろうが、現実問題、そんな人はまず居ない ＞偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
偏差値の高低で教科書の内容が違うの？ 確かに継承しまくってるとソース追って全体を把握するのが面倒とかあるな さぁ実験です＼(^^)／
directX
DXライブラリ
Siv3D
3つのチームにそれぞれ１つずつ配布してゲームを作ってもらいます。
どのチームがいち早くゲームをリリースできるでしょうか？ オブジェクト指向設計は本当にキッチリ効率的に設計出来れば良く、大きなPJになればなるほど有用なハズなのに、大きいPJになればなるほど効率的な設計は難しく天才が必要になると言う矛盾
・そもそも天才は少なく破綻
・途中や仕様追加の段階でアホか入って破綻
ってのが多すぎる。個人でやる程度なら問題ないんだがなww
常駐させる場合のJavaのメモリ管理も同じような事がある。キッチリメモリ管理・メモリの使い方の特性を把握してチューニングしないと地獄を見る。 >>94
そんな人が納期に追われながらまともな設計が出来るわけないんだよな すばらしいけど全てのプログラマに扱えるような簡単なものではないのでやめろ！ >>91
最近の言語を使ってて真にメリットがあると思うのはメモリ管理を基本的にしなくていい部分だと思ってしまう。 ニュー即のＳＥスレで「オブジェクト指向ってなに？」って質問して、納得の行く答えを聞いたことがない
だれか猿にもわかるように説明してくれよ、オブジェクト指向ってなに？ >>97
コンピューターサイエンスやってる大学の話やで？ >>98
＞確かに継承しまくってるとソース追って全体を把握するのが面倒とかあるな
それは無い。継承しまくった物だけ見れば全体が見えるだろ。バカは何やってもバカだから情報処理は向いてない >>104
君はスマホを使っている
だが、スマホの中に使われている技術を知らない
これでよくね >>100
納期に追われてても100％力を出せる天才が必要だな
それでも無茶な納期で破綻とかあり得るし デバグの最中とか所謂デバッグモードとかに必要な、
監査的な機能を書くのが面倒だとは感じる
unsafe とか適当なキーワードでなんでもアクセスできる機能が欲しい 金融系でCOBOL→Javaの移行案件でソースの自動変換でJavaに組み替えしてる場合有るけど、出てきたJavaのソーセージがオブジェクト指向プログラムになっていない事実
これがみずほ銀行とかの実態 >>8
Visual BASICをちょっと勉強してみたらわかると思うよ エンジニアが自分たちの仕事が無くならないように面倒くさいものを作り出してんだよ >>13
これからgoが流行るらしいからgoやっとけばいいかも >>1の書いていることって早い話が
「全てのメンバーにアクセス可能に設計することにより例外的なアクセスは発生しなくなる
従ってプログラム改修の際に例外的な処理を考慮する必要がなくなる」
ってこと
もっと分かりやすく書くと
「最初から全ての例外的な処理を網羅したプログラムを書けば、改修の際に例外的な処理を考慮する必要がない」
つまりアレだ いまこそBASICだろ処理速度はもう問題ないんだからわかりやすくするべき >>69
まぁそうなるようだと改修よりも設計しなおした方が多分早いだろうね 天才と、その人の仕事の邪魔になる要素を全部未然に取り除けるプロマネがいれば或いは 少しかじってる素人だけど、わかりにくい教科書が散乱してるのなんとかならんの？ アスペクト指向みたいなオブジェクト指向の原理原則から脱しないと実現できないパターンなら仕方ないね >>38
本当の土方なら人集めて「ここ掘れ」で仕事が進むけど、IT土方は人だけ集めても進まない。
内容がちゃんとわかっててバグなしのコードが組める人間が少しいれば仕事は進む。 >>112
Javaならリフレクション使えるじゃないか？
UTやってるとこういう事言い出す奴が必ずいるけど
そういう人間にフレクション教えると往々にして「通るテスト」を書き始めて
ここ全部やり直しね♪というハメになる >>47
趣味ならそれもいいけど仕事でそれをやると時間がかかり過ぎて時給100円とかになってしまうけど、それでいい？ >>103
さっき書いたけど(少なくともJavaの場合)、
・非常駐ならJavaでなくてもメモリ管理は適当で問題ない
・常駐ならキッチリやらんと地獄
まぁ天才的JVMが出て来てイズレ解決すると思ってたけど解決せんなぁ。取り敢えず起動optionにメモリ・GC関連パラメータが多数あるうちは敗北を認めてるようなもんよ。 >>105
偏差値の低い学校では「絶対使え」で、高い学校では「絶対使うな」になるのが不思議
「絶対使え」と指導しないといけない低偏差値特有の理由があるのかなと 確かにprivateは糞だし要らん
あとreadonlyのpublicを変数定義時に簡単に設出来る方法欲しい プログラムまったくわからんがある部署の仕事内容は他の部署から全くみえないようにしとくってことだろ？
他の部署が書類だしたら処理されて書類でてくるみたいな ようはブラックボックス化のことだろ >>69
それ、改修の時しか考えてないでしょ
「いつでもどんなときでもアクセスしてもいいよってデータを設計する」こと自体がデスマーチになるだけよ
そのデータを使う側の制御も想定外の更新が起こり得ないように全ての例外を網羅した神様のような設計をしないといけない
さもなくばデータを更新するコードを1行書くたびに参照する全ての制御に「影響確認依頼書」なりを送らないといけなくなる
実際、組み込み系でそうなったプロジェクトもあるからな >>103
ああそれでですね。
私は仕事でマイコンいじってますがOSレスで固定アドレスで完結する仕事しかしてなかったので。 >>104
単純に言えば全体の処理を分割しただけだよ
車のパーツみたないなモノ。エンジンやらフレームやらサスペンションやら
各部品ごとに役割（処理）があるじゃん >>133
オブジェクト指向なんて単なるパラダイムの一つだからな
でも低学歴にパラダイムが異なると正しいことが間違いになることもあるなんて説明しても「？？？」だろ？
低学歴は就職するときに採用してくれる業界で主流のやり方だけ学んどけはそれで十分ねん
頭良い子には何故このパラダイムが選ばれたかの背景や問題点を考えさせ次の時代の新しいパラダイム作ることに貢献することが求められる訳よ 今更何を?
MS がコンパイラを ＋＋ でしか提供しないからしかなくみんな ++ に移行したんだよ >>83
サブルーチンでよくね？
多層構造も作れるぞ。 >>136
だから関数型プログラミングがが今もてはやされてるわけですよ
オブジェクト指向プログラミングはオワコンってね >>133
「使え」と言ったのはOSI基本参照モデルを作った人たち。
由緒ある高学歴な学者たち。
「使うな」と言ったのはIP、すなわちインターネットを作った人たち。
BSDを作った野良の学生たち。
大学がどちらを教科書に採用するか オブジェクト指向からカプセル化と継承取っ払ったドラスティックな言語は無いものか…
むしろインタフェース(多態性…というと少し違うが)強制させるのがいいんじゃねーかと最近思うわ 外からデータを直接いじられたくないからわざわざ隠してるわけでそれをいじる改修とかそもそもおかしいだろ
それをいじる改修できたとしてももう全部作り直しレベルだろ
オブジェクト指向だからという問題ではない
隠蔽できない言語じゃ作り直しするかどうかやいじっていいかはソース見ないと分からないが隠蔽されてるのはその時点でコーディング出来ないから駄目か作り直しかが分かるからメリットでもあるのに >>146
動的型言語で契約プログラミングすれば出来そうだな >>136
決まったものを作るならいいんだけどね。
カプセル化されたクラスはゲーム開発でいえばRPGツクールなんだよ。
RPGツクールの範囲内であれば便利だが「アクション要素いれてくれ」とか要望あると死ぬ。 どんなときに問題になるのか
もう少し具体的に書いてないの？ >>24
バージョン1→2→3とかバージョンアップしないの？ >>150
最初からアクションもシミュレーションも出来るように設計する→デスマーチ オブジェクト指向なんて難しくなんともなく単なる便利ツールなだけ。
ツールをうまく使えば便利だし不要なら使わなければいいだけ。
アホが使いこなせないからややこしくなってるだけ。
アホは死ね。 言語が多いのは仕方ないとしても、使いにくい言語がしぶとく
残っているのは厄介 オブジェクト指向なんて言っても結局手続き呼ぶだけだからなあ >>88
俺なら親クラス子クラス同一インタフェースにして、子クラス側にifチェック持ってきて親クラス側で子のリスト作ってforeachで回すなぁ…
てか何故親にチェックもってきたし… >>150
あー分かりやすいかも
「一定の範囲で」なんて大型PJではあり得ない縛りだけどなw
流用改善しやすいハズなのになww なんだい、最近オブジェクトに凝ってるね。スレたて主w
プログラム板でも言ったら。
アソコのカキコは喧嘩腰でいかんよw クラスの最大のメリットは自己簡潔できるインスタンスがあちこち動けるからだからな。
文字列とか良い例だな 言語のオブジェクト指向は便利だぞ
疲れてるとき運ちゃんに指示出す場合とか
「自宅……町田……そこ右…」 >>79
リエントラントにならなくなる危険性が残るんじゃね すべてpublicにしていついかなるときも更新が可能にしよう
この発想の行き着く先は
値を更新するたびに全体ロックを取得して全てのスレッドを止めるシステムになる >>84
追加要件に対応してもぐちゃぐちゃにならない方法はどんなの？
それをオブジェクト指向と併用できないの？ >>165
居眠り例外で死にかけた事があるんですがそれは。 >>128
単体テスト用テストプログラム(xUnit系)書いてると陥るパターンだなそれ >>167
せめてprotectedではアクセスできるようにしとけ >>164
この流れもある
型でしばる堅牢さよりも、自由さが重視されるシステムは多い。 >>117
ちと古いけどJavaの有名なフレームワークのsastrutsがそうだったな
てかseaserコンテナは基本publicの物見るんだったはずな気が >>89
データと関数が一対一対応しなくなる危険性がある
ドキュメントで注意書きしても読まれないとかあるし いや
単に営業が工数計算できずに、激安受注するのが悪いんだろ
で、会社も大喜び AOP？とかいう、アスペクト志向について教えてくれ。
あのアスペとは別モノなんだな。 クラス化したものは、状態とデータをセットで保持できて、さらに、その状態に応じて処理を制御できる。
クラスを使わないと、インデックスやらポインタやらで精密に制御するコードを組む必要があるけど、クラス機能があるとその必要がない。 >>178
似たような処理を並べた時に、一律で処理挟み込むような目的のための技術がAOP
例えばログ取りとか認証処理とかね
これをお手軽に、後から追加した機能(関数/メソッド)にも共通の処理を追加したいって要請で生まれた どんな言語使ってても仕様上考慮されてない新機能をぶち込むのはどうあがいても絶望なんだと思うんですけど。
デスマの原因はたいていそんなだろとしか言いようがない。 >>145
The Internetが軽量スクリプトに溢れているのはそういうのが理由だったりして。
重厚なレガシーリプレイスほどJavaだったりする。 >>181
>>1が言ってるのは「最初からあらゆる例外を考慮すれば改修の手間が省ける」というお話 完全なるユーザー目線だけど、Javaで作ったWindowsアプリケーションってなんであんな遅いの？？
C♯で作ったアプリのほうが軒並み速い。
JavaのエキスパートにC♯で作らせたほうがマシなものできる。マジで。 大規模、長寿命なシステムを多人数で開発保守していく場合は必要。それ以外はケースバイケース。
ただ、設計手法の選択肢として理解しておく必要はある。理解もせずにいらないと言う奴はただの馬鹿。 制約を加えることで管理しやすくするのがオブジェクト指向
↓
その制約のためにデスマーチが発生する
↓
最初から制約を外してあらゆる管理に耐えられるように設計すればデスマーチは発生しない
素敵な発想だろ？ >>179
JavaScriptなら中括弧で囲めばいい 10年異常前になるけど、工業高校出身が得意になって徹夜してたっけ
実績出れば現場の親分 >>8
お前らが構造化プログラミングをやれば最強って事 >>166
ああ、そういう問題もあるか
リエントラントについては詳しくないから何とも言えんわ >>185
そりゃC#使わせたいから
Javaの為に考慮した環境じゃないかから >>185
そらまあＶＭ作ってるベンダーが自社ＯＳなら速かろうってお話じゃないの。 >>186
言語はなんでもいいよ
CでもJavaでも
プログラミング手法としてのOOPがダメ >>185
GUIアプリの話してるなら仰る通り
素直にC#使えばいい話でそこにJava当て込むのが間違いだと思う >>194
C♯ってvirtual machineで動いてたっけ？
まぁ実行環境自体はより最適化されてるだろうな。 まあ大概はほぼ一点物のクラス作る人の方が大半だから
汎用性ガーとかいって１回しか呼ばないプライベート関数作ったり
教科書みたいに全部の変数にゲッターセッター作って
無駄にコールスタック発生させるバカは才能無いと思う >>185
Windowsってなんであんなに遅いの？ >>147
いじりたいデータを持つインスタンスを特定する様なクラスを追加するだけで改修できそうな気がするけどな >>185
C#はWindows環境でしか動かない代わりに、Windowsに最適化された言語やからな。
WindowsもC#も同じ会社（マイクロソフト）が作ってるから当然。
Javaは遅い代わりに、原則的にはWindowsでもLinuxでも動く言語。
ブラウザで動かすWebアプリケーションではなく、本当にExeを叩いて動かすアプリケーションが
JAVAで作られてるのであればマヌケな選択と思う。理由はあるとは思うけど。 >>195
問題は新規開発でなくてエンハンスだな
聳え立つ糞をどうするかって話で
言語変えるだけの予算はどこも無いだろうし(おまけに要員の問題もある)結局前の言語引きずってJavaで作るか、OOPと関数型プログラムのいいとこどり(？)のScalaみたいな奴使って、徐々にパラダイム変えてくしかない
俺は継続的に機能が進歩するようなシステムにはOOPは向いて無いと思うので、個人的には関数型プログラミングが流行ってほしいこの頃 >>200
Macは早いか？
普通の人がコマンド打たずに全ての機能を、使えるようにしてるからじゃね。
LinuxディストリビューションがGUIで操作できる機能は一部だけだし。 >>185
まぁC#はOS作ったメーカが作ってるから
ネイティブコードの書き方がいいんだろ（分らない事なんて無いだろうから） >>38
日本のソフト開発が終わってる最大のみ原因がこれ >>204
>C#はWindows環境でしか動かない
お前何か別の言語と間違えてるやろ >>104
目的ごとに機能を一つのかたまりにまとめよう、という考え方。
ってだけ。
極めて当たり前の考え方だし、無きゃ不便だし、こんなもの否定するやつの意味がわからん。 >>204
C#はLinuxでもコンパイルできるし実行形式にもできるよ
GUIアプリは知らん >>210
最初の目的に反していたら大規模な設計変更が必要だ
だから目的を決めない方が良い
ということや 全ての機能を全ての人が知ってれば効率はいいんだろうけど
そんな理想的な状況は生まれえない >>212
pythonには同意できんがc#にはまったく同意
c++とかもうやりたくない
javaは地獄へ落ちろ 畑違いでど素人な俺にオブジェクト指向とは何かについておしえてくれ >>219
オブジェクト指向は再利用しやすい(ただし再利用しやすく作ればの話) >>185
Javaはたしか中間コード迄しかコンパイルしない
でその中間コードをwindowsとかlinuxとか
で動くコードに変換しながら動かしてる
作る側はjavaで書けば色んなOSで動かせるから便利 >>223
初めて知ったありがとう
JavaのSWTみたいなもんか？ >>184
それだけで十分？
他にも必要な要素があるんじゃね？ >>220
畑違いには覚える必要のない全く無駄なことだから
教えるために労力をかけるのは更に全く無駄なこと
だから君に教える必要は皆無
天井の染みの数を数えるのオススメするわ >>209
単に知識が古いニワカってだけじゃね
MS柄みの言語ってだけで思考停止w すべての変数、すべての関数はグローバルで宣言しろ
分岐にはgoto文を使え。
プログラミングは自由だ、コーディング規約なんてものに縛られると最高のコードは書けない
他人に簡単に理解できるようなしょぼいコードは書くな なんでこんなにプログラマスレ立つんだよ
そういう季節なのか？(；・∀・) >>224
変換てーか、"中間コード(バイトコード)をJVMで直接動かしてる"が正しいかと
JVMがOSの違いをよしなに取り計らってくれてる >>230
底辺プログラマーは常にストレスが溜まってるから日々マウンティング合戦しないと気が済まない >>8
実はオブジェクト指向はあったな
.data,.textブロックのコピーでデータ構造を表現して処理に渡した >>228
別に.NET Coreじゃなくてもmonoなら昔からあるんだけどね
知識が古いというより無いんやろw >>138
こういう入門書って昔はよくあったな。
冒頭で、
タイヤやハンドルがない車、とか
窓や玄関がない家とか。
初心者は、そんな車や家があるわけねーだろって冒頭で挫折する。 >>234
組み込みこそ状態のあるものは全てオブジェクトだろう >>104
日常生活でいっぱい使ってるで
判子セットとかな 最初からブリザラで攻撃するコードを組めば早いのに、わざわざ幻獣というオブジェクトを定義して召喚してから氷の息吹きとかで攻撃するイメージ
幻獣は再利用性があるとか言うが、さっさと攻撃する方がシンプルで軽い >>243
最近思う
遠回り過ぎて余計複雑になってる つか、見事にオブジェクト指向で作りてるようなソースにまずお目にかからない。日本の炎上原因はそれ以前のレベルなのでは 確かにクソなんだけど大規模プロジェクトだとそうしないと収拾つかないんだよ コピペ関数プログラミング最強とか思ってる奴が多そうで恐ろしい。 いや、別に考え方の一つとしてオブジェクト指向は悪くないだろ。万能じゃないけど。 >>240
複数の構造体のデータを書き換える時
1つ目更新OK
2つ目更新OK
3つ目更新NG
の時は1つ目と2つ目の更新を
ロールバックしないといけない
けどオブジェクト指向とか関数型プログラムではどうやって実現するのかな >>252
モジュールごとに「何を与えたら何が返ってくるか」だけを定義するやり方
そのモジュールを組み合わせるとシステムになるという開発手法
個別モジュールだけに集中できるから何十人もかかわる大規模プロジェクトではそうしないと交通整理できない >>253
目的でまとめるけどいくつもの目的の関係がある時どうやって個々の独立したクラスにする？ GUIを使ったプログラムを作るには必須だよね、オブジェクト指向。 >>243
幻獣を100体召喚出来るキャラと
幻獣を50体召喚出来るキャラが
同時攻撃するのとかどうする？
あと幻獣もそれぞれ個体差がある >>254
差分管理クラスを作っていくつ前とか何秒前とかのデータを再生するとか >>213
C#はたしかにLinuxでもMacでも動くが
普通C#言ったらC#.NETのことだろう >>248
トランザクションとかは自分で作らないと無いんじゃね？ >>235
アセンブラこそ至高。
最高のパフォーマンス、最小のサイズを求めるとアセンブラになる。
男ならアセンブラ >>255
その考え方は関数型プログラムじゃね？
入力→出力の関係を決めるのは関数だし >>263
今はIntelの投機実行全否定されてるしな ソース渡されてそれ言ってたら糞過ぎるな。
ソース無いならデコンパイルしろよ。 下手に作られたオブジェクト指向よりも
手続き型の方がメンテしやすいのは往々にしてある
オブジェクト指向のより良い設計を学ぶ機会があまりないんよね
日々の仕事に追われてばかりで傾いた家の屋根にもう一個家を作るみたいなことになる イベント駆動型プログラミングはオブジェクト指向が似合うよね。
まあ、GUIなんですけどね。 高度に抽象化されているほどソース読み解くのに時間がかかる
ライブラリとかはそれでいいかもしれなけど、実行系はやめたほうがいいというのが俺の結論 >>259
それだけだと
1つ目の構造体更新中に
別のタスクで2つ目の構造体を更新される可能性があるから
何個前のがロールバックするべきものか判らなくなる
全部の構造体をロックしないと >>252
アプリケーションもオブジェクト指向でしょ
ブラウザーのタブとかも 設計がしっかりしていればしている程、作る側は苦労するよな わしゃゴリゴリ書きたいんや！
オブジェクト指向くそ食らえ！ >>254
オブジェクト指向とか関数型プログラムは
プログラムとデータ構造をどのように管理するかの方法論なんだよ。実際のデータの管理は同じで出来るし、そこはDBMSがやるだろ。
情報処理は天才がやる事でバカは言われた事だけ
やれば良いんだよ。 >>276
DBMSが必ずあるとは限らないんじゃね よく分かってない奴がリードするとスレタイみたいになるよな
本当は相当分かっててかつやり慣れてるやつがやらないとダメ 「増えすぎたプログラマを振るい落として
単価を上げるためにより分かりにくく複雑化してます」
って言語作家の皆さん白状してる。 今頃言ってるw
そんなのプログラムやってるやつならすぐわかる話 >>258
幻獣というオブジェクトを作らなくても目的が達成できる要件のに、わざわざそういう設計して複雑にすることがあるといっている。 >>276
オブジェクト指向でトランザクション処理する時の
デザインパターンとかある？
関数型でも 例えばCTの映像からガンを発見するとか、
そう言う部分はAIで代替しやすいね。
多少なりともクリエイティブさが求められる分野は
それが難しいと思う。 >>215
そういうこと、
だからインタフェースをキッチリ決めないとすぐに変数のリードすら満足にできなくなる >>276
オブジェクト指向のDBMSって最低だよな >>245
>>247
>>249
>>263
マジで終わってる
そして iPad コンマが打てないのを今気づいてビックリしたw >>284
将来の事をどの程度見込むかによって変わるのかな
それはその担当者の責任で決めるしかないんじゃね >>282
ストラウストラップのインタビュー記事？
アレはネタ記事だから騙されないように。 オブジェクト指向がデスマーチの原因じゃない
大抵はプロジェクトに関わっている人間、特にエライ人たちが原因 >>289
マジそれ
>.216
見逃してた
すまん 要は汎用性持たせて使い回しや中途変更のしやすい道具って事だろ？
けどそれって基本設計がクソだとエラい事になるよな？
何でそんなもんを現場の下っ端にまで使わせるんだ？ >>291
リレーショナルDBじゃなくて
オブジェクト指向DBもあるみたい オブジェクト指向が使えないって人はJavaとかC++のクラスとか使えないってこと？
生産性が段違いだと思うんだけどなあ 情報の隠蔽はオブジェクト指向の主要な特徴ではないだろ 欧米では、アクセンチュアみたいなコンサル会社が
SE会社を持っていて、コンサル主導でプロジェクトを進める。
日本はコンピュータメーカーがSE会社を持っていて、
お客の言いなりで無理めな要件を丸呑みする。
そのあとは下請けに丸投げ。
下請けは孫請け、3次請け、4次請け、………
デスマーチはこうして作られる。 >>153
最初から作れる必要があるのではなく、
手を入れる手段がないのが問題なんでしょ。 つまり、真に必要なのはインタフェースであってオブジェクトそのものじゃないってことにもなるんだが
インタフェースが複数作られるとインタフェース間で競合が発生したり
インタフェース間の依存関係や共通の処理とかが出てくるとインタフェースが絡み合ったりする
そこを整理してすっきりさせるためのプロセスがオブジェクト指向 >>307
仕事で使う分にはすでにライブラリーはある程度揃ってるだろうけどね >>276
応答時間とか性能とかの要件を満たすためには
DBMSとか使えない状況もあるんじゃね >>307
すまん両方使えるての見落とした
ごめん なんとかUtilとかいう超巨大なクラスがある。
しかもstaticじゃない。 Ｃでもオブジェクト指向はやるでしょ
mallocとstructと関数のアドレス登録で >>315
もはやなぜまとめてるか分からないやつな
クラス内の変数にアクセスせずただ入れて出力を返すとか >>221
複雑なものは
やはり複雑なんだよな
使うぶんには楽チンだが
改修となると・・・・・ >>319
ラムダ式生成するためのユーティリティ関数は入力して返すだけで作ってた 設計7、製造3くらいの工数配分でないと酷いことになる。設計8でも良いけど。 >>326
設計→リファクタリング→設計→リファクタリングのがええよ
実際に触らないと思いつかない仕様を抱えてる客が多すぎる >>327
手っ取り早くプロトタイプ作って
仕様が固まりきってからコード全部設計し直して書き直すのが手戻りが少なくて良いと思う オブジェクト指向の黎明期は「複雑なデータ構造や
複雑なコードにシンプルなインタフェイスを付けて、
モジュール間の結合度を下げ、再利用性を上げて、
生産性をウンタラカンタラ」みたいな触れ込み
だったと思う。
でもこれって「複雑なクラスは誰がメンテするの？」
って視点が欠如してるんだよね。
純然たる（クラスの）利用者としては確かに
便利そうに思えるんだけどね。
抽象クラス以外の継承は一切禁止。
これくらいやらないと保守不能なゴミクラスが
簡単に作られてしまう。 >>309
内製基板にLinuxポーティングしてGUIアプリ載せて製品化とかやるからアセンブラ、C、C++までカバーしてるし既成ライブラリとか極力避ける組み込みの原野で戦ってるけど、C++が一番生産性高いのは間違いない。
メモリ容量から言えばC++とか超贅沢なんだけどこれは外せん。 オブジェクトは有用
無駄な継承はラビオリコードのもと >>332
だから複雑なクラスは作らないのよ
役割毎に分割する
100sを超えたら分割を考えよう そもそもオブジェクト指向でちゃんと設計できる奴が少ないからな。
理解してない奴がオブジェクト指向っぽく設計して、理解してない奴がさらに複雑に直してるんだろ。 >>343
ですな
なんで今まで誰も書かな買ったんだろ >>73
概念から変えないと本当には使いこなせない。頭の中をオブジェクトだらけに変更するのが先。 >>332
＞抽象クラス以外の継承は一切禁止。
＞これくらいやらないと保守不能なゴミクラスが
＞簡単に作られてしまう。
一切禁止とまではほんのちょっとだけ行き過ぎかもしれんけどまあわかる。
オブジェクト指向と言えば実装の継承みたいな考えが害悪。 1人や2人で作る小さい案件ならソースコードの
隅から隅まで把握できるから問題も起きにくい。
でも下請けに出したり大人数になると目が届かない。
そんな中で「開発言語はC++でよろ」とかやっちゃうと
品質の担保は壊滅的に難しくなるね。
まあC++に限らないけど。
MicrosoftOfficeとかどんな体制で作ってるのか
見てみたい。 >>348
あなたは知らない事をしっかり言える人
書き込みが遅れて見逃してごめん プログラマーとかそういう奴らには決定的にバランス感覚が欠けてる
いい塩梅になんでもやればいいのに、基本的に原理主義なんだよ奴らは A「〇〇を更新する処理を作ってくれ」
B「ほい、ちょこちょこっと」
C「え、〇〇を更新したの誰、更新したならこっちの関数を呼んでくれないと、GREPしたから全制御見直しして」
D「ちょ…処理中に更新かかったんだけど、なんで排他フラグ無視するんだよ」
E「ちょっと、チェックサム不一致が出てる！データ不整合だ、
この範囲にアクセスしている全制御見直しだ」
よくある地獄絵図 俺もオブジェクト指向はクソだと思う
原則データは全部イミュータブルであるべき ベンダーで作られたクラスを使うのは有益だが
プロジェクト単位個人単位では百害あって利益無し 苦労してインタフェース設計してもよりスマートな開発環境が出てくると使わないしなあ >>353
最近増えてるって聞いてたけどマジだったのか
若い奴が COBOL 書けなくておっさん駆り出されてるって聞いてたんで信じられなかった >>353
最近COBOLのままオープンシステム化する案件も出てるからねえ
オブジェクト指向よりプログラムの可読性を重視する現場ではね >>360
銀行、保険、自治体案件ではCOBOL技術者不足が目立ってる
*現行システムのプログラムソース追ってドキュメント作り直し
*それを受けてのシステム設計
*システムオープン化に向けてCOBOLのまま移行する場合、その実装
などなど 言ってなかったが未読があるがこんなスレでもすぐ誰かがレスをする
変わってねぇなw >>352
意外と小さいチームで作ってるんだな。
8人ならリーダーとサブリーダーの2人で回せるか。 >>348
LinuxやGitを産み出したLinusはこう言ってる
---
つまり、まともで効率的でシステムレベルで移植性のあるC++ってのは、
Cで使える機能だけに制限することだ。
プロジェクトをCに制限すれば、ぶち壊すヤツはでてこない。
それと、多くのプログラマーが低級な問題まで理解できるようになり、
理想主義的な「オブジェクトモデル」のクソとやらでぶっ壊したりしない >>369
お見事
でもあいつはもうここに来ないのが心残り オブジェクトが状態を持つので、そんなもの同士がイベントやメッセージでやり取りするとか状態バリエーションが膨大になるし、各オブジェクトの状態を理解してないとすぐに例外。
全てのクラスの全ての取りうるインスタンス状態を把握できるのは神しかいない。
関数型みたいなステートレスのが簡単だしテストも楽。 頭の良いやつと悪いやつがいるのが普通
そのとき安全側に倒すと頭の悪いやつに合わせざるを得なくなる >>355
これってオブジェクト指向で設計してたら予防出来る？ >>371
アホみたいなフラグの集合ができてなければ javaのアクセス修飾子が糞すぎる
protectedは自分と子クラスだけにしろよ >>375
自己レス
集合ならまだマシだな
ぶちまけた米みたいなどこに散らばってるのか分かんないフラグの群れじゃなければ >>369
ビジネスとしてプログラム作ってないからそう言う考えになるのかもしれないと思った >>369
Linuxじゃないけど大昔に4.3BSD reno版のソースコードを入手して読んだわけよ。
カーネルのソースコード。
無駄に長いわけ。
ハードディスクのドライバのソースコード1ファイルだけでも数千行あったと思う。
半分以上コメントだったけどね。
ダラダラと長いけど、読めば分かるのよ。
ベタッと1ファイルなんで。
「あっちのコンストラクタからこっちのコンストラクタに飛んで、
アレ？どこに戻るんだっけ？」的なのは一切なし。
無駄に行数長い。
でも読めば分かる。
ハイスキルのPGを集められるなら、
Cで開発するのは良い選択だと思う。
ただし「バッファオーバーランとかメモリリークとか
やらかすようなアホはC使うな」という説も一理ある。
否定できない。 >>371
関数型で自販機システム作れるの？
同じ10円が入れられた時でも
最初の10円か2枚目の10円か
商品の金額より10円少ない状態での10円か
とか状態を見ないと処理出来なくない？ >>374
別にオブジェクト指向である必要はない
責任範囲を明確にしてI/Fをきちんと設計すれば回避できる
オブジェクト指向はそのルールの部分が言語的に保障されている
逆にその制約が邪魔になって更新しにくくなるって話が>>1 めんどくさいからprivate付けない俺正解だったのか >>275
オブジェクト指向でゴリゴリ書けばいいじゃねえか 俺はGlobalsクラスを作って変数を共有してる。どのフォームからも参照できて便利だよ。 >>380
状態遷移図なり状態遷移表なりは手続き型言語でも普通に作れる ORMapperはお酢
オブジェクトは水
リレーショナルは油
結果マヨネーズという素晴らしいものが出来る。
素晴らしい！！ >>142
サブルーチンじゃ使い回しがしにくい
サブルーチンの骨組みだけ作ってプロパティを与えて使い回す
面倒な変数のネーミングも少なく出来る でもオブジェクト指向じゃないGUIライブラリとかあったら苦難の道のりが見えるよね >>362
メインが可読性の観点からなんか？
現行のコードを残した移植と今の開発担当者に引続き発注できることの方が優位に感じる >>389
大昔にwin32apiってのがございまして、
Hello, Worldに約2000行必要だったという… >>381
でもその責任範囲とかI/Fの明確化とかの建前を
実現できないから地獄絵図が繰り返されるんだよな >>377
ミスったら自分で謝れる人本当に居なくなったね
まぁソレを書いたのも自分なんだが >>380
入ってきたら一枚ずつリストに順番に入れとくだけじゃね？ >>393
3次請け4次請けだと「受注した時点で納期まで2カ月」
とかあるもんな。
「なんでもええから動くプログラム出してくれ」
みたいな切羽詰まった状況では
練りに練った美しい設計とか望むべくもないわ。
日本のソフトウェア産業は元請け下請け孫請け…で
工期も費用も中抜きされまくりだから
本質的に品質の向上は無理。
産業構造を変えない限り無理。 プロジェクトメンバーが構築フェーズから運用保守フェーズまで超優秀なやつしかいなければ有効だけど
実際は上から下まで色々なレベルのやつがいるからどこかのタイミングで当初の思想が破綻していく >>381
本当に馬鹿が増えたな
さっきも書いたけどあいつらはここにもう来ないから書くだけ無駄 >>386
その状態遷移表についてテスト必要じゃね？
全数やるか境界値だけやるかは置いといて
オブジェクト指向でも
単体テストとかやったあと
状態遷移表に基づいてテストするのは同じじゃね？ >>394
チャールズペゾルトさんのProgramming Windowsとか読んでたら
Hello, World 2千行ってのはだいたい常識だと思う。 >>396
状態を管理する手段としてリストを使うって事だよね
その状態を外部から更新されたら処理を間違うんじゃね？
クラス内部に隠蔽して守っておいたら良くない？
関数型はステートレスって書いてあったからどうするのかと思っただけ >>403
読んでねえし常識的なWin32プログラマはそんなに書かないと思うよ >>397
デザインパターン作っておいて再利用するとかは >>403
どんな高機能なHello, Worldだ？ でもお前ら底辺ＰＧが既存のオブジェクト以上の物をサクッと組めんの？(´・ω・`) >>362
ていうかわざわざ仕様書作ってJavaで書き直すより、Javaの上で動くCOBOLライブラリにCOBOLのソースを読み込ませてコンパイルすりゃ良いんでないの。 >>400
>> 403はすぐ上のあなたの書き込みも読んでなくて笑えるw 重複したスレが埋まったからこっちに来るとか分かり易すぎだな >>411
JavaでCOBOL書く方がはやいんじゃね Win32APIで窓枠作って
Direct3D初期化してポリゴンの立体文字表示しても2000行もいかない >>405
いや変更から守る必要は無いでしょ
関数のための状態管理を考えるのはオブジェクト指向の発想
むしろglobal scopeなstatic変数でも良いぐらい プライベートは保証なんだよ
保証が無くてもいいなら使わなきゃいいだけ >>410
顧客の独自仕様を実現するためイッテンモノのクラスは底辺PG謹製だぞ。
もちろんそのクラスは神PGが作ったクラスで構成されていふ。 日本の下請け構造やお殿様への設計レビューやプレゼンの文化がオブジェクト指向設計とウマが合わないんだよ。 >>417
371の
全てのクラスの全ての取りうるインスタンス状態を把握できるのは神しかいない。
についてのレスだよ また戻って来たw
俺が書くと古参のレスが止まるからも書くのやめるわ >>411
JavaのコンパイラにCOBOLソース読ませるって、、 >>371
疎結合にオブジェクトを設計できてないだけじゃないの？
各オブジェクトは他のオブジェクトの状態なんて気にしなくていいはずだが >>420
給料未満のVBAしか組めないうんこ製造機な俺とどっちがウンコかな？ >>421
いちおう、VBプログラマはVB.NET案件に投入されてる >>428
見たまま書くね。
Eclipe上で見たことないクラスが定義されてて、その中のメソッド内に汎用機系言語の謎のソースが書き込まれてた。
文字列をCOBOLソースとして読み込んでライブラリがVM上でコンパイルするイメージ？ ちょこっと纏められてパーツごとに見易いですよ〜くらいなモノなのに
馬鹿が勝手にパーツをガリガリ作り込んでブラックボックス化して自滅してるだけ >>424
底辺ＰＧ謹製でなんとか動いてるバグだらけの脆弱性の塊みたいなしろもの使わせさせるよりも
できるだけ既存のオブジェクトに寄せて作った方が顧客も安心だろ(´・ω・`) #include <windows.h>
int WINAPI WinMain(...) {
::MessageBox(NULL, "Hello work!"...);
} >>430
オブジェクトに隠ぺいしたほうが結果的にバグ組み込みやすいよ
mainとかで見えない存在は追加開発者には気付かれないで実装されるから
積み重なると酷いことになる
>>1で言ってる隠蔽の問題点はそこ
逆の発想でスコープを分け無いのよ >>434
ああ、Eclipseで読み込むって話か
それは出来るね
そういう案件も有るな
現行汎用機のCOBOLソース、そのままEclipseにコピーして移行するってヤツ
プログラム板で質問書き込みしてたヤツが居たな つまりオブジェクト指向は一度出来上がったらもう手出しができない、プログラムを拡張できない糞概念ということで合ってる？ キャラが大量に出たりするゲーム作ろうとすると便利なんだなぁ 要するにオブジェクト指向を使いこなせないクソプログラマーが多いから使わない方がいいよ
程度の話だろ >>445
できらぁ！
ただし改変を伴う拡張は初回開発よりももっとお金払え >>449
覚えていく過程で知った知識を実際に試そうとして無数の悲劇を生む >>146
swiftの言っている構造体とプロトコル指向なんてのはその発想では それ以前にオブジェクト指向のメリデメや向き不向きってのもあるから。
世の中の仕事にオブジェクト指向に適合しない案件が多いんだろうな。
間違いなく便利なのはIDEで．を打つとメソッドが出るところな。 >>451
階層化しまくってると丸見えでもそうなるってことですわ
大規模オブジェクト指向開発で似たような機能持つクラスやメソッドが別々に複数作られちゃったりするよね？
追加開発者には（見えているけど）見えてないってこと パターンやコーディングとかルールをガチガチに導入するからだな
デザインパターンもコード習熟に差があるからこういうのあると解釈しやすいね
つって作られたのに日本だと忠実にパターンに沿ってないとダメって発想になるからな
分業化するならIFだけ保障して実装は自由にすべきでしょ
人のコードを読みたいならスパゲティ言う前にコード読解力を高めるべきだ 先頭にアンダースコア使うと予約語だから禁止て怒られるわ糞が >>460
それは大規模である事に起因して発生する問題じゃね？
連絡とかのコミュニケーションとかプロジェクトマネジメントの問題の様に思う >>104
例えば日報書くときに決まりきったことはテンプレにしといて日付とかその日のことだけ書き入れるだろ。それがオブジェクト指向だ！ 我らを愛し慈しむ聖なるスパゲティモンスター様が
己の真の姿を地上の民に思い起こさせようと現れなさるのが
大規模開発のC++のコード上なのだよ >>463
プログラミングアプローチの問題でもあると理解してるのが関数型プログラミングを提唱している人達
スレタイに言う「デスマーチの原因じゃね」
まあ俺はそこまでラディカリストでは無いけど すぐスパゲティー言う奴いるけどクラス分割された
クラス数が多いpjにもスパゲティー言うからどうしようもない
単にコード読解力や追跡能力がなく開発ツールを十分扱えず
メンバーを信じず他人のコードに文句言いたいだけ
それが日本のプログラマー >>455
swift自体触った事無いし名前しか知らん程度だが、インタフェース同士の議論に終始させる事で物事をシンプルにするってのがキーポイントだと思うんよね
俺が考える強制は文字通りの強制で、つまりは
1)すべてのクラスはインタフェースを実装せよ
2)プログラムはインタフェースと実装クラスを完全に分離せよ(同じ階層に置くな。もっと言うと同じ領域に置くな)
3)実装クラス同士の結合は原則禁止
4)インタフェースの実装クラスの提供は言語ツールとルールに委ねよ(つまりDIみたいなもん以外使うな)
こんな厳格なルールをもつ言語があれば、なかなか面白いんでないかなと
時代に沿わないだろうし、面倒だろうし、これでメンテナンス性が保てるかは謎だけど、シンプルにするって目標は達成できる気がする >>464
はじめて意味わかったわ
オブジェクト指向ってそういうことなの？ 別々の部品がバラバラに処理して結果だけをやり取りしてるから処理を変えるときに
「この処理やってる部品はどれだそもそもいくつあるんだ？」ってわからないって話？ 全然違う
Javaの感覚でGoとかやってみ？
確実に炎上するしオブジェクト指向言語の有難みが
分かるから
今その工数を出せてる恩恵が何かを忘れているだけ 重いソフトにメモリリークが多いのはクラスのせいじゃない？ >>474
なわけねーよ
>>1
#define private public
しとけや
まぁprivateなメソッドなり関数は外部クラスにまとめてpublicにすべきなのは基本ではなるな。
っでjavaの場合、そのメソッドがオーバライドされてないことをインタプリタに教えてやるためにfinal化する。
それでもダメな場合もあるが、それは完璧アベのせいとなる。
実際、大型プロジェクトでクラスのデバッグってどうやってるんだろう。クラスのオーバーライドとか、多人数でやってると今なにをいじくってるのか分からなくなりそう。
動いているからいいや、というのは本職としては許せないだろうしなあ。 >>429
そだよ
オブジェクトが気にするのは
他のオブジェクトのI/Fが返却してくる値であって
本来は他のオブジェクトの状態そのものではない そのためのsetter,getterだろ
アフォか >>480
setterやgetterは設計時に意図していないタイミングおよびモジュールから呼ばれる可能性がある
その影響も考慮した修正が発生するってこと
最初からpublicならばどのようなタイミングで更新されるかもわからない
つまり、最初からあらゆる可能性を考慮して設計ができる
仕様変更が来ても安心だ
理想的にはね >>456
マジでそう思うがアンカー付けない貴方も同レベル オブジェクト指向なのにmain()を使っちゃってる言語w
それのオブジェクト指向的な意味を結果論抜きで説明できるの？ >>481
イミフ
全部publicにしたら、オブジェクト型の変数にnullがセットできるやん。
その変数使うときいちいちnullチェックすんの？
setter使う意味は、変な値がセットされないようにチェックするのが重要なんじゃん。 糞だがデスマの原因は別だ
むしろアジャイルとかなんとかのほうが危険度高い ゲッタ―を５回以上通過しないと 取れないなんて馬鹿げてる。
てか、目的は解っていてもそこを取得する手段を見つける事に時間がかかりすぎるんだよ >>486
nullableかどうかは
厳密にはその変数の設計であってオブジェクトの設計ではない
privateだとその辺が曖昧になっていてオブジェクトの都合でnot nullableに設計しているかも知れない
でオブジェクトが他のオブジェクトなメンバになっていたり
継承先のオブジェクトが参照していたりで、何階層もそんな実装になっていたらどうなるのか？
これをあとから変えると大変
最初の設計が悪かったオブジェクト指向のコードと
最初の設計が完璧な非オブジェクト指向のコードを比較してる詭弁ではあるんだけどね さっきまで書き込みがなかったけどこれがν速だ
まだ眠れない >>492
俺の世界だとprivateはそのクラス内で完結する扱いなんだけど、お前の世界線だと派生クラスから参照できたりしちゃうの？ >>354
いい塩梅にというのはソフト屋にはあってはならないことなんだが。
ソフト屋がいい塩梅のつもりで作ったとしても客はそれをいい塩梅だとは思ってくれない。
結局、どこをどうしたいか細かく書いてもらわないと客が望むものは出来上がらない。 汎用機COBOLからオープンシステム化移行しようとして頓挫した京都市自治体システムは裁判継続しながら、新たにキャノンitソリューションが受注したらしい
これも飛ぶな >>317
どうしても必要でなければわざわざそんなことはしない。
普通にサブルーチンコールで済む。 >>494
だから>>1後からどうもそのprivateなメンバにアクセスする必要があるって必要が生じた場合の話ね
君も言うようにobject内で完結すると思って実装しているんだ
さぁ大変だ >>496
IBMの汎用製品を使う予定だったヤツ？違うかなぁ？
あってるなら…京都側も意地だなぁ…キヤノンがやるのか御愁傷様w >>496
アンタ本当にいい書き込みするな
まだ眠れない 頭の悪い人がクラスを設計したから
後でprivateメンバーにアクセスしたくなるだけ メッセージ系を自前て作っているアプリやってるが馬鹿じゃねと思ってる、フラグ管理してるしそこ遅くて当たり前、ちなみにひこです
★★パチンコ換金営業は明白な刑事犯罪（賭博罪）です！
警察官ＯＢは定年退職すると
パヨク（在日韓国人）パチンコ屋に天下りして
年金が出るまで３〜５年ほど雇ってもらいます
警察の風営法検査の日時情報を漏らしたり
ヤクザから店を守る手伝いをします
そんな警察官ＯＢは、最も卑劣な売国奴です
パヨク（在日韓国人）パチンコ屋の犬です
パヨク（在日韓国人）パチンコ屋の社長（金持ち）は
そんな警察官ＯＢをトコトン馬鹿にしています
「警察官ＯＢは使い捨ての犬ニダ！」なんて言ってます
それでも警察官ＯＢは文句が言えません
年金が出るまで、ひたすら我慢です
その分、日本人には威張り散らしています
警察は自分たちの利権（天下り先）を守るために
重大な犯罪行為（賭博）を「見て見ぬフリ」しています
パチンコ換金営業は明白な刑事犯罪（賭博罪）です
今すぐパチンコ換金営業を全面禁止すべきです！
パヨク（ゴキブリ在日韓国人）に甘い「親韓政治家」は
次の選挙で「普通の人」になってもらいましょう
自分の選挙区の政治家さんたちが
パヨク（ゴキブリ在日韓国人）に対してどんな姿勢でいるか
次の選挙のために、冷静に観察しましょう
★★パチンコ換金営業は明白な刑事犯罪（賭博罪）です！
👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) 再利用可能な材料を作りながら家建てるようなもんなんだろ？もし利用しなきゃまるまる無駄になるもんな 本当のオブジェクト指向を知らない連中が
見よう見まねで作ってる弊害だな 結局すべての考え方はなぜそうしたかを理解して適材適所で使うしかないんじゃないのかね。
よくわからんままに教条主義におちいってもよいものはできんわさ。 プログラムが書ければ馬鹿でもプログラマーになれるんだな プログラムを書くにはバカでは困るんだがね
コーダーとプログラマーは違うというといいのかもしれん。
COBOL時代のコーダーと今のプログラマーね。
プログラムの規模を行数で語るかどうかって差かもしれん。 フレームワークの作り手はカプセル化
必要だろ
書き換えられたら、フレームワークの動作が変わるからな オブジェクト指向って要するに
入力と出力だけ決めといて挙動は全部ブラックボックス化するって話だよな
ブラックボックス指向でいいじゃん フレームワーク、OSとか考えるとそこと業務層のプログラムとは
違う気がするのです。 日本は企業そのものがオブジェクト指向になってるがな お前らデザインパターンもロクに勉強してないだろ？
批判内容が表面的で薄っぺらいから分かる >>323
JAVAでもできるようになったんだ
たぶん8からだろうけど
（匿名メソッドと言うかなんと言うか）
最後に触ったのが7 大昔の人「gotoは絶対に使うな」
昔の人「gotoは考えて使えば高速化になる」
今の人「昔の人って情報を更新しないからめんどくさい」 まあメソッドと関数の違いが
あいまいな奴らが使っても
害しかないだろうなｗ オブジェクト指向に限らないが、仕様書、リファレンスが大事だと思うんだよね。
なぜ、こう作ったのか、こう設計した意図などをつぶさに書いとけば、製作者の意を汲める。
かっこつけてるのか、実は設計意図が曖昧なのを隠したいせいか、人から指摘されたくないせいか、そこらへんを自然言語で説明しない開発してると、引き継ぎも難しいし、修正やレビューも捗らない。 >>527
Javadocとかコメントを適切に書いとけばいいって話はどうだろうか。
それとアジャイルだとドキュメントは後回しにされがちなにょうな。 何故ですマーチがあるか？
オブジェクト指向が障害？
一番の原因は
お客様の仕様変更だろ >>528
アジャイルは良く分からないけど、チャット内容が仕様書代わりみたいなものなのかな？
Java docもコメントもミッチリ濃厚で余計なぐらいに想いのたけを書いた方がいいと個人的には思うな。
良いプログラムはコメントが要らない！って言う人もいるけど、そりゃある側面からはそう最適化されたコードはそうなんだろうけど。
そもそも、そう組んだ意図や、詳細設計の正誤までも判断するためには、たくさん情報がないとわからないというか。 >>516
それぞれが勝手な設計をしてればそう
大先生が作った、処理の状況に合わせた
効率のよい理想的なモデルがあって
全員がそのモデルを、適切な処理で正しく使っていれば
効率はいいはず
という話だろｗ
だれがあんなの暗記してるんだよ
と個人的には思う >>530
メソッドによる曖昧さが享受できないなら
全部関数でようくないか？ 実は無能な上司が中途半端に
しかオブジェクト指向を理解してないことが
一番の原因だろしかもそれ指摘したら切れるるし
まあ人間関係を悪くするよオブジェクト指向は 「オブジェクト指向を知っている」
という奴は信用なら無いのは常識だろ
お客さんに聞かれれば
心苦しいが
嘘をつく必要はあるがｗ >>498
getter/setterでチェックして都合が悪い時は例外返せばいい オブジェクト指向の肝は
プログラム言語を自然言語の曖昧さを
もって使用できることだと思うが
たしかにこれ自分が小規模（いつでも
自然言語でコミュニケーション可能）な
環境で仕事しているからかも 大規模だと
また違う感想でてくるだろうな プライベートを触るってことは
誰かが作ったソースを別人が引き継いだってこと
そういうイレギュラーが発生してること事態が無駄でイチから作り直してもかまわん
そういう入れ替えが極めて容易にできるのがオブジェクト指向
だからデスマを生むどころかデスマ対応に強い 言語というか開発環境が数年ごとにコロコロ変わる
10年も経つと使ってたレポートツールが会社ごとなくなってたりする
全部作り直してたらオブジェクト指向がどうもクソもないわ モノ単位でクラスないしファイルを作ることだって聞いたよ 大混雑する駅のホーム
cxrRkP5N0が、その真ん中で爆竹を鳴らす
ホームの人々の多くが立ち止まり、ふり返る
しかし、暫くするとホームはいつもの様子を取り戻す
こんなの従来の言語等では簡単にモデル化は出来ない！
それを簡単にモデル化できるのが、オブジェクト指向の肝だ！ >>541
細かくできるなら全部バラバラの部品にしたほうがいい
再利用できる可能性が最も高くなるから
超細かい部品を自由に使って任意のクラスを作ればいい >>529
「一番の原因はお客様の仕様変更だろ」まぁそうなんだが、それでは開発者失格だ。
悪いのは
・お客様に変更の判断を下させた事
・それによるリスク説明と代替え策で納得させられなかった事
・事前にその仕様を理解させなかった事
・事前にその要求や問題を聞き出せなかった事
下っぱなら、自分の所のPMや本当の意味でのSEが無能であった事を恨め setterってJavaビーンのsetNameみたいなメソッドのこと？
それなら値の妥当性の検査はしないな。
オブジェクト生成して直後にオブジェクトの依存関係とパラメータを設定するんであれば、
コンストラクタもしくはinitメソッドか。そこでチェックすることはあるかも。
実行中にオブジェクトにパラメータ渡したり依存関係を追加・変更するんであれば、
setterは作らず別のメソッドを作りそうだ。changeStateとかaddNameとか。
setterで1つずつ渡すと、パラメータ間の相関関係もあって面倒だからまとめて渡すメソッド作るわ。
だが俺は底辺のWEB業務ロジックコーダーだから、そんな面倒なオブジェクト間の妥当性検査を実装する機会がない。
ライブラリも作らない。他のシステムと連携するオブジェクトも作らない。
作成したクラスはライブラリを除きすべて良く知ったクラスとして扱いsetterとgetterで中身はすべてオープン。呼び出し側が責任を持って中身を管理する。
妥当性検査をするのはHTTPリクエストの中身ぐらいだ。
無駄な検査をすればテストも増える。時間がかかる。金がかかる。そんなことをすれば誰も喜ばないどころか寧ろ罵倒される事態になる。
将来性のある汎用的なプログラムでもない。単なる使い捨てプログラム。
何か改修があれば、予算がついて調査・改修・テスト・リリースと行うだけだ。 >>542
まさにそうだとおもうが
ホームの人々の多くが立ち止まり振り返る
関数型だと
ホームの人々はそれぞれ違う振り返る方をするのを
いちいち記述しなければならないが
オブジェクト指向だと振りあえりメオッドで記述できる
これが曖昧さだとおもうが >>543
それをあんまりやりすぎるとすげー遅くなるよ・・・
それに結局なんのための部品だよ、これってレベルにまで落ちてしまう
いい加減ってのは難しいものだ オブジェクト指向の次のトレンドって何？
プログラム言語は最近あんまり進化してないように感じる。 >>516
全然違うだろオブジェクト指向ってのは設計思想の話
オブジェクトって単位にプログラム作って入出力ちゃんと決めて動かすって話でだろ
プログラム自身を見えなくするブラックボックスでは無い >>369
LinuxのmapはC++より高速らしいな オブジェクト指向導入前のwindowsだと
hello worldと表示するだけで2万行くらい必要だったらしいが オブジェクト指向設計
オブジェクト指向言語による実装
この2つがある
オブジェクト指向設計をしてC言語で実装する事も可能
100%全部オブジェクト指向設計を反映させなくてもいい >>549
関数型プログラミング言語とか一時話題にはなった気もする 最近javaを勉強し始めた
オブジェクト指向でつまづいた
ぶっちゃけ、privateって変数について言ってるんじゃねーんじゃね？
関数やメソッドについてprivateがあるのなら、そのprivateメソッドや関数は別クラスで管理できるだろうからそうしようって話なだけ
カプセル化とか関係ねーからｗｗｗｗｗ
論外
iOSのアプリ開発環境が>>1の思想だよね。
「使うな」って書いてあるメソッドも叩けるけどAppStore審査で弾かれる的な >>549
調べてないだけじゃ…
GoとかScalaとかECMAの新しい仕様とか眺めて見たら良いんじゃない？ 規模の大きなシステムでないと恩恵が無い
意味不明なカタカナのパラメータが増えていく 使うかどうか？判らないルーチンまで設計しチェックしデバッグしなければならない。無駄な工数が増えるだけ デスマーチの原因の10割が無能or馬鹿
発注側も受注側も、せめて応用情報レベルの知識必須にした方が良い
無資格者は仕事に携われないようにしろ 現実世界の仕組みに則して設計できるのが肝だが、
世界の認識にズレがあると問題になる >>38
国内の大規模デスマーチは人を増やせば増やす程、
生産性が落ちるから難しい
下請けに人を集めさせるとIT業界の底辺みたいなのが大量にやってくる やれる選択肢は与えるが、それがやれという意味になるわけではない。みたいな >>183
仕様にないことに最初から手を付けてたら値切られるだけだよ >>254
テンポラリのオブジェクト作って全OKに限り最後にatomicに更新する
オブジェクト指向も何も関係ない >>378
カーネルなんてシステムのほんの一部分に過ぎないし
何より1つも機能実現してないしな setter/getterあっても、setter()についてだけなら俺様最高！みたいなインライン化できるだけだし
それよりもメソッドprivateにされた方が鬼畜すぐるからやめちまえが趣旨だろｗｗｗｗｗ
>>1
正解。
実はオブジェクト指向、協業するときどうこうという理由上げる三流エンジニア崩れがよく使う言い訳なんだが、結局、複雑な仕組みなので、相互で齟齬が生まれ、手戻りがひどい。
関数型がもっともシンプルで良い。
逆を言えば少数でやるならオブジェクト志向も悪くないが、日本のバカSIは大人数でこれに手を出して、見事に手戻りだらけ。機能の追加もままならないから、高くついてる始末。 >>37
残念だが継承繰り返して、複雑化してるのが現実。
結果あると思ってた機能がなく
あったはずのものが削除されてて、現場混乱。これが日本のバカSIerの現実 >>45
正解。
普通に関数型でやったほうがバカでも組める
とくにコミュ障害な日本のバカエンジニアにはね >>569
オブジェクトって言ってる時点でオブジェクト指向前提じゃね？
オブジェクトのコピーを作るとき参照してるオブジェクトがあったらどのレベルまでたどってコピーするの？
複数のオブジェクトをコピーしないといけないしコミットするまで排他制御しないといけないけどどうやって実現する？
全部コピーするだけのメモリとか確保できる？
関数型プログラムではどうするの？ >>38
人増やせば増やすほど生産性落ちますよ無理ｗｗｗ。
君のようなど素人じゃわからんだろうがね。 初心者だが、インスタンスとかクラスとかプロパティとかいう、このスレで出てくる単語が分からない
だれか教えてくれ >>574
それって関数型言語でも
callする関数の仕様を誤認してたら発生する問題じゃね？
プロジェクトマネジメントの問題だろ アセンブラで制御系ゴリゴリな人間にはイライラさせる指向 >>118
最近のPCは性能が昔に比べて格段に違うから
BASICライクでもいいと思うんだけどね。
>>576
同じ意味の値を複数の箇所で持つなバカ！！
で終わり
デスマーチの原因は作り方じゃなく、自分で仕様も整理できない無能クライアントと営業の口約束と昼真っからソープ行って石鹸の匂いプンプンさせて夕方帰社してくるPMだろ 自分のこと棚上げしてウジウジ言ってる無能はプロジェクトに要らない
明日から居なくても困らない 優れたプログラマのオブジェクトはアクセサが適切。
ダメなプログラマのオブジェクトはアクセサが不適切。
ダメなプログラマでも優れたプログラマのオブジェクトを使えば何も考えなくても組める。
優れたプログラマでもダメなプログラマのオブジェクトを使えばイチイチ中を確認しながらじゃないとバグる。 >>13
なんでも出来ちゃう言語だから、他の言語にすぐ移れると思うけど たかがいち商社の子会社向けシステムで3年デスマ
どうしてこうなった
そしてどうしてまきこもうとする ところで美少女ウンコパラダイムの問題は解決したの？ そこら中で車輪を量産しなくなっただけでも昔よりはマシだが、
正直車輪以外の何か（オブジェクト）を再生産してるケースは多いかも
当初から言われてたクラスライブラリーの学習コストは相変わらず
計算機科学者の夢とIT土方の現場とは全然違うってのが未だに変わってない >>587
業界長いけど、お風呂入れてもらったPMの話は聞いたことがない… SEだけど、プログラミングしたことない…
ほんとベンダーさんには頭あがらん >>31
そのフレームワークがオブジェクト指向の産物だろ >>601
プライベートに隠蔽してたモノをpublicにすればデスマーチ始まるよ 関数型ってつまり手続き型ってこと？
ずっと手続き型で作ってきてやっとオブジェクト指向覚えたのに >>597
元メーカー系SEだが、
届いたデスクトップPCの配線ができない
女SE居たの思い出した。
自社製PCの配線は出来ないが、
部長の蛇口とは上手に配線してた。 >>8
もしもあなたが銭湯に行ったとき
股間を隠すか否か
オブジェクト指向の発案者は股間を隠すべきではないと言っておられる >>587
お人好しな営業はまずだめだな
客の無理難題を丸呑みしがち >>561
使うかどうか分からないなら
そんなもん永遠に使わないから
作らない方がいいよ
使い回しできるオブジェクトなんて
ほんの一握りなんだしさ >>544
「前回、機能<乙>について、A案とB案で、B案を選択しましたよね」
お客様「いや、機能<乙>自体俺の勘違い。機能<悦>を作って欲しい」←勘違いって言ってくれっるだけマシ
こっちのプリセールス（調達）の内容を審査してGOを出したのはお客さん
審査に関してはこっちは口を出せない 美少女クラスの排便メソッドで管理しているprivateの宿便プロパティを直接触る必要が出るってことか
クライアントを説得して牛乳浣腸はあきらめてもらうほうがいいな 別に後からアクセスできないコードが在っても構わないのでボテボテ化を許すか許さないかだけの問題の様な気もする >>612
美女に排便メソッドを持つ尻の穴インタフェースが実装されて
排便メソッドは自身がprivateで持つ宿便キューからpopする形式だった場合、
美女にimplementされた尻の穴インタフェースに
宿便キューの中身を返却する浣腸メソッドを追加して
宿便キューに割り込みが必要になった場合に浣腸をコールするように修正しないといけない
→デスマーチ
ただ、最初に宿便キューを別のオブジェクトである宿便キューマネージャで管理していれば
宿便キューマネージャから取得したキューに簡単に割り込みで浣腸を実装できる
要は最初にどう実装するか問題であってprivateがどうのという話ではない
publicで実装しようが、最初の実装が悪けりゃ他制御に干渉してスパゲティになるのだから >>612
老朽化して人工肛門にする必要が出てきたときに手術できないという話 >>618
臓器が完璧にカプセル化されてる。
見えてるのは外観だけ。 たぶん、機能分割が適切じゃ無かったんだろ？
将来の変更に耐えられる設計って奴な。 >>623
カプセル化してるとそれが出来ない場合があって面倒が起こるって事らしいが
ある機能が、クラスＡからクラスＢのルーチン呼んで実現してるから
クラスＣとしてそのルーチン使ったシステムを組んだ
しかし元の機能が修正の際にクラスＡ以外のアクセスを禁じてしまい
暫くして、以前は動いてたクラスＣが動いてない事が解った
クラスＣを書いたプログラマは既に退社してて、コードを見てもバグは見えない、直せない？
とか言う事態が起こりうると >>605
マジか？
プラグアンドプレイ最高だな。 >>586
ちょっと何を言ってるのか意味がわからないです >>624
それ手続き型でも発生する問題
callする側は全部調べてから修正するようにプロセスを見直すべき >>103
Androidだと逆にそれが問題で「いつまでもあると思うなそのメモリ」状態になるんだよ まあVMで動いてるんでデバッグは楽な部類なんだけどね >>550
みずほは最後には中国人、ベトナム人が入り乱れてたらしい
りそな銀行みたいにCOBOL→オープンCOBOL(MF-COBOL)に移行した方が楽だったと思われる
あと、京都市のシステム案件は元々の原稿汎用機のサポートしてたNECが受注にすら参加しないヤバイ状況だった
(現行汎用機のシステム定義書類が全く無い)
俺も過去、他の自治体でNECがサポートしてる所の汎用機→Windows NTサーバーでのVBでの自治体パッケージシステムへの移行作業したが、現行NECオフコンで稼働してる内容のプログラム定義書類が全く無かった
NECがサポートしてる自治体はほとんどコレ >>8
8ビット用にturbo Pascalっあったでしょ
それの5.5からあるぞ >>634
WizardryはTurbo Pascalで書かれてたんだっけ？ >>632
そういうのは京都市とかが持ってるものじゃないの？
他社から資料とかもらえるの？ 機械学習もMATLABなら簡単なのに
Pythonはいろいろ足してTensorFlowを入れて煩雑の極みってのが最悪である >>637
機械学習と一まとめにするけど
方法が色々あるからな
主成分分析とディープラーニングじゃ全然違う >>635
その発展でMacはObject Pascalでアプリケーションが作られていて
Object PascalをWindowsに移植したのがDelphiで
BASICに移植したのがVB
NEXT STEPのアプリケーション言語のために
Object PascalをCに移植したのがObjective Cで
Objective CをベースにJava言語が作られた
マイクロソフトのC#は、どちらかというとDelpiベースのC++実装であるC++ Builderの後継であるが
起点がObject Pascalなので似たようなもんだろう
NEXT STEPをベースにmacOSが作られたので
macOSのアプリケーション開発言語がObjective Cになっている
iOSでもObjective Cで
そのiOSを真似たAndroidではJavaの言語部分だけを使っている >>632
ほかのベンダがサポートしてたら
そういう資料を他社に開示するの？
顧客の機密事項なんじゃないの？ >>636
無いよ
俺の移行担当した自治体も定義書は?
て、聞くとサポートしてるNEC担当者の頭の中、と言う事らしい
自治体のシステム担当者は異動が多いので引き継ぎもマトモに出来て無いし、現行のシステムが何故、こう動いてるのか理由は知らないが、動いてる結果が正解、と言う事
なのでデータ移行の為の情報として現行コード体系表提出してくれ、とお願いしても、そんなモノは無い、で終わり >>640
基本的には機密事項かも知れないが、システム移行の主体は自治体だからな
自分たちがシステム変えたいのに、現行システムの稼働仕様を提示しなかったら移行請け負った側も動き様が無い >>642
自治体から聞けばいいんじゃね？
回答を得られないなら自分達で調べるとか金払って情報を買うとかするんじゃね？ >>641
それってベンダが何処でも起こりうる事じゃね？
自治体側が管理してなかったって事だから
昔はITILとかいう概念がなかったから仕方ない面もあるだろうけど >>639
Object PascalベースのDelphi作ったのはアンダースヘルスバーグだな
C#、J#もコイツが作った
ヘルスバーグに言わせればマイクロソフトの言語仕様作成担当者はレベルが低くて話にならなかった、とか言ってたな
Delphiはボーランド→エンバカデロと売り主がろくな会社に恵まれず、今やDelphiなんてJavaやってる若いプログラマは知らない 継承は少人数でやってる分には超便利
実装の継承も多重継承もどんどん使って差分プログラミングだ
ゴチャゴチャしたらリファクタリングすりゃあいいんじゃ オブジェクト指向を取り入れた某ウィンドウズAPIのハンドルだってCloseHandle()で破棄できたりできなかったりでで多態性が破綻してるしな >>648
そいういのをネットに書き込むのはいいの？ >>651
良いに決まってるだろ
言論封殺して日本が良くなると思うな
昭和じゃないんだぞ >>651
京都市,システム移行,頓挫
で検索したらいくらでも出て来る情報だが 京都とか書面化できない仕様が山ほどありそうだな
部落とか貴族とか… >>651
そもそも、システム改定したい、と言ってるのに現行汎用機システムの仕様は見せられません
じゃデータ移行の仕様も作成出来ない
20年前はそれで通ったかも知れんが、今じゃ裁判やったら負けるよ
実際、京都市は他の部署のシステム移行で同じ様に現行システムの仕様出さずにシステム移行をさせようとして裁判に負けてる
今回も多分、負ける 前回の判例有るのに、また同じ事やって請け負いit企業に安くシステム以降させるのは悪質極まり無い
こういうのは裁判で敗訴させて自治体の態度を改めさせる方が良い >>651
いちいちビビりすぎだわ
お前氷河期だろ？ 既に京都市は前回の負けた裁判でそういう自治体と言う事が明らかになってる
それを今から違うとか覆せないから
裁判で一度負けると言う事はそういう事 >>467
何故日本のことしか知らないのにニホンガーしちゃうの 最近は中型大型汎用機からAS/400へのマイグレーション案件が結構有る
COBOLのままシステム移行出来て、RDBにデータベース移行出来る
銀行系も一気にオープン化するのが良いのかどうか良く考えるべきだな >>1
オブジェクト指向を理解できないPGがクズなだけでは？ 資料が存在して開示しないのか、
そもそも存在しなくて開示できないのか。
そもそも存在しないなら、
開発元にカネを払って作らせればいい。
それすらできないなら移行を諦めればいい。
業務が止まったなら責任者のクビを刎ねればいい。
仕様が開示できないなら、
そんなシステムは捨てればいい。
職員が手作業で行えばいい。 >>資料が存在してても開示しない
この場合は悪質
>>資料が無い場合、開発元に金払って作らせる
その金がもったいないから、やりたくない
どっちに転んでも施主の自治体が悪い >>665
as400にOracleの組み合わせ多いよな。
この場合、オープン系システムになるのか？ >>665
COBOLやってる奴ってRDBにカーソルで一件ずつ読み込んでそうで草
つーか、ObserverパターンにしろReactiveXにしろ、配信者と購読者はそれぞれ独立してるから意味がある
つまり配信者は配信者の仕事をすれば良いだけで、購読者がエラーになろうがなんだろうが関係ねーってのが今の流れでーす。
もちろん配信者がエラーになった場合、購読者側の処理は独立して一緒になってエラーになるとかありえないし。
イベントが繰り返されるような場合にそなえてFluxのようなパターンもある。
なに複数の構造体に値をコピーとかｗｗｗ寝言言っちゃってんだよｗｗｗｗｗｗｗ
オブジェクト指向って何？
(´・ω・`)
現象論的アプローチってこと？ >>210
>>464
機能ソートの構造体ってこと？ >>666
オブジェクト指向って何？
君は自分の言葉でそれを説明できるくらい理解できてるのかな？ >>661
社内の人事はどうだろうね
ビビってないなら匿名掲示板じゃない所に書けばいいのに 結局、現状分析から仕様の取り決めが8割で、あと2割がプログラム。組み方はそれぞれ一長一短あるので、規模や目的、人員やチームスキルに応じて使い分けるべき。保守人員のことも考えて、可読性も大切にすべき。 >>656
裁判で負けそうな相手にはネットで私刑しても良いって事？
そんな権利ないんじゃね？ 今の方がコンプライアンスとか厳しいから
いろんな自治体からの受注が出来なくなるんじゃね？
機会損失が結構な額になりそう >>686
わらわら沸いて来る京都市擁護気持ち悪いなあw
いずれも公知の情報だろうがw みずほ銀行なんか内情が知れ渡ってるけどみずほが訴えた事は無いな 京都市の問題は過去、既に裁判で負けてる事だろうな
その上で守秘義務等で過去のベンダー訴えても既に裁判官の心証が悪過ぎる
そんな事に労力使うぐらいなら、新しい移行担当業者と協力して早くシステム移行する方が賢い そんなこと言ってる間に平成は終る。
役所の書類は和暦だろ。どうするんだ。 >>693
それも有るから裁判やるよりシステム移行が重要 マシン語だとレジスタ処理も完全独立でサブルーチン群を組んで、他のプログラムでも流用させたりするけど、
（もの凄く原始的な意味合いでの「モジュール化」みたいなやつ？）
単にレジスタ保存が保証されないってだけで、事前事後にスタック処理しておけばいいだけだもんな >>675
モデリングはどちらかと言えばプラトン的パラダイムだな 多重継承ってのが使い方によちゃ便利。
下手するとグチャグチャプログラム。 安倍がらみで財務省の人間が2人も死んだみたいだしな。
資料を出せない京都の役所から手を引きたがるのもうなずける。 理解した上で使っている奴はいい。
便利だね！と言って使い倒している奴は駄目だな。 どのレジスタにデータが入っているか確認して、そのデータを後で使うときには１ステップ減らせるんだよな。 自治体が担う業務は総務省とか国の指示
によるところが大きいんだろうから
他の自治体のシステムを担当していて
ベンダ側の知識や技術があれば実現できたんじゃね？
なんでそのベンダはその仕事を受けたのか？
あと要求変更も合意したんじゃないの？
ベンダ側の能力不足も実現できなかった要因じゃね？ >>690
内部の評価をするのに裁判する必要は無いのでは？ >>691
その裁判って最高裁まで行って確定してるの？ >>691
守秘義務を守れないような所に発注する依頼主はいないから今後の仕事に影響する >>656
裁判になってる件と今回の件って言ってるから
別件だよな
裁判の件とは別の件について書いてるってこと
守秘義務違反じゃね？ >>708
自治体だろうが依頼主は関係ない
問題は守秘義務違反じゃね？って所 >>711
誰が、は俺には特定できないが
京都市とベンダのやり取りに関してじゃね？
守秘義務契約は最近だと普通は入っているんじゃね？ >>712
その特定出来ない書き込みしたヤツがベンダあるいは京都市の関係者なら、そうだろうね
それ以外の第三者が人から聞いた話を書き込みしてたら、伝えたヤツまで探す必要有るだろうね >>713
裁判する場合はそうだな
しかし依頼主が依頼先を選定する場合は
依頼主の都合で選定すれば良い
信用に足らない所を候補から外すのは普通に行われると思う >>714
>>信用に足らない所
ベンダの事か?
まあ、そうだろうが少なくとも新しい移行作業業者は決まってるし、今のシステムの運用業者は対応しない、て事は誰が怪しいかは何となく分かるな >>715
派遣とか外注とか請負業者とか
候補はいろいろあるんじゃね？ >>716
ふーん、、
で、お前さんが候補を選ぶの? 裁判になってる件だと調べたら出てくるのは
京都市、システムズ、NEC、キヤノンITSだけど
それとは別件っぽい書き方だけどな
そもそも嘘だったら偽計業務妨害になるかもしれない >>718
>>それとは別件
とは俺は読み取れなかったけどな
お前さんの主観じゃないの? >>718
https://www.google.co.jp/search?q=京都市+システム+失敗&client=ms-android-huawei&gbv=2&sei=aMuBW4i_Bs77-QaGhI6gDw
そもそもこれだけ引っ掛かって来る内容だし >>717
俺が選ぶ立場にいるわけないだろ
なんでそう思った？ >>719
>>656をどう解釈するかはいろいろあるだろう
それぞれの立場で解釈するだろうから >>722
色々影響するしやってはいけないことだから
警告のつもりだ まあ個別の案件出したら守秘義務違反を疑われるのは当然だわな >>38
人月の神話という名著があるから図書館で借りてでも読んでみるといい >>87
困ったことにC++は手続き指向言語としても成立する >>38
ワロタ
こういう風に思ってる上層部まじでいるからな >>727
プロマネ以上の人には読んどいて欲しいよね >>728
だから中途半端なんだよな
大人数で開発するには、フリーダムな言語は危険
コーティング規約守らないやつもいるし オブジェクト指向ってのは、
量子力学の世界観を、人間が認知できる物理学の世界に落とし込むことや。 >>732
波動方程式をシュレディンガー変換してエルミート解からコペンハーゲン状態を分離することでボーアモデルを構築するという理解で大丈夫でしょうか？
オブジェクト指向を一言で説明すると、よく理解してない人間でもオブジェクト指向を語ることができる。この一言にしきますね。このスレ見てればわかる。
つまり癌はオブジェクト指向そのものではなく、それを使う、っていうかよく理解してないバカジャップス共ってこと
>>729
一人でやったら十日かかる仕事も100人でやれば一時間もかからない >>609
いやだから客に必要なのが機能乙なのか悦なのかを最初の段階で、客に認識させれなかったメーカがヘボいと言ってる。無論、下っぱ技術者はそんなこと関与できないから自分所のPMやSEを恨めと
まぁRFPレベルで 機能乙と言っていたのを悦と言い出したら、流石にメーカ責は0に近づくがその場合でもRFPのQA等で必要事項や「こーゆーのが必要(便利)だが本当に乙？」って確認は出来るし、そんなレベルの変更なら金や期間の交渉も出来る
→もし、そんな変更で交渉すら出来ないなら、やっぱりメーカ側にヘボい人間がいるからソイツを恨め
あー念のため
気持ちは分かるよオレもいろんなレベルで殺られるし。でもソレを全て客のせいにしてたらダメだって >>735
100人でやるなら
まずその100人を調達するためにマネージャが一か月くらい調整しないといけない
そこから開発体制を整えて、開発環境を整備して
仕様書を書いたあとは、制御間でレビューをやって
まぁ、1人で10日かけたほうがはるかに速いよ >>641
こーゆーのは逆に客の問題が大きい
移動云々なんぞ関係ない。組織として把握する必要があるのに把握してない。
あまつさえメーカの担当者の頭の中って状態を許すなんて甘えてる通り越して狂ってる。本当に成人してる社会人か？ >>737
まったくまったく
クズみたいなプログラマーを100人より精鋭10人でやったほうが絶対いいもんは
できるんだけど期間はどうしてもかかっちまうよなー
# いや、そうでもないかもしれないが・・・ >>735
マジで言ってるのか？
もし貴方がIT関連でソコソコの立場ならデスマーチが発生した原因の多くの％を担っているのは貴方だ
まぁその発言しか見てないから、ちゃうかもしれんがw >>740
>>735みたいにプログラミングを伝票入力作業かなんかと勘違いしてるあほうがいるんだよねえ。
COBOLのコーダーの時代ならそれは正しかったのかもしれないけどね。
今のプログラマーとかつてのコーダーの違いがわからんクズはさっさといなくなってほしいものだな。
ステップ数なんかで規模をはかるのをやめてくれ。 >>745
古典関数型だろ
MLをBASIC風にした感じだし 一人ならカレー作るのに二時間かかるが、百二十人でやれば一分でできる
と言われればおかしいとわかるのに、こと開発になるとわからん人がいるみたいだな >>746
分かって言ってるんだよ。
分からないって言えばゴリ押しできるから
分からないふりしてるだけ。 >>747
「人月の神話」に、それと全く同じ事が書いてあって草
しかし、銀の弾丸はいつになったら出てくるの？
orz こういうスレ多いけどコボラーを最前線に引っ張り出すフラグかなんかなのかな >>749
ソフト開発ってなぜか特殊だよな
建築や土木は図面が無いと作る事が出来ないのに
ソフトウェアになるといきなり「出来る」に変わる >>752
と言うかCOBOLが再評価されてるからな
Javaへの移行で生産性は上がったが、施主側が見て理解出来ないオブジェクト指向じゃシステムの良し悪しを判断出来なくなってるから
そこへ来てJavaにオラクルがライセンス課すとか言い出したから運用コストとの関連でCOBOLのままシステム改定するのもアリ、だとなって来てる >>753
物理的な形状を持たないから誰もが簡単だと思い込みたがる 確かに配列や辞書型で持ってドットでアクセスする方が楽だわなあ。
クラスにはユーティリティ的なスタティックメソッドがあれば十分だと思う。 >>185
フレームワークとエミュレータの違いは大きい 大きなプロジェクトだとコーダーはそういうの意識することないよね
小規模だとどっちでも変わらない気もするけど
どのへんに当てはまる話なんだ オブジェクト指向の効率化は
生産性コストダウンの効率化とは全く異なるものである
これで話し終わり オブジェクト指向も単に設計の道具に過ぎないからなあ
道具を使えばいいのかというとそうではない
漫然とただドキュメントを書くことが設計だと思ってる奴が大勢いる
しかも、いわゆる上流に行く程そういう奴が多いのはどうしてだろう
業務システムの設計だって極めてクリエイティブな仕事なのに ■ このスレッドは過去ログ倉庫に格納されています
