カプセル化の有害性、オブジェクト指向は愚かな考え

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/06/18(木) 23:47:36.69ID:l/2SQUll
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。

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

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

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)
2020/06/18(木) 23:48:12.14ID:l/2SQUll
大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。医学的にいえば「手術ができない存在」であるといえる。
2020/06/18(木) 23:48:21.02ID:l/2SQUll
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
2020/06/18(木) 23:49:03.96ID:l/2SQUll
実例

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

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

世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。頂点データをGPUに送信した直後にGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。

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

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

カプセル化は恐ろしいね！！
2020/06/18(木) 23:50:00.80ID:RTNtaITn
仕様変更
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。

オブジェクト指向云々ではない。
2020/06/18(木) 23:50:50.45ID:vbQxaIet
シンプルなほうが解読しやすいよね
散逸して現物しか残ってない場合とか特に
2020/06/18(木) 23:51:52.81ID:aKnQJHa5
副作用の起きない処理はpublicでも問題ないだろうな
問題が起きるとすれば運用側の問題
2020/06/18(木) 23:53:22.90ID:evvN6o0n
データベースに出し入れするだけの業務システムなんかは問題ない。
データベース上のデータなんてグローバル変数となんら変わらない。
クラスは構造体としてしか使わないから深い階層化も起きないし。
9デフォルトの名無しさん
垢版 |
2020/06/18(木) 23:54:18.03ID:evvN6o0n
>>2
C++が流行りだしたころに、これ言ったら変な目で見られたわ。
設計能力と未来を見通す能力がある人限定なんだよ。
大人数だと低い方に合わされるから、大人数プロジェクトには不向き。優秀な少数精鋭プロジェクトなら良いんだけどね。
2020/06/18(木) 23:54:53.81ID:evvN6o0n
日本の場合はカプセル化されてようがいまいが基底クラスなんて弄ったら再テストしなきゃいけないから
同じ機能を持ったクラスを作るので意味が無い
2020/06/18(木) 23:55:28.61ID:/lqvqqb1
そもそもアランケイの考えたものと今のオブジェクト指向が違うっていうね
オブジェクトなんて名前を使ったせいでオブジェクトが重要だと勘違いしてるし全員
よって失敗
ただ発展には貢献したそれだけ
12デフォルトの名無しさん
垢版 |
2020/06/18(木) 23:56:10.69ID:TSP7N+np
昔作ったクラスを継承したり再利用したりなんて殆どない

データと関数数個だけで済むものを
無駄にクラス化して
ヘッダと実装にわけて無駄にコード追いにくくするのはあかん
2020/06/18(木) 23:57:06.18ID:MtNDH7Ee
>>4
この実例は良くないよね
Modelクラスが何かにラップされてるならその元を探して改良すべきなのに
それやらないでトリッキーな方法で回避するから余計面倒になってる
2020/06/18(木) 23:58:55.32ID:YGaYv0dq
>>13
その相手が壮大なオープンソースのフレームワークで
改変した修正パッチが開発チームから拒絶されたら死ぬ。

