カプセル化の有害性、 ..
2:デフォルトの名無しさん
20/06/18 23:48:12.14 l/2SQUll.net
大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。医学的にいえば「手術ができない存在」であるといえる。
3:デフォルトの名無しさん
20/06/18 23:48:21.02 l/2SQUll.net
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
4:デフォルトの名無しさん
20/06/18 23:49:03.96 l/2SQUll.net
実例
XNA（M
5:onoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。 ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。 世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。頂点データをGPUに送信した直後にGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。 しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。 さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。 カプセル化は恐ろしいね！！
6:デフォルトの名無しさん
20/06/18 23:50:00 RTNtaITn.net
仕様変更
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。
オブジェクト指向云々ではない。
7:デフォルトの名無しさん
20/06/18 23:50:50 vbQxaIet.net
シンプルなほうが解読しやすいよね
散逸して現物しか残ってない場合とか特に
8:デフォルトの名無しさん
20/06/18 23:51:52 aKnQJHa5.net
副作用の起きない処理はpublicでも問題ないだろうな
問題が起きるとすれば運用側の問題
9:デフォルトの名無しさん
20/06/18 23:53:22.90 evvN6o0n.net
データベースに出し入れするだけの業務システムなんかは問題ない。
データベース上のデータなんてグローバル変数となんら変わらない。
クラスは構造体としてしか使わないから深い階層化も起きないし。
10:デフォルトの名無しさん
20/06/18 23:54:18.03 evvN6o0n.net
>>2
C++が流行りだしたころに、これ言ったら変な目で見られたわ。
設計能力と未来を見通す能力がある人限定なんだよ。
大人数だと低い方に合わされるから、大人数プロジェクトには不向き。優秀な少数精鋭プロジェクトなら良いんだけどね。
11:デフォルトの名無しさん
20/06/18 23:54:53.81 evvN6o0n.net
日本の場合はカプセル化されてようがいまいが基底クラスなんて弄ったら再テストしなきゃいけないから
同じ機能を持ったクラスを作るので意味が無い
12:デフォルトの名無しさん
20/06/18 23:55:28.61 /lqvqqb1.net
そもそもアランケイの考えたものと今のオブジェクト指向が違うっていうね
オブジェクトなんて名前を使ったせいでオブジェクトが重要だと勘違いしてるし全員
よって失敗
ただ発展には貢献したそれだけ
13:デフォルトの名無しさん
20/06/18 23:56:10.69 TSP7N+np.net
昔作ったクラスを継承したり再利用したりなんて殆どない
データと関数数個だけで済むものを
無駄にクラス化して
ヘッダと実装にわけて無駄にコード追いにくくするのはあかん
14:デフォルトの名無しさん
20/06/18 23:57:06.18 MtNDH7Ee.net
>>4
この実例は良くないよね
Modelクラスが何かにラップされてるならその元を探して改良すべきなのに
それやらないでトリッキーな方法で回避するから余計面倒になってる
15:デフォルトの名無しさん
20/06/18 23:58:55.32 YGaYv0dq.net
>>13
その相手が壮大なオープンソースのフレームワークで
改変した修正パッチが開発チームから拒絶されたら死ぬ。
フォークしても誰がメンテナンスするんだよ
16:デフォルトの名無しさん
20/06/18 23:59:22.80 bx1rTxjv.net
内部に状態を持つな
17:デフォルトの名無しさん
20/06/18 23:59:49.19 q6R3f09j.net
オブジェクト指向で設計やるとしばしば手段が目的化してしまって不必要に複雑化する
18:デフォルトの名無しさん
20/06/19 00:00:25.84 /31ICsy6.net
privateの考え方自体は悪くないんだが、
privateの必要性を理解できる人間はそもそもprivateを必要としないんだよ
そしてprivateが必要な人間はprivateの本質を理解せずにおかしな使い方をしてしまう
こういうジレンマは何にでもある
19:デフォルトの名無しさん
20/06/19 00:01:18.25 +IhkHRGD.net
カプセル化は机上の空論ってのは頭いい人しかいないチームでしか通用しない
日本のIT土方みたいに想像を絶する馬鹿が無限に湧いてくる現場ではコードを守るために不可欠
20:デフォルトの名無しさん
20/06/19 00:01:50.77 2JP1keJd.net
無駄に継承しまくるのが害悪なだけ
21:デフォルトの名無しさん
20/06/19 00:02:19.49 wxIbXk9M.net
あとになって公開できないなら隠蔽するなってことだろ
ずっと保守し続けて、公開してくれって言われたらすぐ設計変更して公開できるなら別にかまわん
でもずっと保守し続けるかどうかは予算や人事で決まるんだから、それらに関われないと責任持てんわな
22:デフォルトの名無しさん
20/06/19 00:03:06.93 BXl5HLPF.net
想像を絶する馬鹿が想像を絶するカプセル化をしてしまうんだよなあ……
23:デフォルトの名無しさん
20/06/19 00:04:23.05 mHF7j7mX.net
特定の事例はオブジェクト指向とかクラスが悪いわけじゃなくて
その設計が失敗してるだけですね
24:デフォルトの名無しさん
20/06/19 00:05:13.42 bOeh/ohg.net
>>4
OpenGL ESはファイルからテクスチャ1枚読み込むのにもアホみたいに面倒臭いからなw
OpenGLの手法すら使えないとか何故そこまで削った…って感じだし
25:デフォルトの名無しさん
20/06/19 00:06:06.77 wn9UnRAm.net
OOPにすらついていけない本物のバカには無理ってだけ
まあOOPが無理ならどんなプログラミングも無理だけど
26:デフォルトの名無しさん
20/06/19 00:06:46.04 OaIc6ajp.net
路線バス、タクシー、レンタカー、自家用車の4つを使ってオブジェクト指向を説明して欲しい。
難しすぎて全然頭に入らない。
27:デフォルトの名無しさん
20/06/19 00:07:21.87 c3NGwjmZ.net
時代はDDDって聞いたんだけど
28:デフォルトの名無しさん
20/06/19 00:07:51.60 cOWnS532.net
余計な例えは無意味
そもそも変数とか関数とか引数とか理解しとんのか
29:デフォルトの名無しさん
20/06/19 00:08:22.59 Vry7Dmyh.net
じなあガンダムで例えてくれ
30:デフォルトの名無しさん
20/06/19 00:08:50.90 ih59
31:xFoN.net
32:デフォルトの名無しさん
20/06/19 00:09:59.54 DxHcuyZI.net
>>4
頂点データは常に見られるようじゃないとダメだろ…
レンダリングエンジンとの結びつきどうなってるんだ？
33:デフォルトの名無しさん
20/06/19 00:11:36.72 A+kahko2.net
>>30
>>252
ざっくり見た感じVRAMに送り込んでオリジナルは破棄だな。
もともとXBOX360のフレームワークだからリソースがいまほど潤沢じゃない前提の設計だな。
それがOpenGL ESの「VRAMが書込専用」という追加仕様の襲来で火を吹いた感じだな
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
34:デフォルトの名無しさん
20/06/19 00:12:19 Z/R3v37q.net
>>31
そんな仕様変更が入る方がおかしいんじゃないかな
35:デフォルトの名無しさん
20/06/19 00:12:37 CAQAyB0l.net
>>32
そのくらいの仕様変更はザラにある
36:デフォルトの名無しさん
20/06/19 00:12:54 Vvw9/CQL.net
おっそろしーなぁ
37:デフォルトの名無しさん
20/06/19 00:13:25 +NZQ8ymG.net
オブジェクト思考って何？
誰か説明して
38:デフォルトの名無しさん
20/06/19 00:13:53.03 0YXkLCwz.net
カプセル化は新人や増援部隊に変な事させない為の仕組み
開発者全員が高度なプロフェッショナルならただの足枷でしかない
39:デフォルトの名無しさん
20/06/19 00:14:23.01 sx6tbUfu.net
オブジェクト原理主義者のコードを引き継ぐ事になった時の絶望感は異常
40:デフォルトの名無しさん
20/06/19 00:15:15.75 yjfNCK7+.net
iPhoneアプリ開発に必須のobjective-cやswiftもカプセル化はできない。
人工知能で大流行のpythonもカプセル化はできないようになってる。
これらはアクセス非推奨だがアクセス自体はできる
41:デフォルトの名無しさん
20/06/19 00:15:51.85 a/1dBbgF.net
「カプセル化は悪」「カプセル化はオブジェクト指向ではない」というのがやっと広まりだした。
42:デフォルトの名無しさん
20/06/19 00:16:10.62 GyiKM2YL.net
仕様変更の恐ろしさは異常
43:デフォルトの名無しさん
20/06/19 00:16:29.89 sB9nUpkw.net
未来予測できるが勝負所
44:デフォルトの名無しさん
20/06/19 00:17:11.14 Xum0r1kt.net
>>5
深い階層化って利点あるの？
45:デフォルトの名無しさん
20/06/19 00:17:23.63 HW2oJRWs.net
怖いですねえ
46:デフォルトの名無しさん
20/06/19 00:20:35.02 f1TZFQAl.net
カプセル化は隠蔽体質ってことですね
47:デフォルトの名無しさん
20/06/19 00:30:03 EiviKE7C.net
>>4
そもそも設計が間違ってるのをオブジェクト指向のせいにしてるんじゃねーよハゲ
48:デフォルトの名無しさん
20/06/19 00:49:19.41 8/oqYbS2.net
>>45
XNA作ったマイクロソフトの超エリートたちですら設計ミスをするくらいオブジェクト指向は難しい。
49:デフォルトの名無しさん
20/06/19 01:06:57.53 brGXdq3V.net
ECS
50:デフォルトの名無しさん
20/06/19 01:27:35.28 gQU/M+Sr.net
> オブジェクト指向の発案者であるアラン・ケイもコーディング規約
> （頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、
> アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
つまり
1. privateという概念（アンダースコアという概念）自体はOK
2. ただしprivateでも外部からアクセスできるようにすること
という話
51:デフォルトの名無しさん
20/06/19 03:21:23.63 sPM5NjRd.net
経験的に言えば、ライブラリや部品的なクラスでは、カプセル化はかなり有効で、
安全になる。
ところがアプリ自体の中にクラスの場合、隠蔽しても余り意味が無い事が
分かって来た。
ファイルツリービューの中のデータを隠して、メインウィンドウのクラスからいじれないように
しても、アプリの場合にははっきり言って意味が無い。
52:デフォルトの名無しさん
20/06/19 04:46:03 8+I0eawj.net
>>49
そのアプリを複数人でいじってるんなら、ライブラリやらの恩恵と同じ効果があるんじゃね？
カプセル化の是非は、グローバル変数の弊害の話と本質は同じだよね
影響範囲を狭くした方がミスは防げるが、柔軟性は失われる
53:デフォルトの名無しさん
20/06/19 06:36:33.75 wpvtDg0l.net
>>48
ちょっと違うな
ST80でもOWでもVWでも共通だが
privateはあくまでもプロトコルの一つという設計だから外部からアクセスできるように・・という考え方ではないよ
具体的な扱われ方としてはインスタンス専用のローカルメソッドのような使われ方をする
なおprivateプロトコルは全てではないが
他のオブジェクトからコールするとデバッガに落ちるように仕組んでたりする
（外部からは使わせないよってこと）
54:デフォルトの名無しさん
20/06/19 07:02:17.44 wpvtDg0l.net
>>49
データを誰が保持するのかって問題はMVCの当初から大問題にはなってたからね
単純にModelが必ず持つという形にすると指摘した問題が必ず発生するから
経緯的にPluggableMVCへと変遷しどこからでもupdateプロトコルを受け付けることができるようになった
データはMVCのどれも保持しなくなり、ひとまずの決着がついたが
この形式であっても誰がどのようにupdateをかけているのか逐一コーディングしなければならない問題が残ってた
そこで現在ではデータを保持するAspectAdaptor系は
いわゆるアクセサを書く必要もなくなり通知を受け取るだけで動作するようになっている
（updateのためにアクセサを呼ぶなどということはしない）
55:デフォルトの名無しさん
20/06/19 07:18:54.82 gQU/M+Sr.net
>>51
> 他のオブジェクトからコールするとデバッガに落ちるように仕組んでたりする
殆どの言語はprivateにアクセスできる
56:デフォルトの名無しさん
20/06/19 07:22:21.49 XaRstyom.net
OOは業務システム向き
組み込みだと細分化し過ぎるんじゃね？
57:デフォルトの名無しさん
20/06/19 09:36:31.93 wpvtDg0l.net
>>53
目的が違うので
private配下のメソッドは外部から呼ばれることを意図しない（ことになっている）
のとbehaviorにさえアクセスを許さなかったりする
ただこれは言語仕様としてコントロールしているわけではないので
あくまでも慣例として扱われてる
適当なクラスを作ってprivateプロトコルに適当なメソッドを組めば好きに外部から呼び出すことは出来る
そうは言っても慣例破ってるコードはすぐ見つかってしまうのでまあよろしくないことになる
58:デフォルトの名無しさん
20/06/19 11:11:36.05 t8sp3Lp3.net
>>11
アランケイのは、完璧なものから取り除いていくような感じだったな
59:デフォルトの名無しさん
20/06/19 11:46:38 gQU/M+Sr.net
>>55
private配下のメソッドは外部から呼ばれることを意図しない（ことになっている）
頭文字にアンダースコアを付けるなどの命名規則で縛る程度のも、外部から呼ばれることを意図しない（ことになっている）
60:デフォルトの名無しさん
20/06/19 11:54:17.24 I4TvFtlH.net
>>54
業務システムだとDBいじくるだけだから深い階層構造に関わることはまずないだろ。
DBというグローバル変数をクラスという名の構造体にコピーして、編集して、書き戻すという単純作業の繰り返し。
61:デフォルトの名無しさん
20/06/19 12:44:14.84 dtaC8DdL.net
隠蔽って言うからおかしくなる
privateは一貫性を守るために変更可能性のスコープをオブジェクト内部に限定するためのものであって、内部状態の秘匿が目的じゃない
というかオブジェクトの内部状態が外から分からないようなものはテスト出来ないでしょ
ダメだろそんなクラス
62:デフォルトの名無しさん
20/06/19 16:09:36.39 sPM5NjRd.net
>>50
>そのアプリを複数人でいじってるんなら、ライブラリやらの恩恵と同じ効果があるんじゃね？
個々のクラスをじっくり丁寧に作って、データを変更する専用のメソッドをきっちり
作り上げれば安全性は確かに高まる。
これは、人数の多いプロジェクトなら可能だと思われる。
ただ、個人製作のアプリだと、そこまでクラスを作りこむのは時間が掛かりすぎてとても
効率が悪くなる。
結局、個人製作レベルだと、ファイルツリーニューの中のデータを変更する際にやってはいけないことなどの注意事項をどこかのテキストファイルなどに書いておいて
データはpublicにしておいて、それに気をつけながら、アプリの他のクラスからでも普通に書き込みアクセスするように
した方が開発時間は少なくて済むようだ。
63:デフォルトの名無しさん
20/06/19 16:12:27.76 sPM5NjRd.net
>>59
その気持ちも分かる。
しかし、その一方で、例えば fopen()のようなライブラリ関数を使う際、
FILE構造体の中身までしっかり公開されてなくても、fopenの使い方が
しっかり説明されいればそれで十分であり、逆にFILE構造体の中を勝手に見て、
それを前提にプログラムしすぎることは、FILE構造体の中身が変更になった
場合に問題となる。
64:デフォルトの名無しさん
20/06/19 17:22:18.89 gQU/M+Sr.net
>>60
> 結局、個人製作レベルだと、ファイルツリーニューの中のデータを変更する際にやってはいけないことなどの注意事項をどこかのテキストファイルなどに書いておいて
それをソースコードの中に書くんでしょ？ privateって
65:デフォルトの名無しさん
20/06/19 17:31:41 I4TvFtlH.net
結論：privateにしたら、必ずgetterを用意しておきましょう。
66:デフォルトの名無しさん
20/06/19 17:34:28 sPM5NjRd.net
>>62
昔から言われていることなんだけど、ソースコード以外の場所にちゃんと
フローチャートなり、データの構造や関数の関係図、何らかの図など
プログラム中に書きにくい注意事項をどこかに予め書いておくと、
プログラムにとても役立つんだ。
67:デフォルトの名無しさん
20/06/19 22:59:31 wpvtDg0l.net
>>60
そこは考え方次第だからねー
asyncでいいならファイルツリーはすべてNodeクラス配下で汎用的に扱う方が楽なので
俺ならそうする
コードも少なくて済むし扱いやすい
常にsyncって話になるとfsevent見て反映させる
カプセル化のメリットは全体像を知らなくても扱えるように理解して努力していれば
結果的にコストが下がることにあるけれど
オブジェクト扱ってるのに中身は関数で組んでいる人が混じると割と悲惨なことに（なった）
68:デフォルトの名無しさん
20/06/19 23:03:14.16 wpvtDg0l.net
>>64
それよりもテストコードが含まれてないソースは信用できないね個人的に
コードが更新される時ドキュメントも更新されるとは限らないし
ドキュメントには本当に必要な情報がなかったりもする・・
69:デフォルトの名無しさん
20/06/20 18:55:53 EGdSCTAj.net
こっちでも始まったのか
70:デフォルトの名無しさん
20/06/20 19:10:33 Zs4RBEp5.net
>>66
でもチェックしにくいとこってデバイス絡みや使ってるUIのライブラリの変な仕様のとこだろ
テストコードなんて動くの？
71:デフォルトの名無しさん
20/06/20 19:23:07.65 H+D2eLk6.net
>>68
デバイスを使う「ソフトウェアコード」のテストをするんだから、
デバイスのテストをしても意味がないぞ
「デバイス」のテストなのか、デバイスを使う「ソフトウェア」のテストなのか
どちらを対象としたテストなのかをはっきりさせよう
デバイスのテストはデバイスのテストで別にやる
両方を同時にテストしようとするな
72:デフォルトの名無しさん
20/06/20 19:47:22 Zs4RBEp5.net
>>69
でも全部ひっくるめて正常に動いて欲しいんだろ？
どう組んだら正しいのか誰もわからないものでプログラマをぶん殴る口実がほしいと
73:デフォルトの名無しさん
20/06/21 21:47:24.01 yZ1Fm+rk.net
>>64
> プログラム中に書きにくい注意事項をどこかに予め書いておく
これが必要になる場面って大抵は設計が歪んでいる
74:デフォルトの名無しさん
20/06/21 22:27:56.93 TM3DTGpo.net
>>68
>でもチェックしにくいとこってデバイス絡みや使ってるUIのライブラリの変な仕様のとこだろ
そういうところを切り出してモックなら動くことを示してソフト側は悪くないって
言い張るための技術だぞ。
75:デフォルトの名無しさん
20/06/23 01:08:56.89 hoXOIHD6.net
URLﾘﾝｸ(video.twimg.com)
76:デフォルトの名無しさん
20/06/23 14:03:05.97 Amhn2FuL.net
頭が悪いやつが多い業界だし、カプセル化は有用だと思うがな
勝手に変更させない、有用に変更しても理解できないので変更しないほうがいいって
2重の意味で
77:デフォルトの名無しさん
20/06/23 15:11:05.61 o6bKn79R.net
>>1
そのカリフォルニア大学ソースどこ？
むしろ、彼らの作成するソース(github)を見るとオブジェクト指向で、@private(JSDoc)を律儀に記述しているけど。
ん？JavaScript以外？C#やJava？
privateをサポートする言語でカプセル化しない馬鹿なんてこの世に存在するの？
78:デフォルトの名無しさん
20/06/23 23:33:42.34 JaUjApVc.net
>>74
そういうクラスを作る側が頭が良くて
利用する側がどうせ頭が悪いという傲慢さが
オブジェクト指向が批判される原因だと思うわ。
大体 既に書かれたコードの記述で
新規プログラマーのコーディングを制限しようと
言う考えが傲慢以外の何物でもない。
お前らの言う頭の悪い奴は元のクラスのprivateを
publicに変えるかもしれないし
Personというクラスの隣に
Person2と言うクラスを複製してそっちの方をpublicに
変えて利用するかもしれない。
でもそれって止められるわけないだろ？
それを言語仕様で止めようとしてる事がどうかしてる
元のクラスが使いにくくて変えたいから変えたいんだよ。
それに5重6重にカプセル化されたオブジェクトなんて
邪魔でしかないんだよ。デバッグしにくいし
79:デフォルトの名無しさん
20/06/23 23:58:42.49 AMcrD26I.net
いや、止められるだろ。。そのままリリース出来る方がおかしいだろ
80:デフォルトの名無しさん
20/06/24 00:33:12.84 Vx2zY5TL.net
むしろクラスを作る側が>>76みたいな頭の良い人から身を守るために必要
想定してない使用法でバグった時に責任とりたくないもん
Person2に不具合があっても俺には関係ないから好きにやってくれ
81:デフォルトの名無しさん
20/06/24 00:57:36 I5+T+Giv.net
URLﾘﾝｸ(video.twimg.com)
82:デフォルトの名無しさん
20/06/24 01:13:12.47 ZBvJ9IFx.net
カプセル化の弊害とかいいつつ
カプセル化すら理解してなくて草生える
83:デフォルトの名無しさん
20/06/24 01:57:06.31 W7e3ICMc.net
>>76を見てると、オブジェクト指向を批判しているのはバカが過剰に騒いでいるだけなんだなと良く分かるw
84:デフォルトの名無しさん
20/06/24 02:39:07 gVxDDgwX.net
今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな
85:デフォルトの名無しさん
20/06/24 03:02:02.88 irp07WaX.net
>>81
匿名性のSNSの限界。
記名性だと色々と能力が分かって、無視される。
86:デフォルトの名無しさん
20/06/24 04:52:29.63 evfa9tXu.net
>>76
何がいいたいのか全くわからん。
例えばお前が言ってる頭の悪いやつが、
ローカル変数をグローバル変数に変えるかもしれんよな？
そういう場合、なんだっていうんだ？
ローカル変数が悪いって話をしてるのか？
それを止められないからローカル変数は邪魔といいたいのか？
87:デフォルトの名無しさん
20/06/24 07:20:27.23 ib1NZqNH.net
>>84
まあ、しょうがねぇよなって話じゃん
88:デフォルトの名無しさん
20/06/24 07:21:13.77 ib1NZqNH.net
初めの書き手が悪いんじゃなくてあくまで変更したやつの責任
89:デフォルトの名無しさん
20/06/24 12:20:09.25 irp07WaX.net
>>76
というか、MFCみたいに修正が推奨されて無い場合は
90:除いて、 自社開発のプログラムであれば、能力がある人にはあなたが修正するのを 上司が許可してくれると思うんだ。 もし、修正を許可してもらえないなら、実績が足りて無いか能力のアピールが足りてない。
91:デフォルトの名無しさん
20/06/24 12:31:25.83 bZ0w8eld.net
オブジェクト指向の肝は擬人化と依頼だからな
頼む相手の内部状態を勝手に変えないってのは
無茶重要でしょ
92:デフォルトの名無しさん
20/06/24 13:17:22 U8BVWvkL.net
>>88
>オブジェクト指向の肝は擬人化と依頼だからな
初めて聞いた
93:デフォルトの名無しさん
20/06/24 13:54:42 bZ0w8eld.net
擬人化キャラ（クラス）の関係性で物語を生成する＝オブジェクト指向
そんなかんじで習ってそのまま理解してたな ちなみに学校は恥ずかしくて
言えないような底辺学校
94:デフォルトの名無しさん
20/06/24 14:29:54 +bJy5A36.net
依頼はどことなく委譲って分かるけど擬人化はただのスケベじゃん
95:デフォルトの名無しさん
20/06/24 14:40:07.82 bZ0w8eld.net
>>91
頭わるくてまともな学校にいけない奴らに
教えるために先生が工夫してくれたんだろうね 依頼ってのも困ったら
依存心の高い奴らに教えるのにそういう言い回ししたんだろうね
いま思えばなかなか立派な先生だったな 口は臭かったが
96:デフォルトの名無しさん
20/06/24 15:16:35.37 W7e3ICMc.net
>>92
分かりやすく噛み砕いて教える方法としては良いと思うけど、>>88のように一般的に通じるつもりでいきなり独自用語を使うと話が変な方にいくから、不特定多数を相手にするときは一般的な用語を使った方がいいぞ。
97:デフォルトの名無しさん
20/06/24 16:47:31.01 ZBvJ9IFx.net
>>91
本来人間相手にしかに使わない依頼や委譲って言葉を使ってる時点で擬人化してる
98:デフォルトの名無しさん
20/06/24 16:51:31 ZBvJ9IFx.net
擬人化と依頼のメタファは一般的
オブジェクト指向に限らないけどOOを説明する際によく使われたから
Tell Don’t Ask
URLﾘﾝｸ(media.pragprog.com)
URLﾘﾝｸ(martinfowler.com)
99:デフォルトの名無しさん
20/06/24 19:00:14.27 z1f+Mb2g.net
>>76
> お前らの言う頭の悪い奴は元のクラスのprivateを
> publicに変えるかもしれないし
> Personというクラスの隣に
> Person2と言うクラスを複製してそっちの方をpublicに
> 変えて利用するかもしれない。
ねーよw
もう少し基礎知識学んでから出直してこい。
まず、ライブラリの中身を書き換えること自体、ありえない。
たぶん、見ず知らずの人達が書いたコードを共有する仕組みから知らないのだろう。
100:デフォルトの名無しさん
20/06/24 19:25:00 vlqGopWc.net
>>96
いや、そもそもできちゃうじゃん
そして別にできてもいいじゃん
それが嫌だとしたらそれをドキュメントに書いとけよ
ソースには書けないし書いても消せるからさ
101:デフォルトの名無しさん
20/06/24 19:30:57 6CkV8gwI.net
>>96
いや、周囲や協力会社(依頼元クライアント側プログラマ)
にこれやるやつゴロゴロいるんだって
ソースファイルでもテーブルでも何でも他人が書いたやつ
複製して仕様変更に対応するんだわ。
privateとかカプセル化なんて笑っちまうよマジで
でも意外と何とかなってる、複製したあとはレガシーコードは
全部捨てちまうんだわ
職場で新人研修で「抽象クラスって何のために作るんですか？」
って毎回のように訊かれるけど
「俺にも分からない。必要性を感じたことも、便利だと思った
事も無い。」って正直に答えてる。
オブジェクト指向の入門書に当然のようにabstract紹介
されてるけどそれの有用性を的確に説明している
教科書を見たことがない
interfaceのほうは重要性は分かるしちゃんと説明している
102:デフォルトの名無しさん
20/06/24 19:4
103:2:39 ID:J59L1bOF.net
104:デフォルトの名無しさん
20/06/24 19:53:36 GEcMOOIw.net
>>75
これだろ
URLﾘﾝｸ(ja.m.wikipedia.org)モデル
DARPAモデルとは、インターネットの持つべき通信機能を階層構造に分割したモデルである。
アプリケーション層、トランスポート層、インターネット層、ネットワーク層の4層で構成される。
DARPAモデルという呼称は、インターネットの研究開発を行っていたDARPAに由来する。
元々は確固たる仕様や定義はなく、IPやTCPやUDPなどの仕様中に個々に、あるいは暗黙の前提として存在していたものだが、後からRFC 1122で1つにまとめられた。
IP群はプロトコルとサービスをカプセル化する事によって抽象化する。
通常、より上位層のプロトコルはその目的の達成に役立てるために、より下位層のプロトコルを用いる。
これまでIETFはインターネット・プロトコル・スタックをRFC 1122で定義された4層から変更した事はない。
IETFは7層からなるOSI参照モデルに従うような試みはせず、また標準化過程（Standards Track）にあるプロトコル仕様やその他の構造上の文書をOSI参照モデルに対して参照する事もしない。
URLﾘﾝｸ(ja.m.wikipedia.org)
RFC 3439では、インターネット構造に関して第3章の序文に"Layering Considered Harmful （階層化の有害性）"と題された節が有り、
「階層化」という考え方が概念的および構造的にさまざまな利点を持っているが、
実装面では層単位で同じような最適化が繰り返し発生することによる無駄な処理により効率的な実装を阻害し、複雑化を招くことがあり、
また低層部分のみに存在するデータにアクセスできない場面が発生するなど、
インターネット・プロトコルの目指す「単純化」という原則に反することもあることが明記された。
105:デフォルトの名無しさん
20/06/24 20:04:30.89 GEcMOOIw.net
>>75
ググったら日本語訳もあった
URLﾘﾝｸ(www5d.biglobe.ne.jp)
106:デフォルトの名無しさん
20/06/24 21:01:40.99 7L466iYI.net
>>98
抽象クラスは単なるテンプレ
クラスを作る際の約束事を規定できる
具体的には実装忘れやメソッド名を間違えるのを防げる
自分のような忘れぽい人間には役立つ
107:デフォルトの名無しさん
20/06/24 22:26:02.81 z1f+Mb2g.net
>>98
> 「俺にも分からない。必要性を感じたことも、便利だと思った事も無い。」って正直に答えてる。
正直なのはいいけど...なんで、privateの有効性がわからないのに、カプセル化を批判するのか。
無知の批判ほど、初心者が誤解を生む原因になるからやめてほしい。
例えばだよ。
何の言語をよく使うのか不明だが...標準ライブラリってあるじゃん？
その標準ライブラリのクラスに「呼び出したら破綻する(内部処理実装用の)メソッドや変数」が定義されていたら、どうする？
クラスを使う人に呼び出してほしくない機能はprivateにするべきでしょ。
実装する側の都合だけじゃなくて、クラスを使うユーザーのことも配慮して使うものだよ。
OOPアンチとOOP活用者の絶対的な違いは自作したクラスを使う人のことを深く考えているかどうか。そこだよ。
108:デフォルトの名無しさん
20/06/24 22:30:44.22 MQA513Hf.net
>>103
使う側と作る側が完全に分離した環境に当たったことがない
win32apiや.netframeworkを作る人以外にそんな需要ってあるの？
109:デフォルトの名無しさん
20/06/24 22:31:32.44 evfa9tXu.net
>>104
win32apiや.netframeworkを作る人には需要があるって認めたの？
110:デフォルトの名無しさん
20/06/24 22:32:45.63 z1f+Mb2g.net
って、わからないのは抽象クラスかいッ！
なんか、アンカを間違えたような間違えていないような微妙な回答をしてしまった...。
まぁ、抽象クラスは>>102に書かれている通りって事で。
111:デフォルトの名無しさん
20/06/24 22:34:51.23 MQA513Hf.net
>>105
俺が作るならいらん
状態をクラスのインスタンスが内部に保持してしまうのは害にしかならない
112:デフォルトの名無しさん
20/06/24 22:42:26.10 MQA513Hf.net
なんか今までノリでクラスで作ってきたのを止めると物凄くスキルアップするぜ
一度はオブジェクト指向をやってみるのもいいかもなってのは思う
クラス構造で便利なものとそうでないものは当然ながらこの世にはあって
そのほとんどが実はクラスにしないほうがうまくいくものばかりだ
大半の処理は
入力→処理→出力
の繰り返しであってこれのまとまりが
機能となる
ただ極稀にクラス構造で考えた方が便利な構造のものもある
役に立つのはその時だけだ
そしてそのケースは極めて稀である
113:デフォルトの名無しさん
20/06/24 22:43:14.13 z1f+Mb2g.net
>>104
.netは勿論、Android、iOSネイティブ、バックエンド node.jsやPython、mbed(組み込み)、
まぁ、一部private機能をサポートしていない環境はあるけど、作る側・使う側の意識は常に持つよ。
.netを知っているってことは、Nugetのことは知っていると思うけど...
gradleとか、npmとか、github等と連携させて他人の作ったライブラリの自動追加及びアップデートの仕組みはいくらでもある。
てか、自分で作ったコードですら、作る側・使う側は意識するよ。
過去に作った自分のソースなんて、他人が作ったソースみたいなものだし。
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。
114:デフォルトの名無しさん
20/06/24 22:44:48.06 evfa9tXu.net
>>107
> 俺が作るならいらん
つまり、俺が作らないなら、必要だって言ったのと同じことだよね
115:デフォルトの名無しさん
20/06/24 22:47:38.19 evfa9tXu.net
最初からオブジェクト指向は大規模なものを
複数の人で作るためのもので
それをわかってないから、
「俺が一人で作るようなものならいらん」
なんて発言が出てしまうんだよな
116:デフォルトの名無しさん
20/06/24 22:52:50.78 7L466iYI.net
>>109
内部実装を理解していないと使えないソースなんて使いこなせるほど俺の頭はよくないよ。
まあこれだよね
頭いいやつには必要ない技術かもね 凡人には必須だとおもうけどな
あと設計思想とかそんな面倒な話じゃなくてシンプルに補完ができるのが楽
117:デフォルトの名無しさん
20/06/24 22:54:20.40 VGKuFIs7.net
>>107
内部に保持するのが良いとは言わんが外部に公開すれば良いってもんでも無いでしょ
いつ何時外部から状態が変更されても破綻しないように責任持てと言われても
僕は頭が悪いから無理です
118:デフォルトの名無しさん
20/06/24 22:55:53.79 evfa9tXu.net
そもそもprivateっていうのはコミュニケーションの道具で
privateって書いていなければ、好き放題アクセスしてOKという意味に
捉えられるかもしれないわけだ。
コメントの高度版なのだからコメントなくてもできるのは当たり前
だがそうすると修正が難しくなる
俺が作るなら～っていうのはコミュニケーションが
必要ないから言える話
119:デフォルトの名無しさん
20/06/24 22:58:49.48 z1f+Mb2g.net
>>112
まぁ、そうだな。
ただ、面白いのが...
頭のいい人がOOPに漬かると、余裕ができた分、コンピューターの仕組みにとらわれずエンドユーザーの事を全力で配慮した品質の高い製品を作れるようになる。
120:デフォルトの名無しさん
20/06/24 22:59:48.33 z1f+Mb2g.net
アンカまた間違えた...
121:デフォルトの名無しさん
20/06/24 23:00:40.93 z1f+Mb2g.net
間違えてなかった。もうダメだ...
122:デフォルトの名無しさん
20/06/24 23:26:13.24 MQA513Hf.net
>>113
構造体でまるっと渡してやるよ
123:デフォルトの名無しさん
20/06/24 23:27:50.80 MQA513Hf.net
>>111
逆だな
デカければでかいほどオブジェクト指向で組むのはやめた方がいい
内部の状態遷移を誰も理解できない
124:デフォルトの名無しさん
20/06/24 23:31:43.79 MQA513Hf.net
そもそもさ
クラスで状態を保持するソースってさ
実装全部見て
何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
これが最高にダルイ
もう年取ったしこんなの付き合ってらんない面倒臭くて
125:デフォルトの名無しさん
20/06/24 23:32:23.15 fkg3GZzF.net
単なるモジュール切り離しのための技術の一つだよ。
バカが騒ぎまくったせいでクソみたいなインターフェイスによる切り離しで
逆に見通しが悪くなることが多くなった。
細かい粒度で使うような技術じゃない。
126:デフォルトの名無しさん
20/06/24 23:41:46.40 MQA513Hf.net
>>121
いや、単純に面倒臭いだけでメリット皆無じゃん
127:デフォルトの名無しさん
20/06/25 00:13:01.48 JeYxH76v.net
内部に状態変数をもたれたらグローバル変数の比ではないほど厄介。
単体テストやデバッグが壮大なことになる。
128:デフォルトの名無しさん
20/06/25 00:16:04.75 JeYxH76v.net
「状態によって挙動が変わる」ものが何十個も何百個も集まったら誰も把握しきれない。誰も制御しきれない。
129:デフォルトの名無しさん
20/06/25 01:13:10.51 h5MGZkZK.net
>>119
>内部の状態遷移を誰も理解できない
使う側は内部の状態遷移なんて理解する必要ない
理解しないと使えないようならその設計が悪い
130:デフォルトの名無しさん
20/06/25 01:41:45 Q34w5rfS.net
内包してる初期化フラグ一つで
全く同じ入力に対して全く異なる出力が出てくるんだから
こいつは厄介だよ
勘がいいやつはこれだけでこの仕組みを使わない
131:デフォルトの名無しさん
20/06/25 03:09:24.52 9YSX2wtH.net
>>124
だからオブジェクト指向で小さくするんだよね
132:デフォルトの名無しさん
20/06/25 03:13:43.10 AD4h9H61.net
>>110 君頭悪いねってよく言われない?
133:デフォルトの名無しさん
20/06/25 03:15:57.10 9YSX2wtH.net
>>128
言われない。むしろお前のほうが言われてるだろ。
134:デフォルトの名無しさん
20/06/25 04:09:57.03 3STWDldz.net
お前ら頭悪いね
135:デフォルトの名無しさん
20/06/25 05:35:58 AD4h9H61.net
レス番まで指摘されても自分のおかしい発言に気づけないとはいとあはれ
136:デフォルトの名無しさん
20/06/25 05:40:21 hNcIaCHg.net
いいぞ、もっとやれ
137:デフォルトの名無しさん
20/06/25 07:10:48 MncJLzSh.net
内部を知る必要ない。インターフェースだけ守れ
138:デフォルトの名無しさん
20/06/25 07:22:24.62 /bWSJldt.net
彡 ⌒ ミ
(´・ω・`) 頭がなんだって？
139:デフォルトの名無しさん
20/06/25 07:30:13.69 p+gLKGcc.net
>>122
めんどくさくて新しい(もう20年以上前からメジャーではあるが...)考え方についていけません、てだけだろw
お前が懸念している内部の状態遷移が見えないというのは、見えなくていいように作り、見えなくていい部分だけを隠すんだよ。
お前の大好きな従来の手続き型だって、下手に作れば手続きを呼び出す順序や渡すべきデータの構造や内容が訳分からない複雑なものになるだろう。
単に自分の知ってる手法では良い
140:設計を知っていて問題点を避けられる、よく知らない手法は問題を回避する方法がわからなくて問題のある手法と思えてしまう、ただそれだけのこと。
141:デフォルトの名無しさん
20/06/25 07:32:40.30 U43KJZDw.net
クラスの状態はクラスが知ってれば良い
という思想なんじゃねえの？
オブジェクト指向は？
142:デフォルトの名無しさん
20/06/25 07:35:44.39 Q34w5rfS.net
>>136
テストするんですが～
143:デフォルトの名無しさん
20/06/25 07:53:57.86 Q34w5rfS.net
>>135
違うだろ
内部の状態が見えないのにテストなんかできないだろ
そのクラス使ってある限りそいつの状態次第で色んな動作しちまうんだから
はっきり言ってクラスは欠陥製品
特に内部に状態を保持するような使い方は害悪
144:デフォルトの名無しさん
20/06/25 08:19:04.16 p+gLKGcc.net
>>138
お前はオブジェクトの状態として、外部に影響�
145:^える外部仕様の状態と、外部に影響を与えない内部仕様としての状態を混同してないか？ 文字列のオブジェクトが文字列"abcd"を持つとして、それは外部に影響を与えるものだから、privateのメンバとして保持されていようがテストケースとしてそれを与えて状態を設定してテストすればいい。 一方、その文字列がどういう実装で保持されているか、ヒープなのか固定配列なのか、参照カウンタやさらに複雑な仕組みを使っているのかといった内部仕様的な状態は、このクラスを他と組み合わせてテストする段階ではテストする必要がない。こういう部分は、先にクラス単体のテストで保証しておけば良い。 そういう切り分けができない作りになっているなら、それは設計が悪い。
146:デフォルトの名無しさん
20/06/25 08:42:04.56 Q34w5rfS.net
>>139
いや、MSのクラスだってなんかよくわからん動作するのあるし
いいとか悪いとかじゃなくて状態を保持したら地獄行き
覚えといてね
147:デフォルトの名無しさん
20/06/25 08:57:56 rghIsJSV.net
>>122
めんどくさいのはその通り。
テスト駆動開発の本とか読んでどういうオブジェクトを引数にすると
テストしやすいかが理解できてくるとありがたさがわかってくる。
オブジェクト設計とか言い出す馬鹿は無視しろ。
148:デフォルトの名無しさん
20/06/25 08:58:07 XTsRyKlX.net
>>120
> そもそもさ
> クラスで状態を保持するソースってさ
> 実装全部見て
> 何やるとどう状態遷移が起こるのか把握しないと使えないじゃん
> これが最高にダルイ
> もう年取ったしこんなの付き合ってらんない面倒臭くて
だ、か、ら、
それを解決するためのオブジェクト指向だ つってんだろ！
クラスをオブジェクト指向も意識せずに、ただただ構造体みたいに実装して使うから、そうなるんだよ。
149:デフォルトの名無しさん
20/06/25 09:10:36 p+gLKGcc.net
>>140
どのクラスを指して言ってるのか知らないが、それはそのクラスの仕様自体の複雑さかお前の理解不足が原因で正しい挙動が分かってないとか未定義動作をさせているとかでないの？
状態を保持するのが問題なのではなく、知っておくべき状態、情報を知らずに上手くいかないのをオブジェクト指向のせいにしているだけのように見えるぞ。
150:デフォルトの名無しさん
20/06/25 09:17:11.38 rghIsJSV.net
状態をできるかぎり持たない方がいいってのはその通り。
ただ通信ソケットみたいなもの実装しようとすればどうしても状態を持つわな。
コネクション張るオーバーヘッドが小さくない時点で、性能出そうと思えば状態をもつしかないので。
151:デフォルトの名無しさん
20/06/25 09:21:43.95 H2Spozu7.net
オブジェクト指向って設計手法であると同時に
責任の切り分け手法でもあるんだよね 別の共同体（無償で手伝う気なしって意味で）
と作業する場合は必須でしょ
152:デフォルトの名無しさん
20/06/25 10:04:43.33 Q34w5rfS.net
>>142
は？メソッド全部staticにしてみろ
大半の問題が解決する
153:デフォルトの名無しさん
20/06/25 10:09:16 XTsRyKlX.net
>>146
解決しねーよ！むしろ、問題が多発するわ！
それ以前に、何の問題が解決するんだよ。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
1366日前に更新/316 KB
担当:undef