カプセル化は愚かな考え

■ このスレッドは過去ログ倉庫に格納されています
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/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
アンサイクロペディアでやれ
116デフォルトの名無しさん
垢版 |
2020/08/11(火) 00:29:12.66ID:jdRsH5YI
そもそもJavaScriptや
python使ってると
「あれ？クラスって必要なくね？」
って思うことが多いよ
(クラスというかフィールドやコンストラクタや
インスタンス化の必要性)

複数種のデータをセットで持ちたいなら
連想配列や辞書で持てばいい話で
クラス型なんて無名で言いじゃん。
JSONやローカルストレージやDBなど
格納方法には色々選択肢があるわけで
連想配列を引数に与えてやりとりすればいい
もちろんJavaだとMapのキーと値にも
型の宣言が必要で不便だから
JavaScriptやPyを使ったほうがいいね
117デフォルトの名無しさん
垢版 |
2020/08/11(火) 02:32:11.74ID:Yoj/uuKw
Hooks API来てから皆Function Component。誰もClass Componentつかわなくなった@React
2020/08/11(火) 10:11:56.23ID:PBDRLAp9
privateとかpublicじゃなくて775とかパーミッション設定したい。
2020/08/11(火) 10:25:23.64ID:DyHWpKfR
Java.classファイルのパーミッション？
2020/08/11(火) 12:40:18.13ID:VjXaeZPI
>>114
もともとの議論知らんのならだまってりゃいいのに。
あきらかに元ネタはstatic変数を使ってシングルトンやることをマンセーしとるわ。
クラス使えばいいってもんじゃないが、結合時のバグを気にしすぎてテストしずらい構造つくってるってのが
この手の問題なわけよ。
121デフォルトの名無しさん
垢版 |
2020/08/11(火) 13:45:14.16ID:zGJr4AFR
staticおじさんの逆襲
https://qiita.com/minebreaker/items/45ffaaa5e8729e16cfb4
122デフォルトの名無しさん
垢版 |
2020/08/11(火) 13:45:31.32ID:zGJr4AFR
お前ら論破されてんじゃん
2020/08/11(火) 17:56:32.40ID:K2Zt4r5r
別に論破はされてないなぁ

要するにデータをどう持つかの話で
データが必要なものはオブジェクトに持たせたほうがいいし
データが必要ない（引数程度）ならstaticにすると言うだけの話
この「引数」はシンプルな値型に限る。

いやだってstaticにするために引数にしてデータを持たないオブジェクトにしたのに
データを持つオブジェクトを渡すとか本末転倒やろ？ｗ

ようはデータが有るかどうかって話で、ないならstaticでいいけど
あるなら普通にオブジェクトにしましょうってだけ
データが有るのに頑張ってstaticにするとか無駄
2020/08/11(火) 21:32:59.34ID:nKBbqh2w
ケースバイケース、適材適所で設計すれば良いというだけの話なのにね。
教条主義、原理主義の奴らは必ず◯◯すべし！◯◯すべからず！と声高に叫んでるだけでまともな議論にはならないし、スルーするのが一番かと思われる。
2020/08/12(水) 11:17:16.33ID:lWgXenAf
>>123
お前が言ってるのはjavaのstaticの方な。
もともとのstaticおじさんはcの話をしてる。
2020/08/12(水) 11:39:55.90ID:IJKCUlyt
>>125
staticおじさんはjavaのstaticな
2020/08/15(土) 22:05:11.13ID:HPBTZIIs
スタティックでマルチスレッドはキツイぞ
128デフォルトの名無しさん
垢版 |
2020/08/15(土) 22:52:56.43ID:pyil6gDT
マルチスレッドと関係ねえw
2020/08/15(土) 23:11:43.21ID:67hbQA2K
バカっていっつも関係ないこと紐付けるよな
2020/08/15(土) 23:14:58.03ID:Ob8esEzA
バカって関係あることを紐付けるバカも居るだろ
2020/08/17(月) 08:38:19.59ID:+Ou9g0gb
義経「馬も鹿も四脚」
2020/08/17(月) 20:03:48.21ID:aKA3oP69
>>119
chmodとかで設定するパーミッションな。
↓こんなイメージ。
664： // 基底クラスと派生クラスが読み書き可能。その他はよむことだけＯＫ。
　int a;
640： // 基底クラス読み書き可能。派生クラス読み込み可能。その他はアクセス不能。
　int b;
2020/08/18(火) 16:33:07.58ID:b4wiyhNa
>>127
純粋関数は並列性が高い。
GPUシェーダーとかもろに純粋関数だし。
134デフォルトの名無しさん
垢版 |
2020/08/18(火) 22:19:04.69ID:ZCkQ8Dn9
そもそもフィールドで持つ必要がある
データってこのブログで紹介されてるような
キャラHP,MPや貯水量、現金残高
みたいな上下限をもった数値の増減みたいな
ものだけだと思う。
境界値バグに関係しうるパラメータね。
こればっかりはstaticおじさんはやりにくいと思うわ。

