カプセル化は愚かな考え

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/07/29(水) 17:17:58.13ID:u638n5uE
■危険性

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

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

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

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

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

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/07/29(水) 17:27:31.45ID:27/LTGZ1
>>15
XNAというマイクロソフトの天才たちが推し進めたプロジェクトでも失敗しているという事例だし、凡人だったらもっと悲惨なことになる。
2020/07/29(水) 17:28:38.45ID:Vqlry5vz
おっそろしーなぁ
18デフォルトの名無しさん
垢版 |
2020/07/29(水) 17:28:52.07ID:uvei7tHN
オブジェクト思考って何？
誰か説明して
2020/07/29(水) 17:29:11.35ID:VfBPeHSy
オブジェクト原理主義者のコードを引き継ぐ事になった時の絶望感は異常
2020/07/29(水) 17:29:25.85ID:zsp+8xMC
「カプセル化は悪」「カプセル化はオブジェクト指向ではない」というのがやっと広まりだした。
2020/07/29(水) 17:29:41.38ID:zsp+8xMC
ようするに「仕様変更の恐ろしさは異常」
2020/07/29(水) 17:29:50.61ID:zsp+8xMC
未来予測できるが勝負所
2020/07/29(水) 17:30:12.05ID:i3uBuM+c
カプセル化は隠蔽体質ってことですね
2020/07/29(水) 17:30:38.36ID:pqaZ9+7I
>>15
XNA作ったマイクロソフトの超エリートたちですら設計ミスをするくらいオブジェクト指向は難しい。
2020/07/29(水) 17:31:42.76ID:fVVDTdgK
組み込みだと細分化し過ぎるんじゃね？
業務システムで細分化することはまずない。
2020/07/29(水) 17:32:08.32ID:IWquYLz9
業務システムだとDBいじくるだけだから深い階層構造に関わることはまずないだろ。
DBというグローバル変数をクラスという名の構造体にコピーして、編集して、書き戻すという単純作業の繰り返し。
2020/07/29(水) 17:32:50.34ID:a9P4jhh/
結論：privateにしたら、必ずgetterを用意しておきましょう。
2020/07/29(水) 17:33:09.46ID:FJzf6su8
小規模なら問題ない
2020/07/29(水) 17:33:58.47ID:I4F+YKTC
今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな
2020/07/29(水) 17:35:05.46ID:futNIK+y
RFC 3439では、インターネット構造に関して第3章の序文に"Layering Considered Harmful （階層化の有害性）"と題された節が有り、
「階層化」という考え方が概念的および構造的にさまざまな利点を持っているが、
実装面では層単位で同じような最適化が繰り返し発生することによる無駄な処理により効率的な実装を阻害し、複雑化を招くことがあり、
また低層部分のみに存在するデータにアクセスできない場面が発生するなど、

インターネット・プロトコルの目指す「単純化」という原則に反する

https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:UDP_encapsulation.svg
2020/07/29(水) 17:36:12.77ID:B9GAbJCb
メソッド全部staticにしてみろ
大半の問題が解決する
2020/07/29(水) 17:37:47.33ID:JqP21Wkx
> オブジェクト指向の発案者であるアラン・ケイもコーディング規約
> （頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、

それがprivateでは？
2020/07/29(水) 23:07:46.03ID:mVFqEUCw
>>32
名前でprivate感を出すだけにしておくって話だと
2020/07/30(木) 03:10:51.58ID:oWxKF5YB
>>33
それはprivateと何が違うの？
2020/07/30(木) 09:06:15.43ID:aMAEXQwY
カプセル化が悪いというより、カプセル化にこだわる奴が不適切なカプセル化を認めないところが問題。
2020/07/30(木) 12:31:37.82ID:9/rdfAc6
不適切なカプセル化とは？
アランケイも言っていた、privateはアンダースコアをつけるだけでいいと
つまりprivateでもアクセス可能にしておくのが良いということで
privateでもアクセスしていいということ