フォークしても誰がメンテナンスするんだよ
2020/06/18(木) 23:59:22.80ID:bx1rTxjv
内部に状態を持つな
2020/06/18(木) 23:59:49.19ID:q6R3f09j
オブジェクト指向で設計やるとしばしば手段が目的化してしまって不必要に複雑化する
2020/06/19(金) 00:00:25.84ID:/31ICsy6
privateの考え方自体は悪くないんだが、
privateの必要性を理解できる人間はそもそもprivateを必要としないんだよ
そしてprivateが必要な人間はprivateの本質を理解せずにおかしな使い方をしてしまう
こういうジレンマは何にでもある
2020/06/19(金) 00:01:18.25ID:+IhkHRGD
カプセル化は机上の空論ってのは頭いい人しかいないチームでしか通用しない
日本のIT土方みたいに想像を絶する馬鹿が無限に湧いてくる現場ではコードを守るために不可欠
2020/06/19(金) 00:01:50.77ID:2JP1keJd
無駄に継承しまくるのが害悪なだけ
2020/06/19(金) 00:02:19.49ID:wxIbXk9M
あとになって公開できないなら隠蔽するなってことだろ
ずっと保守し続けて、公開してくれって言われたらすぐ設計変更して公開できるなら別にかまわん
でもずっと保守し続けるかどうかは予算や人事で決まるんだから、それらに関われないと責任持てんわな
2020/06/19(金) 00:03:06.93ID:BXl5HLPF
想像を絶する馬鹿が想像を絶するカプセル化をしてしまうんだよなあ……
2020/06/19(金) 00:04:23.05ID:mHF7j7mX
特定の事例はオブジェクト指向とかクラスが悪いわけじゃなくて
その設計が失敗してるだけですね
2020/06/19(金) 00:05:13.42ID:bOeh/ohg
>>4
OpenGL ESはファイルからテクスチャ1枚読み込むのにもアホみたいに面倒臭いからなw
OpenGLの手法すら使えないとか何故そこまで削った…って感じだし
24デフォルトの名無しさん
垢版 |
2020/06/19(金) 00:06:06.77ID:wn9UnRAm
OOPにすらついていけない本物のバカには無理ってだけ
まあOOPが無理ならどんなプログラミングも無理だけど
2020/06/19(金) 00:06:46.04ID:OaIc6ajp
路線バス、タクシー、レンタカー、自家用車の4つを使ってオブジェクト指向を説明して欲しい。

難しすぎて全然頭に入らない。
2020/06/19(金) 00:07:21.87ID:c3NGwjmZ
時代はDDDって聞いたんだけど
2020/06/19(金) 00:07:51.60ID:cOWnS532
余計な例えは無意味
そもそも変数とか関数とか引数とか理解しとんのか
2020/06/19(金) 00:08:22.59ID:Vry7Dmyh
じなあガンダムで例えてくれ
2020/06/19(金) 00:08:50.90ID:ih59xFoN
オブジェクト思考は糞
関数の引数と戻り値だけ信用すれば良い
オブジェクトに状態持たせるフィールドなんて可読性落ちるだけなのに理解できない一周も二週も遅れてるやつが声高に叫んでるのは笑えるw
2020/06/19(金) 00:09:59.54ID:DxHcuyZI
>>4
頂点データは常に見られるようじゃないとダメだろ…
レンダリングエンジンとの結びつきどうなってるんだ？
2020/06/19(金) 00:11:36.72ID:A+kahko2
>>30

>>252
ざっくり見た感じVRAMに送り込んでオリジナルは破棄だな。
もともとXBOX360のフレームワークだからリソースがいまほど潤沢じゃない前提の設計だな。

それがOpenGL ESの「VRAMが書込専用」という追加仕様の襲来で火を吹いた感じだな
https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Platform/Graphics/Vertices/VertexBuffer.DirectX.cs
https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Platform/Graphics/Vertices/VertexBuffer.OpenGL.cs
2020/06/19(金) 00:12:19.87ID:Z/R3v37q
>>31
そんな仕様変更が入る方がおかしいんじゃないかな
2020/06/19(金) 00:12:37.66ID:CAQAyB0l
>>32
そのくらいの仕様変更はザラにある
2020/06/19(金) 00:12:54.82ID:Vvw9/CQL
おっそろしーなぁ
35デフォルトの名無しさん
垢版 |
2020/06/19(金) 00:13:25.36ID:+NZQ8ymG
オブジェクト思考って何？
誰か説明して
2020/06/19(金) 00:13:53.03ID:0YXkLCwz
カプセル化は新人や増援部隊に変な事させない為の仕組み
開発者全員が高度なプロフェッショナルならただの足枷でしかない
37デフォルトの名無しさん
垢版 |
2020/06/19(金) 00:14:23.01ID:sx6tbUfu
オブジェクト原理主義者のコードを引き継ぐ事になった時の絶望感は異常
2020/06/19(金) 00:15:15.75ID:yjfNCK7+
iPhoneアプリ開発に必須のobjective-cやswiftもカプセル化はできない。
人工知能で大流行のpythonもカプセル化はできないようになってる。

