実は「オブジェクト指向」ってクソじゃね？これデスマーチの原因じゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 結局すべての考え方はなぜそうしたかを理解して適材適所で使うしかないんじゃないのかね。
よくわからんままに教条主義におちいってもよいものはできんわさ。 プログラムが書ければ馬鹿でもプログラマーになれるんだな プログラムを書くにはバカでは困るんだがね
コーダーとプログラマーは違うというといいのかもしれん。
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の宿便プロパティを直接触る必要が出るってことか
クライアントを説得して牛乳浣腸はあきらめてもらうほうがいいな ■ このスレッドは過去ログ倉庫に格納されています