ならprivateにアクセスする手段がある言語であれば
アランケイの名前で明示するやり方よりも良い手段であるということだよ。
2020/07/30(木) 14:37:49.17ID:xP/66ZtT
>>36
pythonがこれなんだっけか
2020/07/30(木) 15:15:07.17ID:vOSCVC8M
>>2
それをラップするモデルを作るんだよ。場当たり的な対応をするからそんなことになる。
39デフォルトの名無しさん
垢版 |
2020/07/30(木) 18:15:34.88ID:5sWEm17U
>>38
その例だと低層からのデータを捨て去ってるわけで、
ラップしても破棄されたデータは復元できない。

破棄しないように作り直すしかない。
2020/07/30(木) 20:00:50.45ID:DFjeaZjZ
>>37
実例たのむ
41デフォルトの名無しさん
垢版 |
2020/07/30(木) 23:26:02.54ID:2DU34DEY
>>40
実例も糞もpythonにはprivateもpublicもない。
すべて暗黙でpublic
2020/07/31(金) 00:07:26.39ID:erqiTFyu
結局の所、privateはあってもいいけど
呼び出したらエラーになるんじゃなくて
ワーニングレベルで良かったって話よね？

テストコード以外から呼んだらワーニングにすればよかった。
そういう言語があると良いね。
43デフォルトの名無しさん
垢版 |
2020/07/31(金) 00:28:49.58ID:yu65eNBx
キミ戦争を英語で何て言う？
え？ウォー？
warをウォーって読むのになんでwarnはワーンって読むのｗｗｗｳﾜｰﾝってかｗｗｗｗ
バカじゃないのｗｗｗｗｗ
2020/07/31(金) 07:42:46.79ID:0J+iX777
ばかはどんな言語機能を用意しても糞な変更したり、普通の変更がしずらい構造にしたりするんだから無意味。
言語機能の問題じゃない。
2020/07/31(金) 09:29:19.53ID:NLy05HSt
>>44
バカの問題と技術の問題は分けて考えましょう
2020/07/31(金) 09:40:25.98ID:ZHQKI64e
>>39
捨てられるデーターを保持しといて、それをカプセル化したらいいんではないの？
2020/07/31(金) 09:41:42.18ID:ZHQKI64e
リファクタリングで困りますよ
2020/07/31(金) 12:51:05.01ID:0J+iX777
>>45
いつでも簡単に分けられると思ってるのはバカですね。
2020/07/31(金) 15:37:48.30ID:KVBY0ZED
>>43
Rの発音はカタカナ表記できないから一概にどちらが正しいというものでもない

warのrの発音を無理やり表記するとウォァに近くこれを縮めてワーにしてるだけ
warningもウォーニングよりもゥォアーニングやゥワーニングのほうが実際の発音に近い
ワープやワランティも同じで日本語カタカナ表記として定着してる

「ワープww バカじゃないのw ウォープだろwww」って書いてるやつ見たら痛いよね？
2020/07/31(金) 17:06:17.60ID:k/mzlDiC
>>48
「いつでも簡単に分けられる」なんて言ってないですね
そう思ったのはお前ですね
2020/07/31(金) 18:59:54.64ID:XB3+uQxn
>>43みたいなバカって義務教育終えてないんじゃないの
52デフォルトの名無しさん
垢版 |
2020/07/31(金) 19:05:26.84ID:Q7hjdc7P
>>49
英語音痴が恥の上塗りで口から出任せ乙ｗｗｗ
warnの発音調べてみろよｗ
会社でそんな恥ずかしい低学歴芸披露して恥かかないようになｗ
You were warned(警告はした)ｗｗｗｗｗ
わーんｗｗｗわーんどｗｗｗｗわーにんぐｗｗｗｗｗハラ痛いｗｗｗｗｗｗ
2020/07/31(金) 20:44:23.24ID:jclw2i1e
うぉ〜ん
2020/07/31(金) 20:48:02.23ID:4XHNop85
平置きバカが発狂しちゃってんの？
55デフォルトの名無しさん
垢版 |
2020/07/31(金) 21:55:19.86ID:yu65eNBx
ワープ
https://ja.m.wikipedia.org/wiki/%E3%83%AF%E3%83%BC%E3%83%97
英語の発音としては、「戦争」の「ウォー」と同じで、カタカナでは「ウォープ」とするのが近いが、日本の初期のSFで「ワープ」と書かれたうえ、『宇宙戦艦ヤマト』で一般にも広く「ワープ」で定着した。