これらはアクセス非推奨だがアクセス自体はできる
2020/06/19(金) 00:15:51.85ID:a/1dBbgF
「カプセル化は悪」「カプセル化はオブジェクト指向ではない」というのがやっと広まりだした。
2020/06/19(金) 00:16:10.62ID:GyiKM2YL
仕様変更の恐ろしさは異常
2020/06/19(金) 00:16:29.89ID:sB9nUpkw
未来予測できるが勝負所
2020/06/19(金) 00:17:11.14ID:Xum0r1kt
>>5
深い階層化って利点あるの？
2020/06/19(金) 00:17:23.63ID:HW2oJRWs
怖いですねえ
2020/06/19(金) 00:20:35.02ID:f1TZFQAl
カプセル化は隠蔽体質ってことですね
2020/06/19(金) 00:30:03.04ID:EiviKE7C
>>4
そもそも設計が間違ってるのをオブジェクト指向のせいにしてるんじゃねーよハゲ
2020/06/19(金) 00:49:19.41ID:8/oqYbS2
>>45
XNA作ったマイクロソフトの超エリートたちですら設計ミスをするくらいオブジェクト指向は難しい。
2020/06/19(金) 01:06:57.53ID:brGXdq3V
ECS
2020/06/19(金) 01:27:35.28ID:gQU/M+Sr
> オブジェクト指向の発案者であるアラン・ケイもコーディング規約
> （頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、
> アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。

つまり
1. privateという概念（アンダースコアという概念）自体はOK
2. ただしprivateでも外部からアクセスできるようにすること
という話
2020/06/19(金) 03:21:23.63ID:sPM5NjRd
経験的に言えば、ライブラリや部品的なクラスでは、カプセル化はかなり有効で、
安全になる。
ところがアプリ自体の中にクラスの場合、隠蔽しても余り意味が無い事が
分かって来た。
ファイルツリービューの中のデータを隠して、メインウィンドウのクラスからいじれないように
しても、アプリの場合にははっきり言って意味が無い。
2020/06/19(金) 04:46:03.37ID:8+I0eawj
>>49
そのアプリを複数人でいじってるんなら、ライブラリやらの恩恵と同じ効果があるんじゃね？

カプセル化の是非は、グローバル変数の弊害の話と本質は同じだよね
影響範囲を狭くした方がミスは防げるが、柔軟性は失われる
2020/06/19(金) 06:36:33.75ID:wpvtDg0l
>>48
ちょっと違うな
ST80でもOWでもVWでも共通だが
privateはあくまでもプロトコルの一つという設計だから外部からアクセスできるように・・という考え方ではないよ
具体的な扱われ方としてはインスタンス専用のローカルメソッドのような使われ方をする

なおprivateプロトコルは全てではないが
他のオブジェクトからコールするとデバッガに落ちるように仕組んでたりする
（外部からは使わせないよってこと）
2020/06/19(金) 07:02:17.44ID:wpvtDg0l
>>49
データを誰が保持するのかって問題はMVCの当初から大問題にはなってたからね
単純にModelが必ず持つという形にすると指摘した問題が必ず発生するから

経緯的にPluggableMVCへと変遷しどこからでもupdateプロトコルを受け付けることができるようになった
データはMVCのどれも保持しなくなり、ひとまずの決着がついたが
この形式であっても誰がどのようにupdateをかけているのか逐一コーディングしなければならない問題が残ってた

そこで現在ではデータを保持するAspectAdaptor系は
いわゆるアクセサを書く必要もなくなり通知を受け取るだけで動作するようになっている
（updateのためにアクセサを呼ぶなどということはしない）
2020/06/19(金) 07:18:54.82ID:gQU/M+Sr
>>51
> 他のオブジェクトからコールするとデバッガに落ちるように仕組んでたりする

殆どの言語はprivateにアクセスできる
2020/06/19(金) 07:22:21.49ID:XaRstyom
OOは業務システム向き
組み込みだと細分化し過ぎるんじゃね？
2020/06/19(金) 09:36:31.93ID:wpvtDg0l
>>53
目的が違うので
private配下のメソッドは外部から呼ばれることを意図しない（ことになっている）
のとbehaviorにさえアクセスを許さなかったりする