カプセル化とはなにか？超わかりやすく解説します！
https://jpazamu.com/encapsulation/

あと考えられるのは 装備品みたいな
魔法使いジョブには剣を装備させてはいけないなど
特有の細かなルールがあるときはカプセル化が必要か。


それ以外の人名とかIDとかメモリ内で変動しないような値を
わざわざフィールドを用意する必要もなければ
privateで保護する必要もないしstaticおじさんで
なんの問題もないよね。
基本的に「演算」がないデータだから
連想配列やJSONでまとめてやり取りすればいいと思う。
あとバグを引き起こすのは値の変更で
あって参照って無害なのでは？
2020/08/18(火) 22:22:09.47ID:wUa7ucBR
バカじゃね
最近のソシャゲなんて全部DBのテーブルに入れなきゃいけないのにクラスの階層構造なんてテーブルに格納するときやりにくくて死ぬだろ
136デフォルトの名無しさん
垢版 |
2020/08/18(火) 22:30:21.66ID:lDffCv4W
>>135
バカじゃね
最近のソシャゲなんてRDB使う方がレアなのにテーブルに格納する前提でコード書いてたらやりにくくて死ぬだろw
137デフォルトの名無しさん
垢版 |
2020/08/19(水) 01:42:01.09ID:hBlUyArs
その界隈はスケールアウト重視でRDBよりさらにフラットなのが主流だからな。
それこそ学校で教えるデータベース正規化の真逆、「逆正規化こそ正義」という世界だし。

「正規化は愚かな考え」というスレを立てようぜ
138デフォルトの名無しさん
垢版 |
2020/08/19(水) 07:15:17.32ID:OrygHj4v
最近気が付いたんだけど。
STLならどうなるか？と考えるのも、一つの分析手法だな。
139デフォルトの名無しさん
垢版 |
2020/08/19(水) 20:19:37.01ID:1TMyVKY8
カプセル化が悪いんじゃなくて設計ミスってるだけじゃん
経験積んで未来予知の精度上げるしかないかな
140デフォルトの名無しさん
垢版 |
2020/08/19(水) 20:29:39.11ID:1TMyVKY8
あとgetter、setterてカプセル化の思想とは関係なく、
便宜上の何かしらの理由(フレームワーク都合、トレースしやすい)で
慣用的に使われてるイメージある
141デフォルトの名無しさん
垢版 |
2020/08/19(水) 20:58:57.98ID:bIJ+SeFj
その未来予知や
設計ミスで後悔する要素とか
フレームワーク依存要素を排除したいから
純粋関数型で余計な状態を持たずに
機械的にプログラミングする方が
いいと言ってるじゃないか。
142デフォルトの名無しさん
垢版 |
2020/08/19(水) 21:05:37.71ID:1TMyVKY8
え、純粋関数型しばり？ｗ
2020/08/19(水) 21:09:50.93ID:AMkDCrIJ
> 純粋関数型で余計な状態を持たずに
> 機械的にプログラミングする方が
> いいと言ってるじゃないか。

↑間違い

状態を持たないものは
純粋関数型で簡単に作れるが
世の中には状態を持っているものがたくさんある

純粋関数型は状態を持たないものは簡単に作れるが
状態を持つものは簡単に作れない

状態を排除することは不可能なので
結局状態を持つものを管理しやすい
オブジェクト指向を併用することになる
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況