ウォーニング
https://ja.m.wikipedia.org/wiki/%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0
ウィキメディアの曖昧さ回避ページ
ウォーニング（英語: warning、英語発音: ['wɔːɹnɪŋ] ）
・警告、警戒
・警報
・訓戒、戒め
・ウォーニング (曲) - グリーン・デイの2000年のシングル曲。
・ウォーニング (アルバム) - グリーン・デイの6thアルバム。
・ウォーニング (競走馬) - イギリスの競走馬。
・WARNING (いしだ壱成の曲) - いしだ壱成の1994年のシングル曲。
・WARNING (アルバム) - mochAのアルバム。

ワーニング
https://mevius.5ch.net/test/read.cgi/tech/1596010678/42
英語の発音としては、「戦争」の「ウォー」と同じで、カタカナでは「ウォーニング」とするのが近いが、日本の低学歴のレスで「ワーニング」と書かれたうえ、恥の上塗りで『warのrの発音を無理やり表記するとウォァに近くこれを縮めてワーにしてるだけ
warningもウォーニングよりもゥォアーニングやゥワーニングのほうが実際の発音に近い』と発音記号も読めない低脳を晒し、同調した低学歴に広く「ワーニング」で定着した。
2020/07/31(金) 21:58:35.21ID:k/mzlDiC
ビニールテープは間違い
バイニルテープ、バイニル袋が正しい
2020/07/31(金) 22:46:03.90ID:KVBY0ZED
>>55
カタカナ英語にこだわるのは自分が発音できない裏返し
カタカナに頼ってたらwalking(ウォーキング)とwarning(ウォーニング)のウォーを使い分けられないよ

学歴コンプこじらせるのもほどほどにね
2020/07/31(金) 23:20:28.75ID:28gnV4mI
カプセル化はいいとして
なんでもかんでもセッターゲッター作るバカの方が痛いわ
2020/07/31(金) 23:25:53.90ID:gJoK1c/t
セッターゲッターしか駄目な点を指摘できないんだね
2020/07/31(金) 23:41:42.59ID:C75u5On2
セッターとゲッターは存在自体がカプセル化を否定してるよな
カプセルに閉じ込めて入口と出口をイベントに絞ったんじゃねーのかよと
オブジェクト指向の目指すものがよくわからない
はじめの思想はともかく矛盾を承知で次の形態へ変化したと言うならそれでもいいとは思うけどね

ただ、言語作ってる奴さ
どんな設計書からどんなソースを作成したいのか？またそれをどうやってテストするのか？そろそろシームレスに真面目に考えるときじゃね？
最近追加で増える機能に思想を感じない
控えめに言って俺よりバカが便所で思い付いたようなアイデアを検証も無しに追加してる気がする
2020/08/01(土) 01:27:20.73ID:lS0R4ljb
カプセル化はデータと処理を分離させないためのものなのに、昔の説明をいまだに信じ込んで、データの参照もメソッド経由でないとカプセル化になっていないと言う30代、40代がいる。オラクル社のJavaの資格でも取り直した方がいい。一部は考え方が誤っていたから、いまは変な理想や思想は教えていない。むしろ、いまでは失敗だったとして否定されている部分も多い。
62デフォルトの名無しさん
垢版 |
2020/08/01(土) 01:27:30.68ID:lS0R4ljb
テスト
63デフォルトの名無しさん
垢版 |
2020/08/01(土) 01:39:18.16ID:JfG80/LC
不具合が起こる根本的な要因を理解していないとカプセル化の効果を得る事は出来ないと思う
解らない人はゲッターセッターを使ってやるほうが有る意味おかしくならないからそれはそれで良いと思う
効果が有るようにオブジェクト指向でプログラムするのは難しいから
中途半端にカプセルかするより従来みたいにしているほうが良い
解らない人は無理せずに行制御basicでもやったほうが良いかも
そんな感じ
2020/08/01(土) 02:01:30.20ID:5v4lbbZK
まあ、設計的にはイベントというかメッセージ以外のアクセスを許さないためのカプセル化だろ？
セッターとかゲッターで横紙破りしちゃったらカプセルにならねーじゃん
だからセッターとかゲッター、プロパティまたそれを宛てにした機能全般は初期の思想からは大分ズレてんなと思う
カプセルなってねぇじゃんと

俺自体はpublic、staticメソッドのみが正義なのでカプセル化なんてどうでもいいし意識することもないけど
65デフォルトの名無しさん
垢版 |
2020/08/01(土) 04:47:59.20ID:hADlV/rS
カプセルはまとめるという意味だったのに、中に閉じ飲めるという意味だと誤解したんだよね。
2020/08/01(土) 07:23:51.46ID:tIIJOG0C
>>65
いや、誤解やないやろｗ
2020/08/01(土) 08:03:35.26ID:1RFWToyV
> セッターとかゲッターで横紙破りしちゃったらカプセルにならねーじゃん

ならねーとまでではないんだろうし
実際教科書ではむしろカプセル化のためにアクセッサ書かせるくらいなんじゃないのかな

でもね、そのアナタの感性はすごくいいと思う
俺もアクセッサ前提の設計はまちがってると思う
カプセル化として間違ってるというより
インタフェースとして型を決めていくのが前提で
内部の実装に引きずられてアクセッサつくっちゃうのは
ホンマまじで脳腐ってると思う
2020/08/01(土) 08:21:19.99ID:Lj3Owie1
まあ、思想的にはそうではあるけど
機能的に書かねぇとそもそも実装できないようなのあるから
ここ今更主張してもしょうがないんだけどね
でも、方向としておかしいのはおかしいのだと思う
69デフォルトの名無しさん
垢版 |
2020/08/01(土) 09:52:11.60ID:cVk77Hxz
>>57
warn
[wˈɔɚn] (米国英語)
[wˈɔːn] (英国英語)
war
[wˈɔɚ] (米国英語)
[wˈɔː] (英国英語)

同じ発音 [ɔ] なのにwarnではア、warではオと使い分けてしまう低学歴ｗｗｗ
2020/08/01(土) 11:12:33.20ID:eqNnh4Zw
>>60
> セッターとゲッターは存在自体がカプセル化を否定してるよな
> カプセルに閉じ込めて入口と出口をイベントに絞ったんじゃねーのかよと

お前が、すべてのprivateフィールドにセッターとゲッターを作り、
そのセッターとゲッターにははただ値を転送するだけにしてるってのはわかった
お前が間違ってる
2020/08/01(土) 11:13:25.31ID:eqNnh4Zw
>>64
セッターとゲッターは必要なものだけ作るんだよ？
ちょっと頭悪すぎないかｗ
2020/08/01(土) 11:56:21.68ID:pnZUr/MU
>>71
あ、いや、そもそも汎用的な出入り口を作っちゃ駄目っしょ
って話
だからどのプロパティがじゃなくて
イベントに対して引数からアクセスさせる以外の方法はそもそもカプセル化じゃないよねってだけ
別に原理主義者出ないのでそれで回らなくなったんじゃない？ってならそれも時代の流れだと思うよ俺は
2020/08/01(土) 12:25:27.95ID:biQ1QRTH
医者が出すのは処方箋
薬💊の調合は薬剤師
患者は中身を弄る必要無いってだけ
2020/08/01(土) 12:32:19.22ID:6s9LN6+z
>>72
> イベントに対して引数からアクセスさせる以外の方法はそもそもカプセル化じゃないよねってだけ
どういう理屈？ｗ

引数があるメソッドはすべてカプセル化じゃないって言ってるの？
引数があるメソッドは、セッターとゲッターだけじゃないよ
2020/08/01(土) 12:38:28.44ID:6s9LN6+z
クラスの中のすべてのprivateフィールドは間接的に値を代入することが出来る

setFoo(int foo) {
　_foo=foo;
}
というセッターはカプセル化じゃないというのなら

setFooBar(int foo, int bar) {
　_foo=foo;
　_bar=bar;
}
というメソッドであればカプセル化になってるとでも言うつもりだろうか？

それとも名前が行けないとでも言うつもりだろうかね

initialize(int foo, int bar) {
　_foo=foo;
　_bar=bar;
}
これならOKとか？ｗ

カプセル化の本質がわかってないから、セッターとゲッター（だけ）に問題があると思ってしまっている。
「問題」はそこではなく、その「問題」の影響がなければセッターやゲッターがだめな理由はない
2020/08/01(土) 12:39:33.47ID:+e9G5Uqi
>>74
え？ちょっとお前頭悪いから話したくないわｗ
2020/08/01(土) 12:41:39.77ID:6s9LN6+z
>>72のように
メソッド単位で「このメソッドはカプセル化じゃない」というような
言い方をしている人はカプセル化を理解してない

カプセル化はオブジェクト単位で考えるもの

何か（薬など）を包んでいる入れ物がカプセルなのであって
入れ物に出し入れする穴がカプセルなのではない
2020/08/01(土) 12:41:58.50ID:6s9LN6+z
>>76
反論できない人はさようなら
2020/08/01(土) 12:45:35.11ID:6s9LN6+z
カプセルにどれだけ穴（メソッド）が空いていようが、カプセルの意味がある

メソッド経由でしかアクセスできないことが保証されているからだ
80デフォルトの名無しさん
垢版 |
2020/08/01(土) 13:28:33.15ID:biQ1QRTH
全面穴だらけのカプセルならもうそれ粉薬で良いんちゃうw
81デフォルトの名無しさん
垢版 |
2020/08/01(土) 14:04:15.81ID:hADlV/rS
値の参照についてはメソッドでの値の取得にはしないともう結論は出ていて、いまは不毛なメソッドは作らない。
2020/08/01(土) 14:05:07.09ID:GK6vh4b0
>>80
はい。そういうことなんですがなにか？

「全面穴だらけ」
これこそがカプセル化の否定の条件だろ

間違い ゲッターセッターがある（穴がある） 故にカプセルじゃない
正しい 全面穴だらけ。故にカプセルじゃない

「アクセスしてはいけないもの」に「アクセスできる」なら
それはカプセル化を破壊していることになる。条件はこの2つでしかない。
この2つの条件を両方同時に満たしていないならカプセル化の破壊にはならない
ゲッターセッター関係ないんですよ
2020/08/01(土) 14:12:41.19ID:htNB4Xat
ハイ論破ッ！！！
2020/08/01(土) 14:37:54.28ID:mnCw/PCI
どんな値でも代入していいし取得してもいいのに
それをpublicにしたらカプセル化破壊とか
ゲッターセッターを作ったらカプセル化破壊とか
ちゃんちゃらおかしいわけですよ
インターフェースの定義が「どんな値でも代入していいし取得してもいい」なんだから
どんな値でも代入していいし取得してもいいんです。
2020/08/01(土) 15:36:05.13ID:zOYkYoe2
初期化の時点で定数扱いするとか、stateパターンみたいなことやるとか、
今時はセッター用意しない方向だわな。
テスト作成がめんどい時はセッターもありだと思ってるけど。
86デフォルトの名無しさん
垢版 |
2020/08/01(土) 20:23:54.58ID:XDmb1Dov
たとえばこのようにカプセル化しておくと
https://paiza.io/projects/rmOOucjuBQy05OnLY5JozQ

使用する側には影響を与えずに値チェックができたりするじゃろう
https://paiza.io/projects/Gn51oPIH_D9tEJchmBEzXA

カプセル化ええじゃろう
2020/08/01(土) 21:07:47.56ID:rpF69vZ/
参照渡しで配列の中身が勝手に書き換えられるのも
気持ち悪いと言えば気持ち悪い
カプセル化ではあるけれども
88デフォルトの名無しさん
垢版 |
2020/08/02(日) 19:17:55.28ID:4pM7vb20
こういう認識の齟齬を生みやすいこと自体が
オブジェクト指向の欠陥

まず分かりにくい思想があって
その思想の解釈が人によってバラバラで
コードで表現すると思想と辻褄が合わない部分が出てきて
その辻褄の帳尻を合わせるためにコーディング仕様追加して
コードがやたら汚くなっていく

そしてそもそもの思想を何も知らない初心者が
帳尻合わせの部分だけを真似して覚える
なんのためなのかも分からずに

じゃそもそもそんな思想要らなかったよね。
って言いたくなってくる。
2020/08/02(日) 19:20:30.93ID:Z93Ns0BP
じゃあOOPを捨てて何使ったらいいの？
もしくは、OOPを排除した人は具体的にどんな言語で書いてるの？
90デフォルトの名無しさん
垢版 |
2020/08/02(日) 19:23:45.26ID:4pM7vb20
>>89
OOPで作られたライブラリをインストールして使うが
自分たちはOOPでコードを書かない
基本自作のコードは使い捨てるものとして
資産になるなんて考えは捨てる
構造化と純粋な関数型プログラミングの
考えに徹する
2020/08/02(日) 19:34:03.04ID:Z93Ns0BP
>>90
素人が手を出したら
OOPの恩恵に預かるよりもむしろ糞の山を量産するからね
これは素人が悪いとか
あるいは誰かの力量を疑うようなことを言いたいんじゃなくて
クラス設計インタフェース設計の根本的な難しさを問題にしてる
2020/08/02(日) 20:53:18.23ID:NyB2sc37
身の程を知らないと難しい
2020/08/02(日) 21:27:34.31ID:fjyVy3s+
>>86
エラーハンドリングが必要だから現実のコードだと影響与えるような気がしないでもない
それは良いとしてこのコードを見るとJavaって大変だなぁって感じる

構造体がない
0~255を表現できる標準の型がない
オプショナルパラメータがない

オブジェクト指向への不満度の高さと使ってる主な言語には相関関係ありそう
2020/08/02(日) 21:28:38.27ID:Sk2GUQvh
現実問題としてオブジェクト指向は避けられない
ライブラリがオブジェクト指向前提なってるから…
数十個のメソッド継承したデブっちょクラスを前に
わけわかんねーってなる（←ポンコツですみません）
2020/08/02(日) 23:55:35.79ID:hOZnEm6f
>>94
いや別にそこだけ回避すればええ話出し
2020/08/03(月) 17:52:25.24ID:dUkcl/VW
>>94
ぶっちゃけ使うのはいいがお前は作るな！が言いたいことだよ。
2020/08/03(月) 23:08:05.87ID:/fZxIKnK
このメソッドはこのクラスから継承と
書き出してみればわかると思うよ
たくさんのライブラリがあって
どのライブラリのどの関数を使うというのと
本質的に同じ問題だから
98デフォルトの名無しさん
垢版 |
2020/08/05(水) 02:50:58.19ID:TuJoRFtb
>>88
んなの、オブジェクト指向以前の問題だろ。
2020/08/06(木) 00:04:23.21ID:BdJgq6RO
https://dotup.org/uploda/dotup.org2219661.jpg
2020/08/06(木) 21:09:25.06ID:8iK3jD+F
イミュータブルてできないか、常に考える。
2020/08/08(土) 02:09:38.97ID:8W1l6inb
https://video.twimg.com/ext_tw_video/1291368506907222017/pu/vid/1280x720/6_SSkXAWzEAP7jVq.mp4
2020/08/08(土) 04:14:12.26ID:2Yg/dKbJ
>>101はチンコ動画でした
103デフォルトの名無しさん
垢版 |
2020/08/08(土) 16:34:38.41ID:DwZ6ejE/
staticおじさんを全面肯定するわけではないが擁護するわ
インスタンスを生成するタイプのクラスは
本当はかなり作るのが難しくて
高度な設計技術と計画性を要すると思う

そういう意味ではstaticおじさんは自分の力量を弁えていて
賢明だと思う
インスタンスを作るタイプのクラスをそうそう
乱発製造すべきではないと思う
2020/08/08(土) 18:24:14.86ID:mdJspHbv
>>103
自分の力量？
同僚の力量も考慮に入れろよ
105デフォルトの名無しさん
垢版 |
2020/08/08(土) 21:02:47.33ID:bKK8FlY/
オブジェクト指向の考え
オブジェクト内に状態(フィールド)を持ったり
オブジェクト内の状態を内部で操作するような
処理は外部から勝手に操作されると
不具合の元だから隠蔽しないといけない
(でも操作したくなることもあるから
ゲッターやセッターを作る)
しかし、オブジェクト指向の一番の問題点は
隠蔽さえすれば、状態をもつたり、
内部状態を操作する行為自体は許容してるという点。


staticおじさんや純粋関数型プログラミングの考え方
そもそもオブジェクト内に状態を持つこと、
内部状態を操作すること自体がシステムがめんどくさくなったり
不具合の原因なんだから、そんなこと自体極力やめた
方がいい。という考え方。
クラスにやたらめったらフィールドを定義するから
それらの管理が大変になるんでしょ？
じゃあそもそも不必要にフィールドをたくさん定義するのは
やめようってこと。
106デフォルトの名無しさん
垢版 |
2020/08/08(土) 22:44:55.21ID:OT1M6D83
1クラス1フィールドの原則な。
2020/08/08(土) 23:32:20.53ID:v8N9JR44
そのフィールドがhashmapのhashmap
2020/08/09(日) 02:13:07.67ID:m2kgymdR
>>105
結局グローバル変数の弊害と変わらないってわけだ
イベント駆動プログラムにはオブジェクト指向が向くとされてるから
現在主流の言語はほぼオブジェクト指向になってしまった
オブジェクト指向を避けてイベント駆動を実現できればなあ…
2020/08/09(日) 08:47:05.41ID:B3aIWQ09
>>103
static変数を使わないつくりにすることがstatic変数使う場合に比べて難しいというのは
あんまり納得しないがな。
確かに既存コードがどこで変更が起こってるのか全く分からん場合には仕方ない時もあるが。
>>108
同じようなところもあるがさすがに数百万行のコードになってくると、グローバルとメンバ変数じゃ
負担はだいぶ違うよ。
2020/08/09(日) 08:53:36.03ID:gwNRWHAq
staticなら何の問題も起きないのにバカがメンバに持つ
2020/08/09(日) 08:54:09.82ID:gwNRWHAq
あ、メソッドをpublic staticね
2020/08/09(日) 09:00:00.94ID:a7MhRm2l
カプセル化が不十分というだけ。
XNA は使い方を間違えている。
2020/08/09(日) 09:20:34.38ID:+PyqObml
そもそも処理を仕方がない理由もなく

入力→処理→出力

で入力と出力でチェックできない形にしてしまうのは悪手
114デフォルトの名無しさん
垢版 |
2020/08/09(日) 11:42:28.37ID:e3BzhtQg
>>109
static変数なんてものももちろん使わない
staticおじさんへの批判が的外れになるのもこれが原因
「staticメソッドしか定義しない」
2020/08/10(月) 02:59:21.35ID:l5zwQhnu
アンサイクロペディアでやれ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。