ただこれは言語仕様としてコントロールしているわけではないので
あくまでも慣例として扱われてる
適当なクラスを作ってprivateプロトコルに適当なメソッドを組めば好きに外部から呼び出すことは出来る

そうは言っても慣例破ってるコードはすぐ見つかってしまうのでまあよろしくないことになる
2020/06/19(金) 11:11:36.05ID:t8sp3Lp3
>>11
アランケイのは、完璧なものから取り除いていくような感じだったな
2020/06/19(金) 11:46:38.71ID:gQU/M+Sr
>>55
private配下のメソッドは外部から呼ばれることを意図しない（ことになっている）
頭文字にアンダースコアを付けるなどの命名規則で縛る程度のも、外部から呼ばれることを意図しない（ことになっている）
2020/06/19(金) 11:54:17.24ID:I4TvFtlH
>>54
業務システムだとDBいじくるだけだから深い階層構造に関わることはまずないだろ。
DBというグローバル変数をクラスという名の構造体にコピーして、編集して、書き戻すという単純作業の繰り返し。
2020/06/19(金) 12:44:14.84ID:dtaC8DdL
隠蔽って言うからおかしくなる
privateは一貫性を守るために変更可能性のスコープをオブジェクト内部に限定するためのものであって、内部状態の秘匿が目的じゃない
というかオブジェクトの内部状態が外から分からないようなものはテスト出来ないでしょ
ダメだろそんなクラス
2020/06/19(金) 16:09:36.39ID:sPM5NjRd
>>50
>そのアプリを複数人でいじってるんなら、ライブラリやらの恩恵と同じ効果があるんじゃね？
個々のクラスをじっくり丁寧に作って、データを変更する専用のメソッドをきっちり
作り上げれば安全性は確かに高まる。
これは、人数の多いプロジェクトなら可能だと思われる。
ただ、個人製作のアプリだと、そこまでクラスを作りこむのは時間が掛かりすぎてとても
効率が悪くなる。
結局、個人製作レベルだと、ファイルツリーニューの中のデータを変更する際にやってはいけないことなどの注意事項をどこかのテキストファイルなどに書いておいて
データはpublicにしておいて、それに気をつけながら、アプリの他のクラスからでも普通に書き込みアクセスするように
した方が開発時間は少なくて済むようだ。
2020/06/19(金) 16:12:27.76ID:sPM5NjRd
>>59
その気持ちも分かる。
しかし、その一方で、例えば fopen()のようなライブラリ関数を使う際、
FILE構造体の中身までしっかり公開されてなくても、fopenの使い方が
しっかり説明されいればそれで十分であり、逆にFILE構造体の中を勝手に見て、
それを前提にプログラムしすぎることは、FILE構造体の中身が変更になった
場合に問題となる。
2020/06/19(金) 17:22:18.89ID:gQU/M+Sr
>>60
> 結局、個人製作レベルだと、ファイルツリーニューの中のデータを変更する際にやってはいけないことなどの注意事項をどこかのテキストファイルなどに書いておいて

それをソースコードの中に書くんでしょ？ privateって
2020/06/19(金) 17:31:41.22ID:I4TvFtlH
結論：privateにしたら、必ずgetterを用意しておきましょう。
64デフォルトの名無しさん
垢版 |
2020/06/19(金) 17:34:28.47ID:sPM5NjRd
>>62
昔から言われていることなんだけど、ソースコード以外の場所にちゃんと
フローチャートなり、データの構造や関数の関係図、何らかの図など
プログラム中に書きにくい注意事項をどこかに予め書いておくと、
プログラムにとても役立つんだ。
2020/06/19(金) 22:59:31.97ID:wpvtDg0l
>>60
そこは考え方次第だからねー
asyncでいいならファイルツリーはすべてNodeクラス配下で汎用的に扱う方が楽なので
俺ならそうする
コードも少なくて済むし扱いやすい
常にsyncって話になるとfsevent見て反映させる

