オブジェクト指向ってクソじゃねぇかよPart3
■ このスレッドは過去ログ倉庫に格納されています
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/ >>304
争いは同じレベルのものでしか発生しないから
※賢かったらそうそう争いに発展せず、平和的な言葉のやり取りで完結する >>306
ひろゆき「それってなんかデータとかあるんですか？」 >>306
韓国と争いになってる日本は韓国と同レベルなんですね アメリカと争いになってる北朝鮮はアメリカレベル！凄い！大国！ >>305
は？じゃあ客から見たらテメーを使うメリットは欠片もないなｗ > は？じゃあ客から見たらテメーを使うメリットは欠片もないなｗ
「早く作れる」のがメリットでは？？？ コーディングが早いか遅いかなんて誰も気にしとらんのですけど >>314
そんなんだからお前の仕事はいつも期限をオーバーするんだよ
早く作れや なにか言い返したいのやろうけどおしてもコーダー目線から離れられないおまえら可愛いすぎw OSがOOPと無縁？
エクスプローラがビヨンビヨン動いたりするのはOOで設計、コーディングしたことの現れなんだが 「お、俺のほうが安く出来るし！」
行き着く先は餓死か一家心中か 人月見積の業務屋こそOOとは無縁
OOPの言語的な進歩によるメリットをありがたく享受しとけや >>319
どうした？ オープンソースに仕事取られたか？ チ
ン
ポ
が
シ
コ
シ
コ
す
る
ぜ
！
！
チ ン ポ が シ コ シ コ す る ぜ ！ ！
チ
ン
ポ
が
シ
コ
シ
コ
す
る
ぜ
！
！ シコシコするのはチンボだと何度言わせるつもりかね？キミ このスレが崩壊するまで
オブジェクト指向の話なんか聞きたくない いや普通にオフショアに発注するから
この業界も順調に空洞化してます ぐちゃぐちゃコードを量産して
なかなか動かないから困るんだよ オブジェクト指向信者は bash なんかより PowerShell 使うんやろなあ オブジェクト指向信者 = なんでも使えるので、それはないかと 一人でオブジェクト指向のプログラムソフト作ったことあるやつなら、オブジェクト指向は凄いってなる
でもオブジェクト指向の恩恵を受けられなかったおじさん達は何も恩恵を受けられなかった
boostはオブジェクト指向！ ビルド時間がboostすることで有名なクソライブラリね。 ビルド時間と実行時間の総和のトレードオフで、
別にビルド時間が７２時間とか掛かってもいいんじゃねえの
出来たバイナリを数百万人とか数億人が使うんだろ
全世界で節約できる実行時間総和は桁違いじゃん ビルドとテストに1分以上かかると集中力切れてやる気なくなる
昔はビルドに1日かかることもあったと爺さんが言ってたが正気の沙汰じゃない じゃあ指向は関係なしで開発方針の問題じゃねえの
爺さんの時代はコーディングシートやらフローチャートやらだろ
ビルドにミスは無いんだよ
だから一日掛かってもいい
ビルド以前にテストが終わってる時代だろ Visual StudioのLive Unit Testが意外と使える子だった エンティティにサービスを注入するのって有り？無し？
DDDだと無しってことになってるけど現実的に厳しくねえか? >>338
いいぞ、のんびりで
午前中→ハイ、ポチッとな→ネットサーフィン
午後→(#･∀･)オイ!新人（俺）、バグってるじゃねーか!→(*ﾟ∀ﾟ)フヒヒ、サーセン→修正→ハイ、ポチッとな
→じゃあ、今日は○○くん（俺）のせいでテストできないので帰宅で アラン・ケイ御大より優れてる奴だけOOをディスりなさい 「私がオブジェクト指向と言い出しましたがC++なんて知りません。クラスベースなんて知りません」 クラスを使うことはまあいいんだよ（必要ならオブジェクトでシミュレートすればいい）
ただ、抽象データ型みたいにプロシージャやデータ構造をどうするかに拘泥して消耗したなくない
アラン・ケイが考えるオブジェクト指向プログラミング
http://d.hatena.ne.jp/katzchang/20080807/p2
いずれにせよ、クラス指向（つまり、クラスを使って抽象データ型を実践するアイデアの）オブジェクト指向
http://www.stroustrup.com/whatis.pdf
と、メッセージングを介して「決定の遅延」を実践するオブジェクト指向は分けて考えた方が混乱がない
http://metatoys.org/oxymoron/oxymoron.html ウンコ言語Smalltalkの影響を色濃く受けたDart 1.0は
Googleの力をもってしてもウンコ過ぎて全く普及しなくて
方向転換を余儀なくされたし、
やっぱりSmalltalkのやり方は間違ってるんじゃね Smalltalkと同じダイナミックバインディングのJavascriptは？良い悪いはともかく圧倒的普及率だが >>347
Javascriptは関数型の方向に舵を切っているように見える >「決定の遅延」
に書いて有るのは単純にアプリケーションを作るにはそれで良いと思うけど
何時も土方系のデータ処理アプリケーションを作るのに
それは適用出来るのだろうか?
という疑問が何時も有る
端的にデータ処理系は対象外とか例外とかになっているのかねぇ?
そういう事なら納得し易いんだけど
これはsmalltalkだけじゃなくてオブジェクト指向的に作る場合何かも感じるんだけど?
どうなんだうろか?
guiなんかだとかなり適合度が高い感じで考えやすく作り易いけど
どうもデータ処理
という視点で考えた時に上手い方法を思いつかない
途中で処理を変えてしまうと後半に影響が出てしまう様な気がするんだけど
それを上手く影響し無い様に作れる物なのだろうか?
ウォーターフォール的に考えて作って
変更する時はテストで流して確認する
これしか無い様な気がして成らないんだけど
余りこの手の分野でのやり方を自分は聞かない
誰か聞いたこととかやってたりとかしないですかねぇ?
smalltalkの場合動的にやるのはいいけど
テストもせずにいきなりやる物なのだろうかという疑問が消えない
ファロみたいに試行錯誤する場合や互いの影響度が低い場合は良いと思うんだけど
データフローが有る様な物に適用出来るのだろうか? >>350
「遅延」させるべき「決定」事項が一切ない決まりきった処理なら
（メッセージングの）オブジェクト指向でやる意味はないんじゃない？
程度によってはソフトウェアである必要すらないわけでハードウェアで組んでしまえという話にもなる
という話ではなく？
何か小さな具体的な例を出してくれると実際のコードを示しつつ議論しやすいかと Smalltalkはウンコ過ぎるから別の言語に乗り換えた方が良い、って決定を遅延し続けた結果
時代に取り残されてるのがSmalltalker >>350
そのデータ処理の内容を分析してモデル化するだけでは？
データ処理だとダメという感覚が全くわからん >>351
何て言うのか
smalltalkについては殆ど知らないんだけど
見た感じ手続き型とは随分違う感じで書いている様に見えるんだけど
メッセージパッシングで遅延する場合はそういう手法で良い様な気がするんだけど
従来型の手続き的に書く場合はsmalltalkではどう書くのだろうか?
という疑問が有る
って事なんだけど
特に具体例って言われても無かったりする
c++だと手続き的にもオブジェクト指向的にも書けるけど
smalltalkだと手続き的に書けない?様に見えるから
遅延しない手続き的な処理が必要な時はどうしているんだろうか?
という疑問
って事
>>353
具体例が無いからアレなんだけど
その
分析してモデリング化する
これをどうやっているのだろうか?
所謂バッチ処理みたいな感じの時にどうやって分けているんだろうか?
という疑問って言えば良いかなぁ?
guiみたいなのだと処理がバラバラに発生するからイメージ出来るんだけど
バッチってズラッと流れるからどう分けるのかイメージ出来ない
そんな感じ何ですよねぇ バッチ処理もウェブもドメインモデルは同じ
外部インターフェイスとアダプタが異なるだけ
バッチ処理だから急にモデルが崩壊するということはありえない >>355
馬鹿かお前。
手続き型の反対は宣言型。SQLやPrologやXML、HTMLみたいなのを言うの。
ほか大抵の言語は手続き型。
当然smalltalkも純然たる手続き型。
いい歳して知ったかぶり恥ずかしいよ。
手続き型言語で宣言「的」に書く、書けるというのとは全然別。
それはナポリタン（ナポリと関係ない）トルコライス（トルコと関係ない）みたいなもん。 smalltalk知らないから
その遅延とやらをどう活用するか聞いてるのに
>いい歳して知ったかぶり恥ずかしいよ。
殆ど知らない
って書いて有るのに
知ったかとか
何言ってってんだよ
アホだなおまえ >>358
357はSmalltalkについては一般論として語っているだけで
ケイの言わんとする「決定の遅延」についてはあまり実感ない（つまりうまく説明できない）んじゃないかな…
SmalltalkはSmalltalk-72というごく初期のバージョンでは（非同期でないながらも）実際に
メッセージを送ることをしていたのだけれども、結局当時のマシンではパワー不足で
その後のSmalltalk-76以降、普段は現在主流のメソッドの動的呼び出しをメッセージに見立てて
メッセージに対応するメソッドがないときだけメッセージをハンドリングできる機構だけ足された
よく言えば省コスト、悪く言えばナンチャッテな実装に落ち着いていて、PharoやVisualWorksといった
今あるSmalltalk処理系でもそれは変わっていません。
なので、通常の言語（たとえばJavaとか）と同じ程度には手続き的な記述は普通に可能です。
あと念のため、ここでいう「遅延」というのはあくまでも設計の指針であって、動的メソッド呼び出し以上の
特別な「遅延機能」というものがあるわけではありません。
強いて言えば、システムを動かしながらでもコードの変更が可能（というか、Smalltalkは
システムを動かしながらしかコードの変更はできません）というのが、他の、ちょうど例に挙がった
Javaのように静的型チェックのある早期結合を好む言語とは決定的に違うところで、
この特徴は件の「決定の遅延」の実践（たとえばデバッグのやり方など）に大いに役に立っています。 >>358
顔真っ赤だぞ。新しい単語覚えられてよかったな。これからは知らない単語思い込みで安易に使わないようにしようなｗｗ エンティティが複雑で巨大なグラフ構造を形成していてしかも集合として調和が取れていなければならないという要件に対してオブジェクト指向は激弱
しかし多くの業務ではまさにこのような集合としての調和が重視すべき要件になりやすい
この事実に対してオブジェクト指向信者の人々はどういう答えをだしたの？
俺としては業務ロジックをSQLで表現する2層アーキテクチャの他に現実的な答えはないと思うのだが ストアドプロシージャで処理できる程度のことを
ORMでわざわざオブジェクト指向に落とし込む意味が分からん
とかそういう話？ クラスで知識整理なんぞせず一本グソで書く方が良いって話か 日本企業でオブジェクト指向が受け入れられない理由がわかった
ビジネスルールそのものが曖昧で矛盾してるから堅牢なオブジェクトモデルを構築できないんだ
だからカプセル化を解除して不変条件を排除して矛盾を受け入れるしかない >>364
＞ビジネスルール
ビジネス・スルー力
かと空耳してしまいました…ほ・し・い・ぃ とにかく全て、再利用だ！カプセル化だ！
たとえ今は使い捨てでも将来的に使う可能性はゼロではないから予め全てに備えておくのがオブジェクト指向だ！
無駄に手を広げてからのドキュメント整備、日本流オブジェクト指向は疲れる >>366
疎結合が目的であって再利用性は副作用だと高卒の俺は思ってたけど、合ってるのかな 「再利用できる部品を大量にストックする」という理念のΣプロジェクトがあったので方向性は何一つも間違ってない 高卒てマジにここまでバカなん？>>367が特別にバカなんか？ インタフェースって作る意味あるの？
どうせインタフェースを改良したら実装のもうも変えなきゃいけないし
二重メンテにならんのかね？ インターフェースの改良て何なん？高卒て時々突拍子もないこと考えるよなw >>371
Hello Worldくらいはやってみたら？ >>372
プロパティ追加が必要になったらインタフェースにも実装のほうにも追加するじゃん？ >>371
インターフェースを作る意味は、
同じようだけど少し違う処理がたくさんある時に条件分岐よりバグが少なく実装できる
ってところかと
それに二重メンテになるのはインターフェースを使っても使わなくても同じだろ >>374
大声でケチ付けるけど自分の意見はなく3日後には忘れるタイプに建設的な答えは無理 オブジェクト指向はクズだ無能
↓
じゃあどんな設計方法が良いの
↓
そんな事も知らんのか自分で調べろ高卒糞無能
↓
エントリポイントに一本グソ開発しました
↓
これやこれ 読みやすい
だいたいこういう流れになる じゃあどの言語が良いの
↓
オブジェクト指向のアレだよアレ後は自分で調べろ 言語名を確定させないことによりシュレーディンガーのSmalltalkを延命させる仕組み rubyやjsはインタフェースないじゃん
でも困らない オブジェクト指向の対の概念を定める
エントリポイント一本グソ指向
以上の定義を前提に語ってくれたまえ
諸君 チ チ チ チ チ
ン ン ン ン ン
ポ ポ ポ ポ ポ
が が が が が
シ シ シ シ シ
コ コ コ コ コ
シ シ シ シ シ
コ コ コ コ コ
す す す す す
る る る る る
ぜ ぜ ぜ ぜ ぜ
！ ！ ！ ！ ！ >>380
型ゆるゆるでめちゃくちゃ困ってるだろうがw A〜Dのオブジェクトがあったとして、Aの処理からDの処理させれば早いのに、オブジェクト指向的にとかいって、A→B→C→Dってやっていくプログラムが許せない >>386
つまりどういうことでしょうか？ その２ >>386
依存関係があるから
あとDIパターン
D「俺のケツの穴はCしか受け付けない！」
C「俺のケツの穴はBしか受け付けない！」
B「Aよ、お前は俺にだけ可愛がられろ」 レイヤーにしてるけど直接呼び出したいって言って崩壊していくの面白い 戦後冷戦下での社会構造（レジーム）がそのまま思考方法にも反映されている
基本的には階級とか階層とかレイヤーとかで、「物事には順序がある」「親子関係がある」「上下関係がある」との基本的認識から始まっている
基本的認識ってのが一番怪しくて、そもそもが上下関係とか親子関係とかはハッキリいって古臭い物事の考え方になる
全部がフラットで並置されていて平等だ、との考え方は比較的新しい思想だ
階層がある上下がある身分がある……は幻想なので、幻想をそのまんまモデリングした思考方法は破綻する
「継承していて欲しい」とする社会的要請から始まったスムーズな連想である継承という機能はオブジェクト指向最大の癌になっている
理想の階級社会では継承は万全に働くものの、それを実装したプログラムは機能不全に陥る
なのでオブジェクト指向と言うときは暗黙のうちに階級の存在を認めている
物事や人間の上下関係（マウンティング）を意識すらもしないうちに認めている
だからJavaは企業ユースが多い
日本的なピラミッド型の組織、上意下達の組織構造では、その組織構造をそのまま反映したプログラミング言語が選定されやすい
また現代はダーウィンの進化論後の世界でもあるので、やはり思想的に「継承」という理念は分かりやすい
（実際は進化したら部位が複雑になる）
つまりオブジェクト指向≒Javaは20世紀後半の思想をそのまんま代弁しているし、逆にそれなしではJavaは後世では理解できない その時点で継承が最も適したモデルだったら継承を使う
知識が増えて不適切になったと判断したら継承を解消してモデルを作り直す
重要なポイントは「不適切になった」ことを判断できるかどうか
それをするには今の理解を完全に反映したモデルが必要
モデルがないと新しい知識が古いモデルに与える影響すら判断もできん デザパタって建築業界元ネタらしいね。もちろんそのままは
適用できんけど。 >>368
Σプロジェクトは大失敗だったわけだが。 業界関係者だけを一ヶ所に集めると暴走してしまう。
それが教訓だろう。Σは知らんけど。 >>399
いや、関係者を一箇所に集めるとみんなまとめて事故死するんだぞ。 >>400
そういう思い込みが膨らむだけだからこうなる。
構造的にひとつの事業のリーチ範囲が広すぎて
ありうる結果の可能性の組み合わせが多すぎる。
だから共通認識を形成しようと思うと原始的か
考えられ得るすべての可能性を潰してからじゃ
ないとここまでいかないんだよ。 枠決めて枠の中で動くのを基本にしてりゃよかったのに
インターネットの可能性は無限、とかプログラマーは
抽象的考えが得意だ説、を額面通り取りすぎたんだよ。
それぞれベースがないから身動き取れないだけだろ。 Σは偉い人だけが集まって”さ、もらえるお金の配分の話しようね”だけしか興味なかったので IT産業なんてソフト事業の最たるもんだからあらゆる可能性に
対処しようとしてオブジェクトとかお金とか抽象概念をやたら
求めたがる。職業病の性癖だよ。たとえば使いみち挙げられる？ あとは唯一の指標にしてるからか。ポイント獲得ゲームになってる ■ このスレッドは過去ログ倉庫に格納されています
