無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
オブジェクト指向ってクソじゃねぇかよPart3 ･
https://mevius.5ch.net/test/read.cgi/tech/1542884872/
隠蔽って別にpublicにすればいいだけじゃねえかｗｗ
そう、オープンソースならね
遮蔽した意味ねぇw
COBOL一筋なおっさんに多いw
逆にJava厨な俺はCOBOLがちんぷんかんぷん
>>78
> 逆にJava厨な俺はCOBOLがちんぷんかんぷん
そういうのもよく聞くけど不思議に思う
あんな古臭い言語なんて簡単に理解できるでしょ？
実際に使うパターンだって少ないもんだし
ただ、よく読み込まないと全体像が理解できないってのはあるだろうけど
言語が理解できないと言うよりただ面倒くさいって話だと思う
そんなんでデスマーチになるなら、開発者のスキルを疑った方がいい
素人同然の人間を放り込んだらデスマーチになるに決まってる
派遣発見w
今時エクリプスみたいなオワコン使ってるとか
getter/setterは自動で生成できるから簡単という話の要点が読めずに、
エクリプス云々言い出すお前が発達障害なのは分かるｗ
「絶対に使うな」
使わないと(使命感)
無茶振りかつ納期が決まっているのが日常だからじゃないですかね
「毎回三回宙返りを決めろ」みたいな話で、
戦術的な勝利を積み重ねても、戦略の時点で負けているわけですね
結局それだね
人間側が悪い
あってるだろ
今後の保守に影響あるだろうが
本来は実装の意図が明確になって保守が楽ってのがメリットでもあるんだぞ
改修の時に中身いじらなきゃいけないって時点でキチンとモデル化出来てないだけじゃん
まぁ、まともに使われてるの殆んど見たことないけど
あるいはアドホックなコードでスパゲティ化
APIなど不動固定のもので留めて置くべきかもね
その通り、フレームワークとそにユーザは結構違うよね
オブジェクト指向がどうこうよりも、命名規約がバラバラ、変数のスコープがいい加減とか、統一感がない実装が一番厄介だと思う
下手な実装でも下手なりに統一されてれば割と読める
って一流もいる
が
現実の馬鹿はそれを超えてくる
その通り、設計書を書けない人は脳内コーディング出来ない人。「実装しながらじゃないと掛けません」←経験不足か脳の限界
オブジェクト指向で失敗するやつは何やっても失敗するような気がするわ。
参照して取れる値が違うとかありそう
>>80
アクセサを脳死で作るとカプセル化にならない
アクセサはそれが本当に必要か、設計をよく考えてから作るといいね
オブジェクト指向自体が古い発想だからなあ
80年代のパソコン誌でSmalltalkがよく話題になってたっけ
俺は組み込みで今もCと時々アセンブラがメインでやってるから
時々趣味でC#やる時以外に思想とか触れる機会がないが、
他にも色々より進んだのあるんじゃないの？
というかデザインパターンとか、全体の設計の次元の方が
もっと重要なんじゃないのかな、アーキテクトだっけ？
戦略と戦術というか
>>83
「プログラム」という考え方がもうすでにやや古い気もする
アルファベットを1文字間違えただけで動かなくなる訳だから
（もちろん、実際問題になるのは違うバグだとしても）
「プログラム」によるシステム自体、大変脆い訳だが、
では、機械学習によるAIに全て切り替わるか？と言ったら当然違うし、
その辺を組み合わせとか、第三の方法論とかでモニョモニョっとやりそうな気もするけど
デザパタはオブジェクト指向をちゃんと理解できてないと無理だろ
継承とかオーバーライドとか
んで、オブジェクト指向を理解するには、まずみっちり手続き型の関数を覚えて、
使い方をマスターせにゃならん
メモリ上の挙動を完全に把握できるくらいに使いこなして始めてオブジェクト指向を使いこなせると言える
マーケッティングのために
「オブジェクト指向はメモリもポインタも意識する必要ありません。だから簡単で文系でもできます。」
と言うけど実際は違う
このマーケッティングがデスマの主な原因
工数の目算を誤って見積もりが甘くなるのが原因
>>85
JavaもC#もJITのコンパイル後を考慮した速いコーディングがあるのを最近知ったよ
CもC++もやってるからメモリリークには元々気を遣ってるけど、
C#とかもやっぱりリークするって聞いて基本は大事だと思う今日この頃
ユーザーとか元請は何も悪くない
なのにみんなデスマ巻き込まれて人生狂ってかわいそう
大企業の上流行程にいる奴はそもそもメジャーなプログラム言語すら理解できてないだろ
やっててC++をかじってる程度
オブジェクト指向の理解も怪しいし、デザインパターンなんか誰も理解してない
年功序列だから、その人間が教育を受けた時代はBASICでGOTO文を打ってた世代だろ
だからジャップメーカーのIT機器はクソアプリしかバンドルできないんだ
大手ほど酷い
いろんな文献読んだのにふわっとしか把握できてなくてすんげえイライラする
たぶん俺の各コードめっちゃやばいんだろうなとは思ってる
ちなみに変数は全部publicにしてる
『オブジェクト指向でなぜつくるのか』がオススメ
概念ベースと実装ベースでの違いがよく説明してある。
>>96
全部パブリックとかクソコードかかれるとブチ切れるわ。
setter とかで値のチェックできないよね。
setterで不正な値（例えば1～9以外）をはじくとかしてても、public な変数宣言されたら意味ないよね。
private な変数を public に変更してくるばかがいるんだよ。
プロジェクト毎に、ゼロから作ってりゃ意味ないし、
むしろ、使わないほうが効率いいんじゃね。
>>108
オブジェクト志向で再利用とか相当古いぞ
再利用しないわけじゃないが、継承やインターフェースは再利用が目的じゃない
これなんだよな
カプセル化だの隠蔽だのってのはそれ実現するための手段であったり副産物
カプセル化自体が目的になってる奴もいるけどさ
色々作ってるとこれ絶対いつも使うよなっていう定番を再利用する為のもんだね。
毎回微妙に違うものを無理やり再利用したら効率悪化する。
>>150
でも作るたびドンドン良くなっていくから、結局、昔の物は使わないというねｗ
せいぜい、過去互換性でデータの同期取る時くらいしか使わない
そんくらい市場環境の動きが早すぎる
言語仕様なんて枝葉の問題でしかない。
多分この有識者連中は業務システムのスクラッチ開発経験に乏しい。
ミスリードも大概にしてほしいし客側は騙されてはいけない。
まぁ、やってみりゃわかるけど、再利用性はそんなに高くない
使う場所は使いまくるけど、全体ではごく一部だよ
あと、システムが複雑化してくると、あやとりになってくるからなＯＯＰは
そのあやとりを上手くやるコストがメチャメチャ高いんだ
特に教育投資や引継が大変
そこ全然やらないからジャップはダメなんだよ
十分教育されてない新人を入れるってのは、目隠し状態であやとりに参加させるようなモンだ
失敗するのは明かだよね
それだけで発注リスクの大半は無くなる
>>116
それはウォーターフォールだなw
昨今は制御系でもアジャイルが多いんだが、おかげで客先から離れられん。要するに派遣だw
アジャイルを自社でやるとデスマーチになるが、客先でやる分にはダラダラと長くなるだけだと言う違いがある。
そりゃ、結果を見て仕様が変われば納期がダラダラ伸びるのは当たり前。受託向けじゃないってだけ。
まー
数年でフレームワークやOS自体変わっちゃうからな
ちょっと前まで.netでc#って言ってたのが、今じゃiphoneアプリでunityだもんさ
じゃあ、今unityの奴らが.netの昔のやつの保守やらされたらどーなんのっていう
多分メチャクチャな作法で改悪していく
そういうことだよな
データを安全に扱うための縛り、機能をシンプルな単位で分割
この辺りまでは積極的に使うけど、全部をデザパタに当てはめて設計とかまでしないな。
デザパタに忠実だと、スパゲティはある程度避けれて、既存のコードをほとんど触らずに機能変更や追加ができるコードになるけど、
ピタゴラススイッチになって保守が死ぬほど辛い。
競合他者との受注競争でギリギリの額で見積もるしかないのかも知れんが結局燃えてから増員して余計に効率が悪くなる
>>159
やっぱ
火付き案件とか言うように
どこかで火という言葉を使うんだなぁ
オブジェクト指向アプローチの最大の問題はデータをカプセリングさせようとすること
これで後で仕様が変ってそのデータが変ったら隠蔽された中をいじらなければいけなくなる
上位オブジェクトではgetter/setterで操作すれば良いのかもしれんが階層の下のオブジェクトの
プロパティも変えなきゃならないことが繰り返されると速攻でスパゲッティ化とデスマーチになる
オブジェクト指向厨はオブジェクト指向が原因だと絶対考えようとしないので
仕様をぐらつかせる顧客が悪い！営業が悪い！ちゃんとモデリングしない奴が悪い！
と人のせいにしてる
データはpublicでstaticで良いんだよw
>>202
ラッパー被せりゃいいだけじゃん
その発想すら浮かばないから構造化プログラマーはダメなんよね
名前のバッティング気にしてやらないんだろｗ
それに継承でデータガーとか、そもそもオブジェクト指向設計できてねーじゃんみたいな
手続き型でクラス階層化だけやってオブジェクト指向語ってる設計にあるあるのクソだよ
オブジェクト指向ってsetter/getterだけなんっすかね？
全然違う。この記事はレベルが低すぎる。
オブジェクト指向はおじさんたちの青春だからな
C++とかをお勉強して当時の新しいやり方でプログラミングして
古い人達と違うんだとバカにしてのしあがって来た数十年前の大切な思い出
現代になっていざ自分たちが逆の立場に立たされていることを雰囲気で感じ始めて
困惑し逆切れ発狂している
データと一言でいうが、そのデータがどのような状態にあることについての考えがまるでない
通常データは単一ではなく複数のまとまったある時は数珠繋ぎのようなある時はランダムなものであり
データの側から見たオブジェクト指向はそれを効率的に扱うのであればオブジェクトのようなものにいれてコレクションで管理したほうがいいんじゃないですかね？
といった一つの考えでしかない。
つまりmainのような箇所にデータの取り扱いを記述するよりも、データを格納するdataクラスにその記述を書いておけば再利用性高くね？
といった感じ。
継承とかは便利じゃないの？
継承しようと思ったけど肝心のデータがカプセル化されていて、結局似たようなクラスを再開発するパターンが多い
>>210
アランケイが創案したオブジェクト指向では継承はオブジェクト指向の要素とは認めてないからな
継承はC++作ったおっさんが勝手に導入した概念
C++的なアプローチはクラス分割して部品を独立させてと疎結合を頑張っちゃうけどその
その分断の補完として統一性を保つためにやむを得ず継承の再利用を取り入れたやり方
アランケイのオブジェクト指向はメッセージ指向で彼が言うには
「”全体より強度の弱いもの”に分割するのではなく、…つまり、そのセマンティクスは、
無数のコンピュータがすべて超高速ネットワークでつながっているようなものだ」
という非分割的なアプローチで１８０度考え方が違ったりする
以前はプログラマー３５歳定年説ってあったろ？
ところがなまじC++とJavaの時代が長かったので、
「いや俺は４０過ぎても現役だぜ」というおじさんプログラマがいっぱい登場してしまった。
クライアントがパソコンでサーバーは三階層の時代が長すぎたのがいけない
新しい言語や考え方を身に付けるには若くないと付いてゆけない筈
40代のおじさんがjuliaやGoをReactとか駆使してマイクロサービスやサーバーレス上で
がしがし新しいサービスを創出できていればその人は現役と言えるけどそんなの僅かやん
オブジェクト指向の考え方を振り回してC++やJavaで身に付けた古い考えを語って皆に迷惑を掛けてることに気付かない
35過ぎたら後進に道を譲ることをおじさんは考えるべき
継承と切っては切れないものにinterfaceがある。
interfaceの役割はそれを実装したものはinterface型の子供にする役割がある。これが重要。
たとえばclassAにclassA1のthisを渡すよりもclassA1にinterfaceＩを実装させてＩの子供としてclassA1をclassAに渡せば
classAはclassA1をinterfaceIとして認識してinterfaceIのメソッドにだけアクセスできてclassA1のpublicすべてにアクセスすることは許されない
まぁたいていのstaticオジサｿはinterfaceといえばオーバライドするものだ程度の認識しか持ち合わせてないのが現状ｗｗｗ
すべてをピーコーで満足してるｗｗstaticオジサｿに限らずmvpの解説をする企業のサイトまでthisを渡しちゃえ！みたいなことが書いてあって目も当てられないｗｗｗｗ
しかし、後輩の後輩の後輩の後輩ぐらいの製造（PG）に聞いたけど（20代前半）
今の話で、FIXされたソースの変更を無許可で改修し、
詳細設計所も製造が勝手に書き直してるって聞きました
誰も責任を取らない職場があるようですね
それがすべてとは思いませんが
現場にサブリーダすら居ないって・・・・・
大体、まぁ、オブジェクト指向ってのは方法論が腐るほどある
それこそ、星の数ほどある
マニュアルなんて存在しないし、存在できない
要は発想力が重要になってくる
日本人の苦手な分野なわけよ
１２年間ずっとパターン学習ばっかりやってくるからな
解法と教科書だけを暗記して繰り返すだけ
そういうマニュアル野郎だと、オブジェクト指向でデザインパターンを使って応用っつっても何もできないわけ
マニュアルが無いからなｗ
つまり全てそういうこと
結局の所、デスマの原因は
・クライアントが満足な報酬と期間を用意しない
・安易に安請け合いして、安易に安値で下請けに流す
・安易に受け取る下請けが膨大に存在する
・これらの存在が仕事単価の切り下げ圧力になり、さらにクライアントは調子扱いて金を払わなくなる
・金を払わないから当然工期も短縮されていく
このループで悪化の一途
どこの業界も同じ圧力が掛かる
日本全体どこ行っても同じ形でデフレしている
全てジャップが悪い
高レベル技術者、取り分け優秀なPMがいればデスマにならない。
デスマが発生するのは良いメンバーがいない時。
つまり、受注が順調な時だよ。
>>448
そもそも良いメンバーが集まらないのが問題だろｗ
その原因は低賃金と待遇が悪いからだ
見合ってない
国際的に見ても日本のIT技術者の賃金は1/3しかない
受注が順調なのではなくて、あまりにも待遇が悪すぎて人手不足なだけだ
日本中全てコレ
引用元
管理人からひと言
どっちみち炎上するさ
この記事へのコメントはありません。