カプセル化のメリットは全体像を知らなくても扱えるように理解して努力していれば
結果的にコストが下がることにあるけれど
オブジェクト扱ってるのに中身は関数で組んでいる人が混じると割と悲惨なことに（なった）
2020/06/19(金) 23:03:14.16ID:wpvtDg0l
>>64
それよりもテストコードが含まれてないソースは信用できないね個人的に
コードが更新される時ドキュメントも更新されるとは限らないし
ドキュメントには本当に必要な情報がなかったりもする・・
67デフォルトの名無しさん
垢版 |
2020/06/20(土) 18:55:53.44ID:EGdSCTAj
こっちでも始まったのか
2020/06/20(土) 19:10:33.56ID:Zs4RBEp5
>>66
でもチェックしにくいとこってデバイス絡みや使ってるUIのライブラリの変な仕様のとこだろ
テストコードなんて動くの？
2020/06/20(土) 19:23:07.65ID:H+D2eLk6
>>68
デバイスを使う「ソフトウェアコード」のテストをするんだから、
デバイスのテストをしても意味がないぞ

「デバイス」のテストなのか、デバイスを使う「ソフトウェア」のテストなのか
どちらを対象としたテストなのかをはっきりさせよう

デバイスのテストはデバイスのテストで別にやる
両方を同時にテストしようとするな
2020/06/20(土) 19:47:22.29ID:Zs4RBEp5
>>69
でも全部ひっくるめて正常に動いて欲しいんだろ？
どう組んだら正しいのか誰もわからないものでプログラマをぶん殴る口実がほしいと
71デフォルトの名無しさん
垢版 |
2020/06/21(日) 21:47:24.01ID:yZ1Fm+rk
>>64
> プログラム中に書きにくい注意事項をどこかに予め書いておく
これが必要になる場面って大抵は設計が歪んでいる
2020/06/21(日) 22:27:56.93ID:TM3DTGpo
>>68
>でもチェックしにくいとこってデバイス絡みや使ってるUIのライブラリの変な仕様のとこだろ
そういうところを切り出してモックなら動くことを示してソフト側は悪くないって
言い張るための技術だぞ。
2020/06/23(火) 01:08:56.89ID:hoXOIHD6
https://video.twimg.com/ext_tw_video/1273820540352909313/pu/vid/270x478/HZq8qYhba4upqVyw.mp4
2020/06/23(火) 14:03:05.97ID:Amhn2FuL
頭が悪いやつが多い業界だし、カプセル化は有用だと思うがな
勝手に変更させない、有用に変更しても理解できないので変更しないほうがいいって
2重の意味で
2020/06/23(火) 15:11:05.61ID:o6bKn79R
>>1
そのカリフォルニア大学ソースどこ？
むしろ、彼らの作成するソース(github)を見るとオブジェクト指向で、@private(JSDoc)を律儀に記述しているけど。
ん？JavaScript以外？C#やJava？
privateをサポートする言語でカプセル化しない馬鹿なんてこの世に存在するの？
76デフォルトの名無しさん
垢版 |
2020/06/23(火) 23:33:42.34ID:JaUjApVc
>>74
そういうクラスを作る側が頭が良くて
利用する側がどうせ頭が悪いという傲慢さが
オブジェクト指向が批判される原因だと思うわ。

大体 既に書かれたコードの記述で
新規プログラマーのコーディングを制限しようと
言う考えが傲慢以外の何物でもない。


お前らの言う頭の悪い奴は元のクラスのprivateを
publicに変えるかもしれないし
Personというクラスの隣に
Person2と言うクラスを複製してそっちの方をpublicに
変えて利用するかもしれない。
でもそれって止められるわけないだろ？
それを言語仕様で止めようとしてる事がどうかしてる
元のクラスが使いにくくて変えたいから変えたいんだよ。

