「オブジェクト指向」は愚かな考え ->画像>7枚

■危険性

かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。

大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。

ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。

https://www.google.com/search?q=%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96%E3%81%AF%E6%84%9A%E3%81%8B%E3%81%AA%E8%80%83%E3%81%88

■ 実例

XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。

ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。

世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。内部でGPUへ送信したときに使用したGPUにアクセスする関数ポインタは公開されているのでGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。

しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。

さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。

カプセル化は恐ろしいね！！

■仕様変更
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。

staticおじさん

まじかよエドガーダイクストラ赦すまじ

JavaScriptの大流行でやっと認知されだしたよな。

union

C++とJavaの全盛期に言おうものならフルボッコだったが、
PythonとJavaScriptの流行でやっと認められた感じだな。

staticおじさんは元気かな

関数型ばかりになったな

排便メソッド

型付の関数型ってないの？

このスレ定期的に見るね！

信教の自由

プログラマ「gotoは死ね！」

オブジェクト指向がどうこうより、ソースいじれない構造がクソっていうだけだろ

>>12
scala

>>14
それな

フラットなPHP型が最高だよ

日本のIT技術者が育たなかった一つの理由に間違いない

friend 100個できるかな？

まあ確かに
サブルーチンでいいじゃん
僕はコボラー

オブジェクト指向は色々おかしいからな

関数型ってコボルの書き方そのものなのに驚くよね

じゃあ何指向がいいのよ？それ言えよ

プログラマー自体がおかしいからな
買おとか臭いとか

>>16
せやかてAPIやライブラリなど
到底全員が全体を理解できないものをいじってろくな結果になるとも思えないけど

じゃあサブジェクト思考で行くわ

unityも超高速化のために「オブジェクト指向を排したc#」という方向に突撃しだしたからな。

>>16
バイナリしか提供されない市販のライブラリとか絶望的だわな

ちょっとなに言ってるのかよくわからない

最近はコンポーネント指向ってのが流行ってるんだろ
知らんけど

そもそもオブジェクトって何だよ？

オブジェクト指向ってのが流行ってすぐ同じこと思ったわ
デバッグできないブラックボックスは使うべきじゃない

>>29
バーストコンパイラーとエンティティシステムな

インターフェースは全てを解決する
コードの手間は増大する

>>34
デバッグできないのはオブジェクト指向となんの関係もなくね

クラス内部の見えない状態変数で関数の挙動が変わるとか
デスマーチ必死だわなw

>>30
そんなんコストダウンのために利用するんだからデメリットがあって当然だよね
嫌なら自分で全部書けと

メンバ変数に依存してメンバ関数の挙動が変わるんだぜ？

>>37
正確にはそうだけど、代表的なオブジェクト指向言語にprivate属性がある以上大まかには正しい言説なんじゃないの？

>>16
それ。
継承しようと思ったらfinal classだったとか。

データベースもフラットな方向に進んでるからな

>>31
ニュースじゃねえ死ねということだ

privateが全ての悪の根源

ソースコードがないと死ぬ

いまさら

一切バグがなく美しいクラスしか存在しないならいいかもしれないけどな

>>39
そういうこっちゃ

作った一発目はいいんだけどね。
改変が始まると一気に苦しくなる。

>>46
ソースコードがあったって死ぬよ
厖大だし、他人の作った仕様書もないコードなんか読めん

車というクラスを定義したらトラックでもSUVでも作れるというやつだろ

仕様変更への耐性が激低なんだよ

今更何を…

AIでディープラーニングとか出てきて加速してる気がする
tensolflowとか中でどんなことやってんのか全くわからんけどKERASとパイソンでとりあえず動くからな
微分積分すら覚えてねぇが
ほんと雲の上でだれかがなんかやってる話だよな

一番の問題点は
犬小屋の設計開発方法で
高層ビルを建築しようとすること

>>15
longjmpにするわ

試行錯誤する用途には絶望的に向いていないからな

だからウェブはjs
AIではpythonが流行った

Androidがまだ出始めの頃、Androidの職業訓練でオブジェクト指向習ったぞ？

単に設計ミスの事例をオブジェクト指向のせいにするのもあれかな。
適材適所ってあるので。向き不向きがあるので、一律オブジェクト指向も愚かだし。
構造化プログラミングでもオブジェクト指向でも、関数型でも何でもいいので、
きちんと目的にあった言語を選んで、正しく設計された保守しやすいコード書いてくれれば。

といってもそれが難しいんだけどね。

>>56
良いこと言うね

直接見せたくない/触らせたくないから隠蔽しているのであって

見たいなら理由込みでAPI追加してくれってのが筋だと思うがなぁ

>>41
スコープの話とオブジェクト指向は話違うと思うよ

そうとも言えないが、万能からは程遠い

>>61
設計ミスではない
仕様変更に弱い

カプセル化が駄目って書いてあるだけじゃん
まあレベルの高いプログラマ揃えられるんなら規約で縛るだけで足りるんじゃない？

10　i=i+1
20　GOTO 10

アジャイルみたいなアホな開発やるならオブジェクト指向取り込んだら終わるよな

結構前から言われてたよな。
でも、ずっとそれでやってきてるから今更変われねぇわ。
若い世代の奴ら頼むわ。

>>16
ならpublicにすればいいだけじゃんジャン

>>15
Linuxのカーネルではめちゃくちゃ使われてる件

>>69
何で言語の特性の話しに開発手法の話しがでるの？

カプセル化されたクラスを
リフレクションで丸裸にしてしまう背徳感

自社製品の開発ならそれなりに意味はあるんじゃね？
インデントでやるのはアホだと思う

答えはひとつで｢馬鹿にやらせるな｣

>>70
オブジェクトの設計資料とソースがちゃんと残ってりゃ問題にならないんだよ
アジャイルとか騒いで必要な資料も残さない、何処かからバイナリ借りてきても記録を残さないから訳ワカメになるんだよ

>>73
手法に基づくからだよ
資料残せよ、ソース残せよ
馬鹿なの？

結論

臨機応変

Cからやると、Javaの記述の長さとクラスに耐えられなくて気持ち悪い

>>6
そういう世界線もあるのか

>>77
アジャイルさせられたよ。
最初に期限決めます。要件定義は口頭とメモ、基本設計さえなくせって言い出す始末で品質悪いってキレられてプロジェクト抜けたわ。

デスマとは直接的関係なくね？w

>>82
設計図なしでタワーマンション建築するくらい無謀だなｗ

>>82
正解

日本はなんでもプロプライエタリにこだわって全部潰したよな
オーブンソースになっていたら世界を席巻できていたようなプロジェクトは腐るほどあったろうに

猫を作ると野良猫からライオンまで作れるとか言うのだっけ

そしてセッタとゲッタをたくさん作りました

確かに画像解析ＡＩのソースコード見たらJavaスクだったりしたのを見たらな

>>82
「仕様書どこですか？」ではなく「ソースのどの辺ですか？」って聞ける奴向けの開発手法
本来適当にかき集めた連中で立ち上げるようなものじゃない

>>86
支那やら韓国から来た連中がソース盗みまくったからオープンソースみたい物だろwww

>>82
アジャイルって内製が大前提だから
日本のはアジャイルじゃないよ

>>51
巨大なクラスライブラリのソースと階層構造理解しないとどこをいじればいいかわからんてのはいやん

>>92
派遣入場してれば業務上は正社員と同じだから（法的には）…
↑日本たけで通じる言い訳wwww

>>82
悪いアジャイルだなぁ。
そんなのもう10年前ぐらいに廃れた悪いやり口で、今どき聞かないってのに、
変なのに引っかかったね。

アジャイル憲章にもちゃんと書いてるよ。
完璧なドキュメントは作らず、動くソフトウェアに注力します。
ただしドキュメントは大事ってのは当然ですよ。
って。