それに5重6重にカプセル化されたオブジェクトなんて
邪魔でしかないんだよ。デバッグしにくいし
2020/06/23(火) 23:58:42.49ID:AMcrD26I
いや、止められるだろ。。そのままリリース出来る方がおかしいだろ
2020/06/24(水) 00:33:12.84ID:Vx2zY5TL
むしろクラスを作る側が>>76みたいな頭の良い人から身を守るために必要
想定してない使用法でバグった時に責任とりたくないもん
Person2に不具合があっても俺には関係ないから好きにやってくれ
2020/06/24(水) 00:57:36.62ID:I5+T+Giv
https://video.twimg.com/ext_tw_video/1266492233030627329/pu/vid/720x1280/AvyTiTS0EeNdp3DS.mp4?tag=10
2020/06/24(水) 01:13:12.47ID:ZBvJ9IFx
カプセル化の弊害とかいいつつ
カプセル化すら理解してなくて草生える
2020/06/24(水) 01:57:06.31ID:W7e3ICMc
>>76を見てると、オブジェクト指向を批判しているのはバカが過剰に騒いでいるだけなんだなと良く分かるw
2020/06/24(水) 02:39:07.65ID:gVxDDgwX
今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな
2020/06/24(水) 03:02:02.88ID:irp07WaX
>>81
匿名性のSNSの限界。
記名性だと色々と能力が分かって、無視される。
2020/06/24(水) 04:52:29.63ID:evfa9tXu
>>76
何がいいたいのか全くわからん。

例えばお前が言ってる頭の悪いやつが、
ローカル変数をグローバル変数に変えるかもしれんよな？
そういう場合、なんだっていうんだ？
ローカル変数が悪いって話をしてるのか？
それを止められないからローカル変数は邪魔といいたいのか？
2020/06/24(水) 07:20:27.23ID:ib1NZqNH
>>84
まあ、しょうがねぇよなって話じゃん
2020/06/24(水) 07:21:13.77ID:ib1NZqNH
初めの書き手が悪いんじゃなくてあくまで変更したやつの責任
2020/06/24(水) 12:20:09.25ID:irp07WaX
>>76
というか、MFCみたいに修正が推奨されて無い場合は除いて、
自社開発のプログラムであれば、能力がある人にはあなたが修正するのを
上司が許可してくれると思うんだ。
もし、修正を許可してもらえないなら、実績が足りて無いか能力のアピールが足りてない。
2020/06/24(水) 12:31:25.83ID:bZ0w8eld
オブジェクト指向の肝は擬人化と依頼だからな
頼む相手の内部状態を勝手に変えないってのは
無茶重要でしょ　
2020/06/24(水) 13:17:22.34ID:U8BVWvkL
>>88
>オブジェクト指向の肝は擬人化と依頼だからな
初めて聞いた
2020/06/24(水) 13:54:42.95ID:bZ0w8eld
擬人化キャラ（クラス）の関係性で物語を生成する＝オブジェクト指向
そんなかんじで習ってそのまま理解してたな　ちなみに学校は恥ずかしくて
言えないような底辺学校
2020/06/24(水) 14:29:54.72ID:+bJy5A36
依頼はどことなく委譲って分かるけど擬人化はただのスケベじゃん
2020/06/24(水) 14:40:07.82ID:bZ0w8eld
>>91
頭わるくてまともな学校にいけない奴らに
教えるために先生が工夫してくれたんだろうね　依頼ってのも困ったら
依存心の高い奴らに教えるのにそういう言い回ししたんだろうね
いま思えばなかなか立派な先生だったな　口は臭かったが
2020/06/24(水) 15:16:35.37ID:W7e3ICMc
>>92
分かりやすく噛み砕いて教える方法としては良いと思うけど、>>88のように一般的に通じるつもりでいきなり独自用語を使うと話が変な方にいくから、不特定多数を相手にするときは一般的な用語を使った方がいいぞ。
2020/06/24(水) 16:47:31.01ID:ZBvJ9IFx
>>91
本来人間相手にしかに使わない依頼や委譲って言葉を使ってる時点で擬人化してる
2020/06/24(水) 16:51:31.16ID:ZBvJ9IFx
擬人化と依頼のメタファは一般的
オブジェクト指向に限らないけどOOを説明する際によく使われたから

Tell Don’t Ask
http://media.pragprog.com/articles/jan_03_enbug.pdf
https://martinfowler.com/bliki/TellDontAsk.html
2020/06/24(水) 19:00:14.27ID:z1f+Mb2g
>>76

> お前らの言う頭の悪い奴は元のクラスのprivateを
> publicに変えるかもしれないし
> Personというクラスの隣に
> Person2と言うクラスを複製してそっちの方をpublicに
> 変えて利用するかもしれない。

ねーよw
もう少し基礎知識学んでから出直してこい。
まず、ライブラリの中身を書き換えること自体、ありえない。

たぶん、見ず知らずの人達が書いたコードを共有する仕組みから知らないのだろう。
2020/06/24(水) 19:25:00.99ID:vlqGopWc
>>96
いや、そもそもできちゃうじゃん
そして別にできてもいいじゃん
それが嫌だとしたらそれをドキュメントに書いとけよ
ソースには書けないし書いても消せるからさ
98デフォルトの名無しさん
垢版 |
2020/06/24(水) 19:30:57.72ID:6CkV8gwI
>>96
いや、周囲や協力会社(依頼元クライアント側プログラマ)
にこれやるやつゴロゴロいるんだって
ソースファイルでもテーブルでも何でも他人が書いたやつ
複製して仕様変更に対応するんだわ。
privateとかカプセル化なんて笑っちまうよマジで
でも意外と何とかなってる、複製したあとはレガシーコードは
全部捨てちまうんだわ

職場で新人研修で「抽象クラスって何のために作るんですか？」
って毎回のように訊かれるけど
「俺にも分からない。必要性を感じたことも、便利だと思った
事も無い。」って正直に答えてる。
オブジェクト指向の入門書に当然のようにabstract紹介
されてるけどそれの有用性を的確に説明している
教科書を見たことがない
interfaceのほうは重要性は分かるしちゃんと説明している
2020/06/24(水) 19:42:39.07ID:J59L1bOF
>>98
abstractは
上の方の人達が未知の設計概要として会議で使う
コーダーじゃない営業や客とのコミュニケーション用
2020/06/24(水) 19:53:36.46ID:GEcMOOIw
>>75
これだろ
https://ja.m.wikipedia.org/wiki/DARPAモデル

DARPAモデルとは、インターネットの持つべき通信機能を階層構造に分割したモデルである。

アプリケーション層、トランスポート層、インターネット層、ネットワーク層の4層で構成される。

DARPAモデルという呼称は、インターネットの研究開発を行っていたDARPAに由来する。
元々は確固たる仕様や定義はなく、IPやTCPやUDPなどの仕様中に個々に、あるいは暗黙の前提として存在していたものだが、後からRFC 1122で1つにまとめられた。


IP群はプロトコルとサービスをカプセル化する事によって抽象化する。
通常、より上位層のプロトコルはその目的の達成に役立てるために、より下位層のプロトコルを用いる。
これまでIETFはインターネット・プロトコル・スタックをRFC 1122で定義された4層から変更した事はない。
IETFは7層からなるOSI参照モデルに従うような試みはせず、また標準化過程（Standards Track）にあるプロトコル仕様やその他の構造上の文書をOSI参照モデルに対して参照する事もしない。

https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:UDP_encapsulation.svg

RFC 3439では、インターネット構造に関して第3章の序文に"Layering Considered Harmful （階層化の有害性）"と題された節が有り、
「階層化」という考え方が概念的および構造的にさまざまな利点を持っているが、
実装面では層単位で同じような最適化が繰り返し発生することによる無駄な処理により効率的な実装を阻害し、複雑化を招くことがあり、
また低層部分のみに存在するデータにアクセスできない場面が発生するなど、

インターネット・プロトコルの目指す「単純化」という原則に反することもあることが明記された。
2020/06/24(水) 20:04:30.89ID:GEcMOOIw
>>75
ググったら日本語訳もあった
http://www5d.biglobe.ne.jp/stssk/rfc/rfc3439j.html
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況