>>2
それはＯＯＰの問題ではなく
単にModelクラスへの不満でしょｗ

自分で作って下さいオブジェクト
私は逆にドットを入力したときに
ずらーっと候補表示出る方が
ウンザリするんですが

リバース・エンジニアリング(`･ω･´)ｷﾘｯ

仕様書作ってないことを横文字で誤魔化すな

オブジェクト指向は再利用が可能というけど再利用なんてしたことがない

上から下まで1人で作れりゃ問題ないがんなことできん。そんでライブラリの問題でコケるのもままありカプセルヘイト

>>94
研修社員と派遣とフリーと下請け出向が入り乱れる現場でアジャイルとか無謀にもほどがあるよな

>>98
わかる
再利用なんかしたことない

どっかの神が作成したかしらないライブラリを手探りで使ったことはあるけど

カプセル化をunpackする機能があればいいんじゃね（暴論

デザインセンスに落差が大きすぎて、多人数開発でとんでもない事になるのが実情ってやつだな

＞頭文字にアンダースコアを付けるなどの命名規則
どういう事？

>>1
そんなこと考えたことなかったわ

アイドルが排泄メソッドを実装できるのは云々のスレじゃないのか

golangは継承もないしな

新型コロナ蔓延のいま、時代はGOTOプログラミングか

オブジェクト指向でなぜつくるのか

を読んでもなぜなのかさっぱり理解できなかったわ

>>15
jumpは基本なんだけどな本当は

>>97
> リバース・エンジニアリング
逆アセンブラがあった時代からある言葉だが

食べてる絵をくださいって言われて仕事だから言われたとおりやってるだけやで
素人のデブが欲求のまま食ってるのとそりゃあ違って当たり前だろ

再利用ゆうても単一メソッドな訳もなし、いらないもん抱き合わせされるならいらない。
コピペはするけどな。
再利用して元のが更新かかって動かなくなるとザラ。
自分で追加した部分が元のにも追加されて、せっかくだから元のを使おう、で意味のない作り直し。で、バグ。
きれいに出せてたエラーメッセージも英文になっちゃう始末。

プログラムなんかコンパイルすればGOTOだらけなんだよ

オブジェクト指向を推し進めるのは要はデータを管理しやすい為、この一点でしょ…

IT土方離れて久しいけどオブジェクト指向とかまだ言ってるの？

>>21
草

>>116
コーダーなんて職業はすべてAIに取って代わってロボットが人類を滅ぼしたときいたが

>>68
BASIC？なら変数に$要るんじゃない？

>>118
正解を導き出せる完璧な仕様書が必要になってしまうわｗ

俺みたいなクソザコすぎてIT業界で箸にも棒にも掛からなかったような雑魚でも
ちょっとAndroidのアプリでも作ってみようって思ったら
書けるのはオブジェクト指向の恩恵なんだろ
ウィンドウのクラスとかボタンのクラスとかそういうのがいっぱい働いてるらしい

おっさんだけど
オブジェクト指向が悪いんじゃ無くて、イベントドリブンが出来るようになってプログラマーは頭使わなくなった
昔は、プリントアウトするか、トラップ使ってバグ探ししてた
コンパイルも８時間とか掛かったから、漏れが無いか、間違いが無いかって命ガケだったよ
便利は人をアホにするんだ

なんかやたらとソースが簡素に書けるとか自動的に生成してくれるようなやつって
ちょっとイレギュラーなことやろうとするとアホみたいに面倒くさくなる

全部 publicにしてアンスコの数で外部向けなのか内部想定なのかを整理する派

動けばいいんだよ、動けば vs 綺麗なソースコードで動くプログラムは美しい

勘違いした輩が収集つかなくなってスパゲティにしなければ、オブジェクト指向なんてしなくても良いんだよ

構造化すら知らない、やらないで、クラス書いてればOOPと思っているアホが沢山いるか、隠蔽したくなるんだよ

>>125
俺はもう動けば良い派だな
複数の人が介在するプロジェクトでは最初の思想なんて時間と共にぶち壊されていく
綺麗にシステムを作れるより汚物コードを読み解くスキルの方が必要だって気付いたわ

開発現場の8割の偏差値は50台なので
もっと簡単に、多少無茶をしても動くようにできるやつを
偏差値７０や８０の人達が頑張って考えればいいと思うヨｗ
（ま、それがフレームワークって奴なんだろうけどね）

>>100
正社員が資料作り出すと派遣のリーダ様が正社員をハブり出して、結局資料が無い物が出来上がるとかなwww
派遣のリーダー様が残らないと何も判らないwwwwww

こんなの誰が望むんだよw

選択肢が多いほどいいってだけの話
オブジェクトの再利用によって、現実問題、生産性が著しく向上しているわけで
今の最新のゲームを、一から作り直したら、開発費用は100倍を超えるぞｗｗｗ

カプセルに内包された致命的な問題があるなら、そのコードを修正すればいいだけの話
別の会社が開発していて、ソースコードをいじれないなら、その会社に通知して直してもらえ

>>120
昔のCOBOLの詳細設計書みたいに
一言一句プログラムに落とせるような物を書けって話なのかな？wwww

流石に、あのCOBOLの詳細設計書は無駄だぞw

別実装からあらゆるデータにアクセスできるようにせよと言うなら、いくらたってもそのモジュールは完成しないわw

極論を振りかざす前に線引きを語れよw

変数確認してから関数呼べばいいだけじゃないの？

>>6
今ってJavaScriptが一番人気なの？

>>130
ゲームと言えば20年くらい前から世界を圧巻した韓国製MMOの元プログラムも日本から盗んだクラサバシステムのソース群だったなあwww
どこの企業のが盗まれたんだっけwww

クライアント側がwebシステムに移行しまくってる最中で盗まれた企業も騒がなかったんだよな、確かw

>>134
web実装が多いと言う話。
nodeでも使うけどさほどメジャーではないし。
たとデジタル放送でも使われてる。

カプセル化による隠蔽っていうか、「○○を意識しないで△△をすることが可能です」みたいなのは、サンプル以上のことをすると大概ハマる。
デバッガで動きを見れば、動かない原因がわかることも多々あるんだけどね。
デザインパターンを意識してスタックトレースが積み上がり過ぎてるやつとか、リフレクションですっ飛んでるやつとかも原因が探しにくくてハマる。
オブジェクト指向じゃないけど設定より規約みたいなのもハマるな。

>>116
俺も90年前半にバイトでCプログラマーをやってた
MS-DOS環境のC言語しか知らない
あとBASICとCOBOL

>>136
なるほど

クローズドソースで内部データを追えないこととごっちゃにしてる奴がいるなw

>>138
実はCOBOLって今でも仕事沢山あるぞw
基本的に若い奴居ないらしいので、年齢は気にしなくて良いし
金回りのシステムなので、単価も悪くないって聞いた

>>119
文字列ならじゃね

>>119
いらない

JavaScriptでプログラムを作っていたところだがthisだらけで見にくい
何か間違っている気がするが直しようもない

>>135
ソースコードの著作権保護って線引き難しいみたいだしね〜
アルゴリズムは著作権保護されないっていうのもあるし
まぁ流石に丸パクリしたら、アウトだろうけど

同じような処理2回も3回も記述してるアホコードよりマシ
分岐すりゃ済むだろ改修漏れるだろボケナスと思うから

カプセル化は疎結合の手段に過ぎない。
手段と目的を取り違えて地獄に落ちてるだけだろ。

>>140
＞クローズドソースで内部データを追えないこととごっちゃにしてる奴がいるなw
そういう話じゃないの？
オープンソースでオブジェクト指向なら、何も問題ないと思うんだが

>>141
一人月単価60万以下程度でいいなら、いいんじゃない？ｗ

カプセル化自体は悪くなくね？
必要になったらprivateからpublicにすればいいんじゃないの

>>127
そもそも途中から入ったメンバーには、最初の思想が何だったかなんて
コードの残骸から読み解くくらいでしかわからないし、分かったところでもはや意味をなさないものになってるしな

周りがもう動けば良いでしか作業してないから
スパゲッティになってなければマシな方

>>125
引数にパスを直書きとか増えるのだけは許せんわ。データ入力業務でもしてるのかと思うようなプログラム改修させられる。

あんま覚えてないが
別のところに集約して大まかな条件を動かして
それを呼び出すとかそんなだっけ
あれ？これはクラスか？

いたずらに複雑化し、結果、メンテナンスも相応のレベルのものでないと出来ない。

オブジェクト指向である必要のないプログラムは山程あるが、必要なプログラムはそう多くないのが現状。

書き直せばええだけやん
アホなの？

>>145
クライアント側にグラボメーカの支援が入り込んで画面表示部分は別物だったからねぇw
肝腎要のクラサバの通信部分とサーバサイドが丸パクリだったみたいだね

>>149
1度引退したCOBOL屋さん向けだしねw

ITどかたん　がんばれぃ〜

>>155
書き直すのに必要な資料が残って無いから…www

>>5
マジレスするがそれ構造化プログラミングな

てか最近のとにかくフレームワークって風潮なんなの

コード規約とかもっとちゃんとしたほうがええんじゃないの？って話をしたら
テキストエディターは何を使うことにするか決めるところから会議始めててワロタ

>>1
カプセル作る奴がバカだから成立しないってだけ
つまりIT後進国の日本には無理ってだけ

>>161
EJBなんて判るPGがいないからw

あとからいじる奴が偉そうにって思うんだが

>>41
別にprivateだからデバッグできないとかないけど

20年ほど前にVB6で仕事してたときに
Javaプログラマーにオブジェクト指向が使えないと奴はバカとぼろくそに言われたわｗ

設計の時は頑張って考えるけど結局改修で邪魔になるってのはあるあるだけど
だから要らないって話でもないよね

>>15
後藤さんに謝れ！

教科書こそ全て
教科書こそ真実
教科書に間違いはない
なんて主張してる人をディスってんのかw

闘うプロゴルファー

データーレコードに関数もセットするという位しかしらんな

世間ではgotoが流行っているが
プログラムの世界じゃ、随分前から大流行よ

>>5
ダイクストラはいいんだが、その原理主義信者どもがjavaから積極的にgotoを
排除してヘドが出る
あいつらプロパティさえ実装できないし

カプセル化の問題なのか？
仕様の問題じゃね？

>>72
>>110
gotoキャンペーンとかけてギャグにしてるクライアントの意図を汲み取れてない
たとえ技術は優秀でも手戻りが多いタイプ

リフレクションとか使えばprivateくらい外せるだろ。まぁ仕事ではやらんけど

>>169
コロナ広めんなや

初級者「オブジェクト指向は糞」
中級者「オブジェクト指向面白い」
上級者「オブジェクト指向は糞。C++使うぐらいならCでいい」

プログラム関係のスレはいつもコメントが攻撃的。
プログラマは心が荒みすぎてる

もう全部publicでいいんじゃないかな

最近多いんだよね、JAVAとかちょっとかじった程度で「俺プログラマーやってます」って顔する子
最初の入り口がオブジェクト指向なんだよね、最近の子って
そんなんじゃ使い物にならねぇっての

>>182
JAVAとかちょっとかじってるだけマシでは？
職業訓練校でHTML習っただけでの元板前とか拾ってきてプログラマーやってますって顔させてる会社とかたくさんあるけど

ヌルポインタ

やろうよ、自分の仕事なんだからさ

>>182
Cかじった程度でもだめですか？
別にプログラマなんてやりたくないけど

ム板で相手にされなくてν速にスレ立てるとか最悪

結局これ、クローズドソフトではいつまで経ってもバグだらけでまともなソフトにならんよ
って話だろ

>>2
そりゃ最初にmodelクラスの改変（もしくはバージョンアップ）をやらずに

最悪のスパゲティ手法で回避した駄賃三文以下のプログラマとそれを踏襲した全関係者が悪いわな

スパゲティ・コーディングは明日世界が滅びるという確たる保証がある時に
その前日にのみコーディングが許される唯一の手法であることを
全プログラマは再度、自らの肝に銘じなければならないわな

>>29
それってASCI C 89となんか違うの？

デザインパターンってのを理解しなきゃいかんのだろ？

創価学会の嫌がらせ行為の黒幕は、信濃町総本部の学会幹部です
http://2chb.net/r/ms/1603716395/1-14
＞1 ：テンプレ ◆Rr.V4pIjXE []：2020/10/26(月) 21:46:35.81 ID:0FjuccQi0
＞創価学会の地方組織は
＞
＞方面――総県――圏（地域によってはなし）――本部――支部――地区――ブロック
＞
＞となっています
＞ちなみに全国は１４の方面に分かれており
＞（中略）
＞となっています
＞創価学会が特定個人の嫌がらせ行為を働くときには
＞
＞信濃町の総本部の幹部　→　方面幹部　→　総県幹部
＞
＞という形で、特定個人に嫌がらせをしろと、総本部の幹部が指示が下りる事で行われます
＞
＞つまり嫌がらせ行為を行わせている黒幕は、信濃町にある総本部の幹部だという事です
＞文字通り、創価学会による組織的な嫌がらせ行為というのが実態です

２０１５年１月頃、創価学会の嫌がらせ被害者が民事裁判を起こし、騒ぎになりました。
被害者は勧誘を断っただけで嫌がらせを受けるようになった非会員の一般人でした。
政治家でもなければ、ジャーナリストでもない、敵対教団の関係者ですらない。
ごく普通の方です。

そんな人に対する嫌がらせでさえ、信濃町の総本部からの指示により、行われているのです。

つまり創価学会という団体の実態は、組織犯罪集団である、という事なのです。

詳しくお知りになりたい方は上記のスレッドのリンク先を参照してください。

※この情報は下記レスの続きです
創価学会の嫌がらせの手口について、１０年以上前に、現役会員が手口を暴露した事実がある事をご存知だろうか
http://2chb.net/r/newsplus/1603363901/696
i17

未だにCがド低番の組み込みにはどうでもいい話ですわ

>>159
カプセル化されてなくたって、機能追加しようと思えば結局書き直すことは変わらないじゃん

>>182
このホリエモンモドキの台詞も使えない状況なんだよな〜ww
java齧ってたら凄いって時代を作者は予見しようが無いもんなw

>>184
ガッ

今Unityでゲーム作っててめんどくさいからpublicしまくってるけど俺しぬの？

>>194
何処をどう直すのか、どうやって調べるんだよwwww

まー、結局さ
継承がどういう物で実際にどういう動作をしているのか理解してない文系プログラマーや
WEB系やオフィス系や専門や独学でなんとかなってる奴らが使うと、
バグ生産装置になるってだけ
コーディング量減らせるし、バグも減らせる
下手に使うと依存性だけが増える

要は使い方次第だが、バカにはどう使うべきか判断できないのが問題だ
どうしょうもなくなってから、間違いに気づく

>>182
javaならいいじゃねーかw
pythonをちょっとやるくらいの俺よりいい

つまりos作れないとダメってことか

>>2
アホな仕様なんだな

>>2
＞ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセス

それ、オブジェクト指向の問題じゃなく設計の問題だろ
そういう仕様にした奴に文句を言うべし

他人のソースでオーバーライド使いまくりなソースは読めない
気が狂いそうになるわ

構造化プログラムの時代がきたな！

>>199
確かに・・・
それが現実だな・・・

>>204
ソースだけならな
ちゃんと設計書ある前提の話だが

>>205
C言語で構造体と関数ポインタと翻訳単位を駆使すれば
同じように出来るしな(継承はさすがに無理だが)

>>208
C++のクラス継承を便利な関数として使えよ
ポインタ地獄はソースや設計書が残ってても読み解くの面倒だそ

>>199
世の中、お前みたいな天才だけならいいんだけどね。

例えばさ、IO処理なんか継承なしじゃあ話にならん訳よ
継承無しで個別のコードを書いてたら、HDDでは正常動作するけどSSDにすると駄目になるとかになるわけ
それぞれコードがバージョン違いで食い違ってたとかになる
だったらIOを継承させればそうはならない訳

要は使い所の問題
バカにはそれが判らんのです

モデル云々はオブジェクト指向っつーかモジュール内のスコープの話じゃね

バカの継承の使い方は、本当にバカ
頭の程度が一番出るのが、継承の使い方

バカはHTMLを処理させるのにメモ帳を継承させたり、WEBソケット処理させるのに
ブラウザをまるごと継承させたりする
だからバグが無くならない
全体を見通せてない

頂点データが隠蔽されているなら、少なくとも当時「公開しなくともよい」という判断がされたわけで
その判断の理由が当時妥当だったか、今でも妥当かが論点であって、カプセル化による隠蔽が愚かとはならんだろ

そもそもアプリケーションフレームワークってのは、余計なことが出来ないように作る面もあるしな

あるプログラムの仕様が機能Aと機能Bで構成されているとして、
C++の実装が
クラスA(機能Aの実装80%と機能Bの実装20%)
クラスB(機能Bの実装20%と機能Bの実装80%)
Cの実装が
サブフォルダAにAの機能のソースが100%格納されている
サブフォルダBにBの機能のソースが100%格納されている
どっちが分かりやすく、カスタマイズもやり易いかは明白
作り手がクソならどんな言語使おうがクソが出来上がる

＞アラン・ケイが関わったオブジェクト指向プログラミング言語には
＞どれも「private」などという概念はない。

privateだろうが、publicだろうが
オープンソースなら関係ねぇだろ

その時々で最適な選択をせよ

JavaScriptプロトタイプ最強伝説

>>213
んまあ、いいたいことはわかるし、YOUは優秀なんだろうけど、

コードレビューでイキリコメントをつけて相手のモチベーションを破壊したりするのはやめておくれよなｗｗ

ちょっと知ってる人ほどイキリレビューして貴重な戦力を潰したりするからホント迷惑。。（パワハラで裁判なりかけたのもあるし

他人が触れたジグソーパズル組み立てるとか考えたくもない

文句があるなら自分で作れ
どうしてもというなら開発費出して頂点データのgetterを作ってもらえ
なんでもタダだと思うなっつうことや

さっぱりわからんが、HTMLでも「どこに書いたっけ」ってなってた俺は死ぬタイプなんだろうな

>>8
JavaScriptでオブジェクト指向やろうとしたら、死にそうになるからな

>>216
??

>>219
コードレビューでパワハラなんて起きるのかw
基本設計書のレビューで文系上司が「テニヲハガー」「句読点ガー」「日本語ガー」連呼で優秀な奴がバタバタ止めるプロジェクトなら良くあるがwww

ソースがない上に、記事の主題もオブジェクト指向ではなくカプセル化

>>225
基本設計書は人間用なんだから、誤解を招く記述してる方がアホだろ。
それよりすぐ文系理系で一括りにする奴は、一生うぁつのあがらないコーダーやってろ。

>>213
UMLを書いて、継承する属性とメソッドがそのオブジェクトにふさわしいか検討すべきなんだろうね
とりあえず動くし、大は小を兼ねるみたいに継承してると複雑怪奇なクラス関係が出来上がる

>>227
文系上司からシステムに関する指摘が一切無いのも特徴だよなw
つか、お前その口かよww
「テニヲハ」「句読点」がどうであろうと設計書の意味を成してるからなw
（日本語ガーはテニヲハと句読点を合わせての締めの挨拶だぞww）

外部変数てんこ盛りﾋｬｯﾊｰｰｰｰ

何がなんだかわからんが動いているからヨシ！！

>>231
ご安全に！引継ぎも手抜きヨシ！

まあ実際色々なプロジェクト触ってると、
隠蔽のメリットよりデメリットの方が多いな
設計が適切とは限ら無いし

同じ入力なら必ず同じ出力してくれる方がテストしやすいしな

宗教戦争スレ

出来次第だからなんとも…
オブジェクト指向そのものは机上の空論で、それを綺麗に実現するには練度とセンスが必要不可欠
上手い人が書いたOOPコードなら参考になるし使いやすいけど、素人の拙いOOPコードは理想と現実の乖離が酷いって印象
要は見た目以上にハードルが高い

>>203
特に意味はなくてもREADONLYプロパティで公開しとくよなぁそれともテンプレートがいけてないのか？

アクセサがないパブリックなオブジェクトってジジババがDtoって呼んでるやつだろ
AOPしてるプログラムでオブジェクトの可視性変えたら効率上がってやべえ気がするのでうちのプロジェクトでもやってみようぜ(๑˃̵ᴗ˂̵)

カプセル怪獣ウインダムしか思い浮かばん

OS/2・・・

継承なんてオブジェクト指向において全然重要な部分じゃないのに継承が話題になってしまうあたり、オブジェクト指向批判をする人の多くはオブジェクト指向を誤解しているんじゃないかと思われる Javaあたりで手続き指向の発想から抜けられなかったというか

>>1
大体的が気になって入ってこない....

どうして開発元にお金出して仕様変更してもらうという、
人として当たり前のことをせずにキレてるのかという疑問はある

>>1
そんな事文章のどこに書いてあんだよ
カプセル化はやめろと言ってるだけでオブジェクト指向は関係ない
カプセル化はオブジェクト指向を理解しないガイジが
勝手にメリットとして見出した概念

>>243
開発元って会社なの？人なの？
会社だと思って金を払おうとしても「仕様を知ってる人」が遥か昔に退社してて行方不明なんてザラだぞ？

古すぎて開発当時の資料どころかSEまでこの世に残っていなさそうなメインフレーム時代の遺産から
COBOLのソースやコピー句を掘り返して仕様をリバースエンジニアリングする作業も不毛っちゃ不毛。

>>246
それは便利なツール使っても全ては解決しないもんなw
でもソース残ってりゃ読める奴は居るぞw

>>127
汚物コードをなるべく読みたくないからこそキレイに（美しくというよりかはわかりやすく平明に）書きたいしみんなにも書いて欲しい派だな

>>248
ソースコードなんか癖があって当たり前だらどうでも良い、何よりも仕様書なり設計書なり設計メモをしっかり残せよ

はて?前にも同じ記事みたような・・

システム更新の際に言語やDBみたいな開発プラットフォーム自体が全然別物なのに
「とにかく現行仕様を踏襲すること」だけを求められるのはよくある話
メインフレーム端末のエミュ（黒背景に緑の文字）でお茶を濁すのも常套手段だったけど今は知らん
こんなの誰が得するんだ？と思いながら数年前までその手の案件にも関わってたけど
お役所相手の仕事だから仕方ないってことで自分を納得させてた

言語とIDEをセットで語る時代だよね
オブジェクトを効率的に扱えれば問題ないよね
ところでそんな素敵なツールは存在するのかな

>>245
日米ともに人を大事にしないのかね
アップル子会社の缶詰ブラックの噂も聞いてる
それでも統計的には賃上げなので、日本ほどじゃないだろうけど


なぜ行方不明なのか
地位を保証しないと、後輩に伝授することもできない
あるいは、誰でも引き継げるようにサービス旺盛に整える余裕もない

>>228
UMLは確かに一定の効果あるけど、完璧じゃないね

バージョン違いと仕様変更に弱い
結局、この辺は経験になってくる
業界の動向や物理限界や最新機器の状況、最新OSや最新技術の開発動向なんかが影響してくる
深い洞察と慎重さが不可欠
いくつものプランが必要で、さながら軍事的なインテリジェンス
そこまでやってる企業は皆無だろう
最新の製品に対応した、古い設備を買い換えろ、位しかやってないからな

>>223
TypeScript「そやろか？

ぼくの肛門もカプセル化されそうでつ

>>189
いい事言ってるなー
あいつら放っておくと自らの無能を棚に上げてスケジュールや予算のせいにしてスパゲッティ肯定しやがるからなぁ
新規開発だけでなく運用においても例えばもう1日与えてでもスパゲッティを回避し続けなければならない
一度でも許容すると増殖し破綻するのは時間の問題
だから本当にオブジェクト指向の問題なのか無能のせいなのか議論の余地はある
やはりそれなりの知的水準を備えていなければITに関わらせてはいけない

おおよその物理限界を理解するのだって文系には無理な仕事なのに
ITゼネコンで飛ばしSEを量産するために動員されたそういうわかってない系が
なんちゃってオブジェクト指向プログラミングなんてすると大変なことになる

恐ろしくレベルの低い物なら一応成功するが、ちょっと複雑になるともうダメ
鳥の羽集めて太陽に飛ぶ感じのプログラム始める

>>257
どうせ破綻するときは自分が担当のときじゃねえから
知ったこっちゃねえやｗｗｗ

>>249
論理性や合理性の世界で癖とか許容してんなよ
突き詰めれば一つに集約される

また、うんこの継承の話か

バベルの塔なんか作ろうとしたって完成しないのは当たり前だろ
プログラムはコンパクトが正義
後から改変したいなら尚更そう

>>248
綺麗に書くじゃねーんだよ
一字一句全てのコードになぜそう書くのか説明ができれば自ずと美しいものが出来上がる
つまり綺麗に書くは結果だ

>>189
早く帰ってゲームしたいやん

またこのスレか
銀の弾丸なんて無いと何度言ったらわかるんだ？

>>259
皆さん、オブジェクト指向が無関係な事ご覧いただけたであろう

>>266
そうだよ、結局、派遣だらけのゼネコン体質なのが根本的な原因だよ

まあ当たり前だが、作り手側がこんなとこに出入りする余裕はないわなｗ
今頃必死にやってるか、ぐったりしてる
おそらく辞めるような使い方をしたいがゆえに、引き継ぎやすい作りにしろという、身勝手な勢力

すべてのプログラムをアルファベットで表現しようとするから
天才以外脳がおいつかんのよ

階層化はグラフィカルで知覚できるようにせんと

そもそもオブジェクト指向プログラミングってのは、プログラミングが上手くなれば
自然とオブジェクト指向プログラミングになるんだよ
プログラミングが上手くなれなかった挫折したやつが、OOP批判を始める
結局、モノにならなかった嫉妬だろう

それを有名人が言うとコミュニティが崩壊するからあえて言ってないだけ

JavaだろうとC#だろうとオブジェクト指向を無視して面倒なことをいろいろやってくれるConvenienceという静的に使えるデカクラスつくるほうがよっぽど便利

＞ソースコードがあってもライセンス的に改修できない場合や、

金払えば済む話ｗ

＞そもそもバイナリのライブラリしかない場合などは絶望的である。

自社でできないレベルのものだから他社が作ったものに頼ってるわけでしょ？
作り手が下手くそって話ではなく、作り手の方がレベルが高く、文句言ってる方がレベル低い状況

議事録や仕様書変わりにredmineのチケットしかありませんとか…
それも決定の経緯もろくに描かれておらず何だこれみたいなのあるよね

例えばさ
勤怠管理まで一括管理するセキュリティシステムがあるとするじゃない
んで指紋認証でログインするんだけど、ブラウザがIEだけ

で、今回上がYou Tube見れないからchromeに変えてよとか言い出すわけ
ところが、指紋認証システム部分を開発した下請けメーカーが数年前に倒産してる訳よ
ソースもサポートすらない
じゃあ丸ごと入れ替えるって予算もない
だからvmでIEを起動させて特殊な認証処理を通過してみたいな話になってくる

金じゃ解決できない
完全にデッドロックするわけよ

設計書じゃなくて、ソースだせソースを

>>274
ChromeからWindows Hello使えるみたいよ

外部設計するのにソースみないと進められないような糞の仕組みあるよね

>>274
＞ところが、指紋認証システム部分を開発した下請けメーカーが数年前に倒産してる訳よ
＞金じゃ解決できない

倒産がありがちとすれば（実際ありがちなんだろうけど）
金の問題だよねｗ
もちろん一社の金で解決できないよ
社会問題レベル

>>274
それ契約に関する問題でしかなくね？
そうなるリスクを避けたいならソースも納品してもらえば良かっただけだと思うのだが

>>276
コンポーネントがIE6縛りで、それ以上だと動作しない

割とよくある感じのクソみたいなシステム
10年くらい前にクソほど量産された
流石につべ見るために全改修300億円は経理が許さない状況
システム自体はなんの問題もなく動いてる状況

>>280
IE6だとwindowsもXPとかじゃないの
つべどころの話では無いような

ソースと仕様書とコメントの三重管理

>>260
お前がそう思う中で集約された物がお前の表現する癖だから…
理解出来ないのは修行不足だよ
ハンドアセンブルやってた時代から、同じ事を実現するプログラムが複数種類書け、それが癖だったりテクニックだったりと語られてた事くらい学ぼうよ

>>280
そんなもんをこのご時世に存続させていることが罪
報いを受ければいい

>>253
人を大切にするって金の問題だけじゃ無いからね…
システム開発、システム設計の世界がどう頑張っても数千年の歴史ある建築業のように洗練化された手法が生まれてこない以上は属人的な世界が必要以上に纏わりつくんで…

>>6
JavaScriptはそもそもの設計がうんち

まー、これがオープン規格でソースも公開されてれば移植って話になるけど
独自仕様で特定のバイナリモジュールを特定のOSや特定のバージョンのソフトに
インストールしないと駄目みたいな話になるとクソ面倒

カプセル化公害も同じような問題
規格化されてない仕様はデスマの原因

>>274
保守管理に掛ける費用をケチった結果、にっちもさっちも行かずデッドロックなんてどこでもある話だわな
無理なら無理です、としか言いようがない。当時の、そして今の責任者の疵瑕や

>>274
何年前だか知らないがIEオンリーとか発注側もアホだよね
そういうの結構多いの知ってるけどさ

>>284
役所や工場だと普通にあるぞ
MSDOSやPC98も拝める
もちろん、クローズドなネットで運用されてるのがほとんどだが

>>289
IE6は企業が使うブラウザのデファクトスタンダードみたいなもんだったからね

結局、依存性の高いシステムってのは、負債な訳よ
いつか高いツケを払う時が来る
それが10年後か、100年後かはワカラン
100年後ならギャンブルに成功
借金は踏み倒した

オブジェクト指向がベストかどうかより、オブジェクト指向ごときを理解できてないのはヤバいだろ

>>289
・PC端末を買ったら最初からインストール済な物だけを利用する
・余計なセットアップ作業をPC端末には行わない
・壊れたらその時に買えるPC端末をそのまま使用する

素晴らしい要件じゃないか

googleは各企業に手間暇を増やさせ不要なコストを増大させた諸悪の根源だろ？
このありふれた要件を崩された各企業はgoogleに対して損害賠償請求しても良いんじゃないかな？

edgeがchromeベースになった時点で訴訟し難くなったんだけどねw
googleは随分とMSに金毟られたんだろうなwww

工期が半分過ぎた頃に、要求を倍に増やしてくる企業が多い
なんかのハウツー本にでもあるのかなってぐらい

体力のある企業はそんなふざけた顧客からは撤退するが、
前半の労力が只働きになるので、体力のない企業はなんとか納品しようとする
そういう、下請けを倒産させるような使い方が横行してる

またこの話か
前回は古いドライバの改造でマニュアルもないしオブジェクト指向でめっちゃ苦労したって話だったっけ

>>283
ではその同じものの中でなぜそれを選択したんだ？
それを癖という抽象的な理由にしてはいけない

この業界って見えないコストが多いんだよな
トレーニングコストとか、ソースの整理だとか
そういうのに顧客は一切金を払わない 理解もしない
一番安い業者を常に探して、一番依存性が高いシステムを選択して
数年後に一番高い代償を払う
そんなのが横行している

20年ぶりにエクセルマクロ作ったんだけどエクセルVBAもオブジェクト指向になっててビビッた
もっと気楽に作らせてくれや

綺麗に書ける人は、頭がいいゆえ、汚物コードも読める

最近は構造化すらできないデタラメなやつ多すぎ

構造体を直接叩きたがるバカを防ぐためにプライベート変数はあったほうがいいけど
JSみたいに隠匿できない言語もあるので
結局命名規則で絶対に触ってはいけない感を演出するのが最適解

>>114
アセンブラに落とせばそうなるのは当たり前だが、そう言うことではない

このスレ定期的に見るね！

>>270
熟達者でないと分かり難い、という批判は、嫉妬ではないだろ。

>>298
詰まり、見えないコストを見える化するのも営業努力であり、サービス提供の一環ということか。

>>297
無自覚な選択を癖と呼んで済ます。明確な理由を言語化して考えていないという。

>>295
擦り合わせが足りない。或いは作りながら要求が明確化されるから。

オブジェクト指向が嫌なら、手続きベースで構造体に値を出し入れしながらコピペで処理を書くことになるがよろしいか？
よろしいも何も今書いてるプログラムがそうなってますかそうですかお疲れ様ですありがとう_(┐「ε:)_

20年前、デザインパターンが考え出された時、これこそが銀の弾丸だと思ったな
今にして思えば、AbstractFactory？どこの中二病ですか？って思うわ

>>306
まー、金のあるところはそれで理解すると思うよ
金融系とかね

問題は、製造とか役所とか小売店とかだな
コスト意識が強かったり、予算が下りないなどの理由で、標準化された技術を採用しないケースが多い
ここで多少のコストをかけておけば、将来の改修が何倍も楽になると言っても目先しか考えない
一度痛い目を見ないと駄目なんだろうなと思う
あるいは、経営の根本的な改革 例えば税制優遇や補助金なんかが必要

高度なプログラムは高度なプログラマしかメンテできないから
保守性が高いとは言えない

コメントは大事だが、コード内に残された９割の修正履歴は
屁の役にも立たない邪魔なものなので、廃除した方がコードは読みやすくなる

ぬるぽ

低レベルなプログラムというのは、完成度が低い
それ自体がバグの温床
メンテ性が多少良くてもデメリットも多い
ケースバイケースだが

高度なプログラムに勝るものはない
必要なコストと言える

ただ、それを経営が認識するかは別問題
必要かもまた別問題

WEBアンケがいくらバグってても問題ない
プリウスとか東証がバグってると大問題だけどさ
会計ソフトの表示が多少おかしくても帳尻と出力生成さえ合ってりゃ問題ない
結局、ケースバイケース

htmlがオブジェクト指向にならないのを見れば、
最良の方法でもないんだろ

バッチ書いてて、ログの中をforでまわしてstr=%*にいれようとしたら
ログの中に%文字列が存在してて積んだ

>>315
javascriptはclass構文取り入れてクラスベース言語に挙動を近付けているよ
互換性の問題もあるしシンタックスシュガー止まりだけど

HTML自体、イチイチプログラム書くのめんどいよねってので開発した言語だからな
バカチョン言語なので

高度なプログラムを書いていくと、自然にオブジェクト指向プログラミングになるよ
ブラウザとかは完全にオブジェクト指向開発だし
それ以外あり得ない
手続き型や関数型では複雑性の管理が不可能

産能大 プログラミング1 『南ちゃん』クラス…

講師も受講生も皆ぶっ飛んでた
コードを見せてもらったが
「あぁコイツら『仕事をしてるぜっ』って充足感を得るためにコードを書いてるんだな」
ってのがひしひしと伝わってきた（当時はまだ「意識高い系」なんて言葉はなかった）
まだWindowsが世に出回る以前だってのに完全に「イカレた」集団が出来上がってた

俺は三浦のクラスにまわされて本当に良かったと思ってた…

結局まぁ、プログラミング言語にもバカチョンレイヤーが必要なんだろうな
多分そういう話
Cでインラインアセンブラが使えるような感じで、バカでも書ける手続き型言語に、OOPレイヤーを入れるとかそんな感じで

>>1
つまり害悪なのはカプセル化であり、別にオブジェクト指向が悪なわけではないな
これにもしっかり、アランケイが関わった言語にはprivateは無いって書いてるやん
その通りでカプセル化なんてオブジェクト指向において必須ではない
Cの時代だって、勘の良い奴はオブジェクト指向なプログラミングをしてたものだよ

スレッドプログラミングにはプライベート必須なんですが
全部グローバルならシングルスレッドしかできない事になるよ
論理的には分かりやすいけど、効率は最悪だろうな
なにしろマルチコアCPUの利点が全く生きない
シングルスレッド性能が頭打ちなんだから、スレッドプログラミングは必須
つまりオブジェクト指向も必須なのは変わりないよ

隠蔽したメンバーが外から見えないのは当たり前
設計が悪いだけ

>>322
物理層にプライベートなんて概念は存在しない
アセンブラが分からないなら技術者なんて名乗るなよ

大昔のストラウストラップのC＋＋に関するインタビューにすべて答えが書いてある
フェイクだけど、書いてあることは真実

ITドカタが生き生きとするスレw

>>322
Cとかでスレッドプログラム組めるぞ？

>>82
そりゃ君のプログラミング能力が及んでなかったんじゃない？

>>274
昔からw3c に乗っ取ってなかったIE でしか
動かないシステム入れた奴がバカ

オブジェクト指向って元々設計思想であって実装は別の話なんだけど

カプセル化のお陰でシステムが高度になった反面、深いところまで触れんわな
今やAPIファーストでなんでもかんでもjson経由でデータのやり取りを行なっているが
Json変換ロジックを一から書いてって言われたらそれだけでバカにならん工数がかかるわな

>>328
プログラミングもあったかもしれないけど、アジャイルですらない。高い確率で失敗するとわかっている状態で顧客を説得できなかったとか、関わらないように出来なかったのかというのは未だに自問自答することがあるね。

>>331
深いところ触る必要ないでしょ
何らかのカスタマイズが必要なら継承ってのを使って表面的に修正を加えるんでしょ
知ってる

じゃあどうするのが正解なんだ？
もっとすばらしいプログラミング言語作ってくれよ

>>1
PCの知識無いくせに、いつもこの手のスレ立てるよね

やりたい事が出来なくて、再利用も改修出来なければ使わなければいい
無理矢理直したところで当初の思想から外れてるんだからその場凌ぎにしかならない
そんなライブラリは淘汰されれば良い

>>335
じゃあ君の優れた知識で反論してみてよ

ライブラリ使うなって話になりますやん

そもそも、使い回すものはどう使われるかわからんのだし、全部publicでいいんだよ

お互い利点も欠点もあるから
メンバー全て公開して好き勝手さわれるのも普通にリスクあるぞ
自分一人で作る訳じゃないから

privateでもいいけど、すべての変数にゲッターセッターは欲しいわ

あ、頭文字

>>334
言語じゃねーよ
1960年代から言われているように本来は共通化された設計手法が確立される事が大事

実装方法（言語）なんて時代と共に変わるんだから、そんなのはどうでもいい

オブジェクト指向がいいか悪いかじゃなくて、privateがダメって話じゃねーか

そんなアナタにprotected

privateなかったら計算途中で別スレッドから変数の内容変更されるだろ
シングルスレッド前提の手続き型言語しかやらんとそういう発想になる

結局、この手の議論は、スレッドプログラミングを知らないか、チャレンジしたが
挫折した者の意味不明の叫び声なんだよな
嫉妬混じりの
あるいは本物のバカ

JavaScriptプロトタイプはアート。

>>25
玄人志向

>>25
プロトタイプ

オブジェクト指向の真骨頂は複雑さの管理だからな
単純なミニプログラムには必要ない

外部のサーバに問い合わせてDNSを引いてIPでアクセスして、ハンドシェークして、HTML解析して、画面サイズに応じた配置に成形して、アドオンにコールバックして、
みたいな超複雑なプログラムを人間が管理しやすくするためのモノ
ただテキストを表示させるだけとか、並べ替えるだけとか、そういうのなら要らない
大半の業務で要らない

>>322
不変にすればおｋ

>>351
そんな説明じゃ何も利点が分からないよ
現にそんな手順なんてダラダラ順番に書いたコードの方が理解し易いからなぁ

まーあらゆる人間にメリットあるってもんでも無いからな
単純なプログラムなら手続き型でいいんじゃないか
大体1万行以下のプログラムならオブジェクト指向は要らないかな
適当だけど

俺的には関数が8個を超えた時点でクラスにまとめないと
なんかスコープによるバグがありそうでムズムズしてくる
意図しない変数への代入とか
処理があっちこっち飛んで全体の見通しも悪くなってくる
エラーの切り分けができない
などなど

まぁ、結局、やらかし経験無いと分かんないよな

privateは、内部処理用の変数やメソッドに対して定義するもの。
内部処理のつもりで作った部分を変えたら動かなくなったと怒られるので、公開部分だけを使ってくれれば動作を保証するよというもの。

それだけの事だけだったのだけど、隠蔽が正義になって何がなんでも隠蔽しようとするからおかしくなった。

>>324
物理層でもスーパーバイザー/ユーザーモードとか仮想とかMMUとか、メモリ空間や階層権限つけてアクセス制限かけるやん。

結合度の弱い処理単位に分ける事で相互作用による不明なバグの入り込む余地を減らす為だけなら、別にオブジェクト指向じゃ無くてもいいけどな。昔からある構造化プログラミングで充分だ。

>>357
それはもろともバッサリなんで、プライベートとかとは根本的に考え方が違うだろ

>>357
物理層＞BIOS＞OS＞APP

お前さんが言っている事は本当に物理層の話かな？

ProgateでJSコース一周したワイ、何を言ってるかさっぱりわからない
ほんとにエンジニア転職できるんか、、、？

異論反論おぶじぇくしょん♬

>>361
できるわけない

>>360
物理層に近くてもSMIとか隔離された領域はあるぞ

自分が作ったシンプルで流れるようなソースが
スパゲッティになっていく様を眺めるんですね。わかりま…

>>344
初心者向け（）解説書にオブジェクト指向＝カプセル化みたいな事書かれてるからそれ信じた馬鹿が馬鹿を再生産し続ける

オブジェクト指向ほど定義の定まらない言葉も珍しいな

要は再利用を意識しながらプログラミングすることでしょ？なんでもかんでもオブジェクト指向に当てはめてたらかえって無駄なタスクが増えるよね(´・ω・｀)

再利用なんていまだかつてされた事は無いけどなw

OSSとか標準ライブラリとかめちゃくちゃ再利用されてると思うのだけど
ああいうのは利用する側が分かりやすいようにオブジェクト指向で作られてるからだよね

素人が責務とかインタフェースとか何も意識せずに作ったライブラリなんて再利用されるわけない

>>370
それ、オブジェクト指向と関係ないやん
MS/DOSの昔から共通処理だからなぁ

昔のとの違いなんて、リエントラントかどうかだけだし

ライブラリを使用してても再利用はしてない方が多いような。
interfaceの実装は書くけどextendsはしない感じ。
ライブラリのクラスを継承しようとしたらfinalクラスだったでござるとかもあったりするし。
オブジェクト指向というよりは、デザインパターン重視な感じ。

結局、privateだの隠蔽だのは、バカが触って壊さないようにする為だよ
子供用の防止柵や補助輪のような物
ところがそのバカにその安全策を運用させると、あっちこっち補助輪付けたがって、
最終的にバイクとかに補助輪付け始めて、自爆したり、歩行者跳ね飛ばしたりし始める
安全策がむしろ厄災をもたらす

結局の所、技術的問題というよりソーシャルな問題

放送禁止用語とか、PTAのような物かもしれない
それ自体は無いと秩序が保たれないけど、
使いすぎると言語として成り立たなくなったり
社会が機能しなくなる
バカに運用させてはいけない物

あと著作権なんかもそうだな

>>1
まじかよw
月日が経ってあかんことになるとは
夢にも思わんかったな。

オブジェクト指向言われる前は
スパゲティだったんだよ
規律がなかった時代に聖書で「人のもの盗んではいけない」と説かれた、
ってレベルで無法地帯だったところの最初の指針レベルさ

>>377
スパゲティになるからgotoは悪って言い始めたのは構造化の時代でしょ

関数型プログラミングになれてるか今更、オブジェクトはちょっとね。

ゲーム作るわけじゃないし。

C++のグチャグチャなコーディングよりスパゲッティの方がマシ
というか、バカがコーディングしたら、どんな言語(道具)でもダメということ

オブジェクト指向ってなに？って聞いてまともな答えが返ってきたことないわ
コンピュータしか友達がないんだろうと思う。

多重継承もあんまりやられるとソース追えないよ
作りっぱなしのプログラムならいいけど、そういうのがトラブル起こしてメンテしなきゃいけないみたいな立場の人間もいるんだから
ストラウストップが言った改良したC言語だと思って作ってくれ

やたらに継承しまくって違う種類のスパゲッティになってる奴あるよな

継承も
使いすぎれば
GOTO :HELL
結局バカは
何をやっても駄目にする

OOPという言葉が、この世に出てきてから、そろそろ３０年か・・・
新しい技術用語が雨後の筍のように出ては消えるＩＴ業界において

本物は長く生き続け、その変化は底流に流れるマグマのように緩やかだ

しかしそろそろ、時代にあったメンテナンスを
ほんのちょびっとだけ、受けてもいい

そんな時期なのかも、知れないね

結局の所コードを整理できるかなんだよな
機能追加やアップデートで膨れ上がった分整理し直さなければならない
それが出来ないものは死ぬ

gotoでジャンプしまくるスパゲッティプログラム

やっぱりアセンブリ言語が最強だよね

うちの会社工数高いからプログラマー居なくなったりして切羽詰まった顧客がくるんだよ
で、ソース見たら頭抱えるようなのばかり

>>389
そういう仕事って3倍、いや10倍でもいいくらいはふっかけないと採算あわないでしょ。
どーせバグだらけだし。

>>388
・MASMで構造化プログラミング
・C++にインラインアセンブラでオブジェクト指向プログラミング

アセンブラに擬似条件マクロ付けた奴は天才だよ

結局、言い方変えただけで、構造化プログラミングの考え方から一歩も踏み出して無いんだよな。
オブジェクト指向みたいな曖昧模糊な物を習うより、構造化プログラミングを学んだ方がはるかに役に立つぞ。

世の中は、C++でも構造化プログラミングだよな。

まぁ、構造化のほうがやり尽くされてるからな
評価法も確立してて、工賃取りやすい
人も集めやすい

結局、この国は成果物の価値よりも、過程を評価するから、オブジェクト指向はそもそもビジネス的に成立しない
日本型正社員システムや派遣システムと非常に相性が悪い

その意味ではオブジェクト指向は愚かな考えだな
確かに

個人用の遊びか研究分野でしか利用価値が無い
ビジネス的にはコード行数が減って単価がデフレし、バグが減ってサポートも儲からない
ビジネス的にダメなプログラミング手法だろうね

真面目にやるほど賃金が下がり、働くほどデスマになる構造なのだから仕方がない
ソレがジャップ社畜の様式美なのだから

>>393
構造化プログラミングが第一にあって、
その肝となる関数の管理を体系化したものがオブジェクト指向
OOP単品じゃクソの役にも立たないってのは同意だけどOOPを実践出来るくらい洗練されていて欲しい

オブジェクト指向のデザインパターンとインターフェースが悪だわ
机上では確かに便利そうだけど、実際それでシステム作るとデバッグがめんどくさい

オブジェクト指向でもスパゲティプログラムができるからねえ

>>398
インターフェースは分かるけどデザパタはあった方が見通し立ちやすいっしょ

無茶な仕様変更、無茶なスケジュール、ドキュメント等を切り捨てるコストカット

オブジェクト指向だのカプセル化だの関係なく、ソースのスパゲティ化は無くならない

技術は積み重ねなんで上の方だけ学んでも仕方ない
全ての技法は制約なんだが何で制限するのか意味が分かってないと際限なく暴走する
暴走しないための物なのに

ワイ爺
子供たちの情報の授業が羨ましい

よくわかっていないけど
オブジェクト指向プログラミングを
学ぶにはpython かruby でいいの？

>>398
継承はいらんが実装は欲しい

そもそもオブジェクト指向拒否したら
外部ライブラリとか他のソフトウェア、OS、BIOSすら否定しない？
全部ブラックボックスになるでしょ

自分の意図してない処理やコードが嫌って言うなら電子回路から作ったら良いと思う

>>404
OOPを学ぶってのがよく分からんが、完全なOOP設計を売りにしてるrubyでええんやないの
数値リテラルですらオブジェクトって扱いや。全てがオブジェクトで構成されている

これからはN88ベーシックの時代なんだよ！
アムローーーーーーーーー！！！！！！！！！！

>>407
ありがとう
昔C++の解説書読んだけど
さっぱりわからなかった
ruby でやり直したいw

趣味プログラミングのC++でクラス使おうとして
「クラスの中に動的配列確保して、と」
「そのクラスを本文の中で動的に配列確保して、と」
「あれぇぇぇ〜？メモリの開放はどすするのぉ〜？？？」
みたいに挫折した俺には勉強になるスレ

今時もうルビーなんか勧めない
それならjs かphp勉強したほうがいい
Php も7になってだいぶ改善した

ルビーは自由度高すぎてスパゲティになりやすい

>>411
jsはES2015でマシになったけど演算子オーバーロードが無かったり、引数無し関数の()を省略が出来なかったりまだまだ未成熟な感じ
他人のコードを検分するのならともかく趣味で自由度高くて困る事はないわ

何から始めるかは作りたいものに応じて選んだ方がいいよ
例えばだが、スマホアプリ作ってる/作りたいなら、
flutterから始めるとか面白いかもな
jsに似ていてpython同様sqliteも使える

>>409
金を得るならC＃かJava
それ以外仕事が異常に少ない

まー、オブジェクト指向やるならRubyかC♯だな
ほかは手続き型臭いし、変なクセがある
伝統的な理由で
Javaもクラスファイルの仕様のせいでオブジェクト指向とは言い難い手続き型言語に成り下がってる
C++をクラス化して面倒くさくしただけのもの
C++はひたすら実験的なオブジェクト要素を加えた手続き型言語

JSはただの手続き型言語でスレッドプログラミングすらできないゴミ
Pythonも似非VBレベルの補助輪言語
変な癖があるやつの矯正施設

まー、Rubyはジャップ政府と連るんでるので、反日勢力から目の敵にされてるからね
今後どうなるかはワカランけど、普通に良い言語だよ
C♯はある程度わかってる人向けだなぁ
初心者には酷かもしれない

Rubyは書き方が気持ち悪いからねえわ

>>27
中身公開してグダグタになるケースと、隠蔽してどハマりになるケースを比較したら、圧倒的に前者の方が多そうだしな。

オブジェクト指向は万能じゃないけど、それは何でもそうだし、適材適所なだけだな。

>>42
でもライブラリ提供でAPIが公開されてるだけの関数でもそれは同じじゃね？

>>66
じゃ、仕様変更に強いのは何？

継承って役に立つの
functionで十分事足りるだろ

JavaScript勉強しようかな

>>382
多重継承を使う設計が悪いだけな気がする。多重継承を使わなければならないケースなんて本来少ないんじゃないかと思う。

・オブジェクト指向の仕組みや有用性をよく理解して
・継承や多重継承を有効最低限に止め
・将来プライベート部分の変更に対応し易い様設計し
・そのためのドキュメント等も残し
と言う様な事ができるプログラマが
巨大で複雑なプログラムをスッキリさせる場合に有効な手法
それ以外の場合は手続き型で可
みたいな認識でいいんだろうか？

まー継承が生きるケースってのは、完璧なロジックが確定した部分だけだろう
それ以外は、バグ修正や仕様変更で、修正のオセロやる事になる
これの厄介なとこは、デバッグできない実行時エラーを新たに生み出すこと
車が暴走したりする

全部グローバル変数でスパゲッティ量産された反省からカプセル化が出てきたのに時代に逆行するのか

俺はここの説明が一番分かりやすかったかな

疑りぶかいあなたのためのオブジェクト指向再入門
http://kmaebashi.com/programmer/object/

オブジェクト指向は元々設計の方が主なんだが
主客転倒した阿呆の多い事よ

バカなJS使いか何かがでたらめな事言ってるだけの様な
コイツラ低レベルなハードの知識皆無で何でもライブラリに投げれば解決すると思ってる
今は環境が良くなってそれでも割となんとかなるから、変に自信ついちゃってるみたいで、終いにゃローカル変数イラネみたいなこと言い出してる始末

Rubyというゴミで激遅な言語を未だに崇めてるバカってもう淘汰されたからほとんど残ってないらしい

>>430
PythonとNode.jsに完全に駆逐された

速度なんて今日日問題にならんと思うがなぁ
よほど巨大なサイト以外は

「staticおじさん」はすげー馬鹿にされてるけどさ
オブジェクト指向を変に使う輩も多いんだよね

「それstaticメソッドの方がよくね？」とか
「それ多態使うよりシンプルに条件分岐でよくね？」とか
適した使い方を理解してないのがたまにいる
APIでstaticや多態がどう使われてるかを考えればわかると思うんだが

>>433
結局インスタンスを作らなきゃいけない理由ってちゃんと出たんだっけ？
教科書に書いてあるから的な事ばっか言ってる奴ばっかだった印象

>>388
mov ah,09h
INT 21h
mov cx 0Ah
loop
jz 0

インスタンスはスレッド用だろ
スレッド中に別スレッドから変数変えられたらバグる
シングルスレッドならプログラマーが気をつけてさえいれば特に必要はない

リエントラント