カプセル化は愚かな考え

■ このスレッドは過去ログ倉庫に格納されています
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/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
> 純粋関数型で余計な状態を持たずに
> 機械的にプログラミングする方が
> いいと言ってるじゃないか。

↑間違い

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

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

状態を排除することは不可能なので
結局状態を持つものを管理しやすい
オブジェクト指向を併用することになる
144デフォルトの名無しさん
垢版 |
2020/08/19(水) 21:11:56.89ID:1TMyVKY8
純粋関数型のプログラム書いたことないけど
例えばカウンタ（内部に整数型データ保持）とかどういう実装になるんだろ？
って調べたら↓が見つかった
https://riptutorial.com/ja/haskell/example/25413/%E3%83%A2%E3%83%8A%E3%83%87%E3%82%A3%E3%83%83%E3%82%AF%E3%82%AB%E3%82%A6%E3%83%B3%E3%82%BF%E3%83%BC
結構面倒だな
145デフォルトの名無しさん
垢版 |
2020/08/19(水) 21:13:46.83ID:1TMyVKY8
状態を多用する場面で純粋関数型は向かないってことかな？
2020/08/19(水) 21:14:49.28ID:AMkDCrIJ
純粋関数型言語を使えば状態を持たなくて良くなるわけじゃないんだよ

状態があるのとないのであれば、状態がない場合は
テストも簡単でシンプルに作れることが出来るだろう

しかし実際のシステムは状態があるんだよ

状態がないもの（つまり簡単なもの）を簡単に作れることを目指しても有り難みがない
状態があるもの（複雑なもの）を簡単に作れるもののほうがありがたい
147デフォルトの名無しさん
垢版 |
2020/08/19(水) 21:28:46.66ID:1TMyVKY8
関数型言語のエッセンス（イミュータビリティ）を部分的に取り入れると
いい感じだけど全部置き換えたら破綻するね
148デフォルトの名無しさん
垢版 |
2020/08/19(水) 21:37:00.69ID:bIJ+SeFj
状態を持つ必要が有るとしても
極力少なめに厳選すべき

データベースのカラムは
全部オブジェクトのフィールドとして保持して
コンストラクタ経由で引数をフィールドに移し替えて
全部ゲッターセッター用意して
見ればわかるメソッドに全部Javadoc記述して
とかどう考えても馬鹿でしょ

personオブジェクトの
人名、年齢、身長、体重
とかがプログラムが動いてる短い期間に目まぐるしく
変動するんですか？
オブジェクト指向の教科書見るとそうやって教えてるんだぜ？
2020/08/19(水) 21:39:15.87ID:meyBYzW3
>>147
別に破綻しないよ
状態が必要なら、状態ごと受け取って状態を含めた出力をするような関数を作る

データとそれを使う関数を1つの単位(クラス)にまとめたほうがいいのか
それともデータはデータ、関数は関数で分けて管理したほうがいいのかという違い
(関数型でも必要ならある種のデータ型とそれに密接に関係する関数群をモジュールとしてまとめる)

どちらかが常にいいというわけじゃなくトレードオフだから
それを理解してドメインに応じて使い分ければいい
2020/08/19(水) 21:42:50.48ID:AMkDCrIJ
> 状態が必要なら、状態ごと受け取って状態を含めた出力をするような関数を作る

んで、その最終形態が

メモリの内容を全部渡して、書き換え済みのメモリを返す
それを永続化する。

つまりはグローバル変数と同じ状態になるわけだ
2020/08/19(水) 21:44:22.03ID:AMkDCrIJ
結局書き方の違いでしか無いんだよね

状態 = 関数（状態）にするか
状態.関数() にするかという書き方が違うだけ
2020/08/19(水) 21:47:30.11ID:AMkDCrIJ
そして行き着く先は

状態 = 関数（状態）の形で
大規模なものを人間が統治管理できるのか？って話

人間がってのが重要な所
理論的には出来る。コンピュータにも出来る。

だが人間がそれをやれなきゃ意味がない
簡単な足し算でも、それが何万個もあれば人間はミスをする
2020/08/19(水) 21:49:27.84ID:meyBYzW3
>>150
プログラミングモデルの話だからそういうのは関係ないんよね

言語が保証してくれるレイヤーから上でプログラムをどういうスタイルで書くかという話だから

>>144の最初の例ならCounterが状態
incはCounterとIntを受け取ってCounterを返す関数

inc :: Counter -> Int -> Counter
inc (MkCounter c) n = MkCounter (c + n)
154デフォルトの名無しさん
垢版 |
2020/08/19(水) 21:55:27.63ID:1TMyVKY8
結局外から整数渡すのか
155デフォルトの名無しさん
垢版 |
2020/08/19(水) 22:08:23.64ID:1TMyVKY8
>>152
>状態 = 関数（状態）の形で
>大規模なものを人間が統治管理できるのか？って話
オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
このあたり関係ありそう
2020/08/19(水) 22:33:08.34ID:yE6ycl6R
昔のC言語は状態なんか持たなくても動いてたよｗ
前提が間違ってるじゃん
157デフォルトの名無しさん
垢版 |
2020/08/19(水) 22:34:39.94ID:1TMyVKY8
>ソースコードが存在し改修が可能であればカプセル化しても問題ない。
>ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
ライブラリが担うべき要件でもないし他の探すか自分で作るか改修依頼するかしかないでしょ
なんでカプセル化が悪の権化みたいなことになってんのｗ
158デフォルトの名無しさん
垢版 |
2020/08/19(水) 22:35:36.18ID:OrygHj4v
純粋でなければ、利点として宣伝されるものの多くが実現されなくなるからな。
もっとも、純粋であっても、現時点では実現されていないのだが。
159デフォルトの名無しさん
垢版 |
2020/08/19(水) 22:36:45.75ID:1TMyVKY8
C言語とかバリバリ状態変数使ってるでしょ
160デフォルトの名無しさん
垢版 |
2020/08/19(水) 22:39:11.93ID:1TMyVKY8
その状態の管理方法がオブジェクト指向でも純粋関数型でもないだけで
161デフォルトの名無しさん
垢版 |
2020/08/19(水) 22:56:55.74ID:c5gUks+P
>>140
getter/setterはJavaBeansの仕様だからね
JavaBeansはGUIツールでポトペタで操作できるようにするためのもの
GUIのツールでプロパティ書き換えたりイベントリスナー書いたりするのが目的
だからJavaBeansの情報を取得するBeanInfoにはgetIconメソッドがあったりする

JavaBeansではプロパティに値をセットしたら値が変更されましたイベントを発火したりするから
getter/setter経由でアクセスすることは理に適っていた

それがいつの間にかオブジェクト指向のプログラムではgetter/setterを書くんだーになってしまった
JavaBeansのようなコンポネントの作法はライブラリ内部で使われるようなオブジェクトには必要ない
デスクトップアプリの開発が衰退したおかげかいまはだいぶその認識が広まってる
2020/08/19(水) 23:05:18.29ID:EjRsdu11
単にそのクラスに必要な操作のみ公開するという思想は良いと思うが
頭の硬いやつがいると理解出来ないからか文句を言ってくる
2020/08/19(水) 23:25:59.69ID:yE6ycl6R
>>162
結局入力と出力を
メンバ変数に入力や出力を内包されると単純に動作が把握し難いだけで
全くメリットがない
内包されたデータを見ないで修正してもいいのか？
お前の会社はそれでいいとは言わないだろう
だとしたら入力や出力を隠蔽するのは誰にとっても迷惑にしかならない
164デフォルトの名無しさん
垢版 |
2020/08/19(水) 23:41:19.27ID:1TMyVKY8
そのクラスの責務（入力に対する出力の仕様）がわかっていれば
具体的な内部の動きを把握する必要がそもそもない
把握する必要ないから楽
2020/08/19(水) 23:48:14.52ID:AMkDCrIJ
>>163
システムの規模が大きくなった時
どう管理するかって話だからその理屈は全く関係ないんだよな

内包されたデータを見ないで修正してもいいか？
オブジェクト指向であれば、それがある単位で分割されているから
そこだけを見ればいい
2020/08/20(木) 00:39:03.89ID:Ha0cLvqC
>>164
お前が作ったクラスの動作がおかしいときどうすればいいの？
中身みんでええの？
2020/08/20(木) 00:40:27.24ID:Ha0cLvqC
>>165
お前が作ったクラスの動作がおかしいときどうすればいいの？
2020/08/20(木) 00:43:54.72ID:x6SYzBHh
>>167
テストコード書いて直すだけ
2020/08/20(木) 00:44:38.43ID:x6SYzBHh
>>166
お前が作った関数の動作がおかしいときどうすればいいの？
中身みんでええの？

どちらも中身を見るなら
管理しやすいオブジェクト指向の方が良い
170デフォルトの名無しさん
垢版 |
2020/08/20(木) 00:50:30.84ID:ecAQ66Lj
適切な単位で分割されてると修正も楽
それこそ「そのクラスの責務（入力に対する出力の仕様）」だけ
満たすことを考えればいい
171デフォルトの名無しさん
垢版 |
2020/08/20(木) 00:53:30.10ID:ecAQ66Lj
内部で関係する変数とかを閉じててくれないと
そのクラスに値を設定する部分を見て回らないといけなくなる
2020/08/20(木) 00:58:14.66ID:nfJPehze
クラスに値を設定する部分は、そのクラスを見るだけでいい
引数として独立していると、その引数を使ってる部分を全部調べなければいけなくなる
戻り値が変わると、その戻り値を使ってる部分全てだ
2020/08/20(木) 00:59:25.71ID:Ha0cLvqC
>>170
中身を見るとどうやらメンバ変数statesの値がnoneにならないとメソッドの処理が最後まで流れない処理になってるみたいなんだけど
こういうときどうしたらいいの？
174デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:09:23.46ID:Eg0HvHSQ
一クラス一メソッドの原則な。
175デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:10:33.08ID:ecAQ66Lj
メンバ変数statesがprivateだったらそのクラス内に閉じた問題だから
単純にそのクラスのメソッド内でstatesとnoneを比較するようなとこを
洗い出せばいいんじゃないの？
176デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:20:32.10ID:qjxJt4Hn
>>170
その責務って奴が言葉だけは聞こえがいいが
現実論として関わるプログラマや関係者の間で
認識がバラバラになる最大のポイントなんだわ。
プログラムやコンピュータを計算機として見てないんだわ。
「この処理を果たしてこの場所で書いていいものか…」
なんて余計な事で頭を悩ます最大の原因なんだわ。

それよりももっとシンプルに、
任意の場所に、受け取った引数を使って
結果を返す関数を作って関数に要求させた演算を
投げて結果だけ受け取った方が生産的だよね？
関数を連鎖的に組み合わせればどんな複雑な演算も
成し遂げることが出来る。
177デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:27:25.42ID:ecAQ66Lj
それはチーム編成とか統制の問題では
レベルが低い集団だと統制とれずク○の山が積み上がって
収集つかなくなるんだろうな
2020/08/20(木) 01:32:57.21ID:Ha0cLvqC
>>175
privateメンバ変数は見なくていいって話じゃなかったん？
179デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:36:01.29ID:ecAQ66Lj
クラス外からは気にしなくていいけどクラスを修正するときは見なきゃだめでしょ
privateなら見るべき範囲はクラス内って絞ることができる
2020/08/20(木) 01:44:41.21ID:Ha0cLvqC
>>179
じゃあ、結局見るんじゃんバーカ
181デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:48:58.64ID:ecAQ66Lj
え
182デフォルトの名無しさん
垢版 |
2020/08/20(木) 01:52:46.09ID:ecAQ66Lj
まあ理解できもしないのに真似事みたいなことするのが一番迷惑だから
やりたいようにやりなさい
183デフォルトの名無しさん
垢版 |
2020/08/20(木) 02:03:10.41ID:ecAQ66Lj
そもそも>>173の質問がバカ丸出しなのに自覚ないとか
2020/08/20(木) 07:00:11.09ID:X1nNk3cj
>>161
プロパティって、どういうプロパティが存在するかを実行時にインスペクトできるというのも重要な性質だな。
BeansはJavaのリフレクションでそれを実現していたけど、単なるgette/setterではそういうのも忘れられている。
2020/08/20(木) 07:31:18.16ID:Ha0cLvqC
>>179
さらにpublic staticならグローバル変数不使用なら引数と戻り値（入力と出力）の確認だけじゃん
絶対こっちのがクラスより優秀だろ
2020/08/20(木) 07:59:40.26ID:i/J3/2zN
>>176
それって、ちゃんと考えて設計するの面倒だから全部グローバル変数でやります、生産性高いよね！といってるのと変わらないじゃないかw
2020/08/20(木) 08:08:01.01ID:Ha0cLvqC
>>186
比較するものがグローバル変数使用のソースしか無くなった？
188デフォルトの名無しさん
垢版 |
2020/08/20(木) 08:33:25.88ID:ecAQ66Lj
>>185
> さらにpublic staticならグローバル変数不使用なら
どうせその前提だとそれはクラス内部に状態を持つ必要ない単なるUtilityクラス
内のメソッドだろ？
状態をどうやって管理するかの話だったのに、状態を排除した前提を持ち出してきて
何を認めさせたいの？反論することだけが目的？
2020/08/20(木) 08:38:25.78ID:Ha0cLvqC
>>188
だからグローバル変数不使用のc言語と同じでいいよ
っていうかこれで完璧なんだよ
190デフォルトの名無しさん
垢版 |
2020/08/20(木) 10:46:21.05ID:ecAQ66Lj
御託はいいからお前の書いたコード見てみたいわ
グローバル変数を使わないCコードが書けるんだろ？（失笑）
C言語ならグローバル変数はある程度使うべきなんだけどね
2020/08/20(木) 11:25:12.56ID:Ha0cLvqC
>>190
普通に書きゃいいじゃんｗ
作れないものがあったと思ってるの？ｗバカ？ｗ
192デフォルトの名無しさん
垢版 |
2020/08/20(木) 12:04:17.63ID:ecAQ66Lj
下手なりにかけるとは思うよ下手なりに
ただその方法じゃスケールしない
ここまで言ってわからないならもう相手にしてあげないよ
193デフォルトの名無しさん
垢版 |
2020/08/20(木) 12:06:02.57ID:ecAQ66Lj
小さいプログラムしか書いたことないんだろうな
2020/08/20(木) 12:14:50.55ID:KHHtBj+5
結局大規模なものをカプセル化が有効なんだよね
2020/08/20(木) 12:49:31.45ID:tyNv301J
Information Hidingの意味でカプセル化と言ってるやつと
データとメソッドをオブジェクトという構造にひとまとめにすることをカプセル化と言ってるやつがいるから
話が噛み合ってない

前者はオブジェクト指向に関係なくあらゆるプログラミングスタイルで使われてる
規模に関係して重要になってくるのはInformation Hidingの意味でのカプセル化
CでもHaskellでもそれが重要なのは変わらない

後者はオブジェクト指向特有のもの
これはソフトウェアの規模の大小とは関係なく
どういう方向の変化に対して高い柔軟性を確保しておくのがいいかという問題なので
デメリットも考慮しつつ状況に合わせて採用するかどうか判断すべきもの
196デフォルトの名無しさん
垢版 |
2020/08/20(木) 15:12:12.70ID:ecAQ66Lj
Ha0cLvqC ← こいつに関しては
・情報隠蔽
・関心事の局所化
いずれの意味も明らかに理解できていないし、日本語も通じてないから話が噛み合わない
197デフォルトの名無しさん
垢版 |
2020/08/20(木) 16:03:22.57ID:BhReT/u1
お前らのコミュニケーション能力が劣ってるだけだろ
良い大人なんだからきちんと伝わる語彙と文法、論理を示せばわかりあえる
コミュ障のお前らに俺が手本を見せてやるよ
198デフォルトの名無しさん
垢版 |
2020/08/20(木) 16:04:17.28ID:BhReT/u1
>>191
>>193
ちんちんが痒いときってキンカン塗っとけば良いですよね？
2020/08/20(木) 17:54:53.75ID:Ha0cLvqC
>>196
でも君、メリット説明できないよね？
200デフォルトの名無しさん
垢版 |
2020/08/20(木) 18:34:06.73ID:ecAQ66Lj
お前みたいな低能に説明してる時間が無駄
2020/08/20(木) 19:27:08.80ID:Ha0cLvqC
>>200
まあ、この世のどのサイトも説明できてないから気にするなよｗ

ってアレ？ということはメリットない技術なんじゃない？ｗ
202デフォルトの名無しさん
垢版 |
2020/08/20(木) 19:33:32.26ID:ecAQ66Lj
技術的な関心があってこんなスレ開いてるんだろ？
にしては程度が低すぎる
203デフォルトの名無しさん
垢版 |
2020/08/20(木) 19:47:35.12ID:ecAQ66Lj
お前が今まで信じてきたものやってきたことって意味あったの？
2020/08/20(木) 20:05:43.17ID:Ha0cLvqC
>>203
お前の方が顕著だろ
じゃあ、お前と主張が同じサイト持ってきてメリット説明してみろよｗ
205デフォルトの名無しさん
垢版 |
2020/08/20(木) 20:24:20.57ID:ecAQ66Lj
オブジェクト指向の理解にすら躓いてるやつと話しても時間の無駄だから
2020/08/20(木) 21:49:30.63ID:Ha0cLvqC
>>205
ああ、そう？ｗ
メリットを解説できてるサイトないけどなｗ
207デフォルトの名無しさん
垢版 |
2020/08/20(木) 21:56:57.19ID:/mEcLGEB
理解できる脳みそがない
2020/08/20(木) 22:16:51.32ID:KHHtBj+5
>>206
メリットを解説してるけど、解説になってないというサイトを言える？
お前が一番まともだと思うやつね。全てまともじゃないというのなら其の中でいちばん有名なやつ
それをお前が言えるのであれば、俺らはそれがちゃんとした解説になってることを証明するのは簡単だろう
2020/08/20(木) 22:22:56.32ID:Ha0cLvqC
>>208
いいや、ゴミクズ過ぎて違いなんかわからん
オブジェクト指向が役に立つって書いてあるだけで俺にとっては全く役にたたんサイトなわけだし
210デフォルトの名無しさん
垢版 |
2020/08/20(木) 22:30:26.14ID:qjxJt4Hn
もう「お前はオブジェクト指向理解してない」
に結論づけるのやめにしようや。
かならずそこに収束するやん。
理解してない奴が悪いんじゃなくて
理解し難い概念であるオブジェクト指向が悪い
っていう発想の転換してんだよ
2020/08/20(木) 22:31:11.37ID:Ha0cLvqC
だいたい言ってることキチガイじゃん
オブジェクトの中身は隠蔽されてるから気にしなくていいって言った口で
修正するときはprivateのメンバ変数使用箇所全部確認して直せって言ってるんだぜ
なんのために誰に隠蔽してたんだよｗ
完全に無意味じゃんｗｗｗ

こんなくだらないことやってるんだったら、public staticにするべきだぜ
212デフォルトの名無しさん
垢版 |
2020/08/20(木) 22:34:10.09ID:Eg0HvHSQ
いや、一クラス一メソッドの原則に基づいて設計すればじゅうぶん可能。
2020/08/20(木) 22:47:07.87ID:KHHtBj+5
>>209
そういう言い訳をしたからお前の説得力ゼロになったな
結局何も知らなずにろくなサイトも見ずに
ダメダメ言ってるだけだろ？

言い返したいなら、ちゃんと解説してるサイトの一つでも上げてみろって
2020/08/20(木) 22:48:24.29ID:KHHtBj+5
>>211
> オブジェクトの中身は隠蔽されてるから気にしなくていいって言った口で
それは使う場合の話。つまり開発（担当）者とは別の人は気にしなくていい

> 修正するときはprivateのメンバ変数使用箇所全部確認して直せって言ってるんだぜ
それは開発（担当）者の話

この区別ぐらい基本だろ
2020/08/20(木) 23:03:27.99ID:Ha0cLvqC
>>214
じゃあ、開発者しか触らない環境でクラスなんて作るのは無駄ってことでおｋ？
お前、完全にそう言っちゃってるよな？
それでええの？
2020/08/20(木) 23:06:06.44ID:KHHtBj+5
>>215
お前バカなのか？

例え自分が開発したとしても、それを使うだけの場合と開発する場合は違うだろ

苦労して頑張ってライブラリを作りました。
そのライブラリを使うときに、ライブラリのソースコードの中身を見ないと使い方がわかりません

ってそれ、作り方しっぱいしてるじゃん
お前はいちいち中身を見てるんだろうけどな
2020/08/20(木) 23:07:26.61ID:Ha0cLvqC
>>213
ハイハイ、オブジェクト指向にメリットが全く無いのはメリットを感じ取れないやつがバカなんだよなｗ
誰も証明できないけどなｗ
バーカ、一生やってろｗ
218デフォルトの名無しさん
垢版 |
2020/08/20(木) 23:08:01.72ID:qjxJt4Hn
そのライブラリ使ってるブログ検索して
真似するだけなんだよなぁ…
隠蔽要らんやん
2020/08/20(木) 23:11:15.07ID:Ha0cLvqC
>>216
は？何言ってるのか意味不明
2020/08/20(木) 23:13:58.87ID:KHHtBj+5
>>219
隠蔽っていうのはな、コードとデータの両方の話なんだよ
ライブラリにすれば中身を見なくてすむようになるんだよ
知ってるか？
2020/08/20(木) 23:15:04.46ID:KHHtBj+5
頑張ってクイックソートライブラリを作ったおっさんは
これでもうソートするときに中身をいちいち見なくてすむ
って安堵してるわけだ
2020/08/20(木) 23:19:44.69ID:Ha0cLvqC
>>220
でも修正するとき見ないと駄目なんだろｗ
つまり作る側と使う側が完全に別れてないときにクラスなんか無意味なんじゃない？
2020/08/20(木) 23:44:16.56ID:KHHtBj+5
>>222
オブジェクト指向
　修正しない時・・・見ない（メリット）
　修正する時・・・見る

関数型言語
　修正しない時・・・見る（デメリット）
　修正する時・・・見る

理解できますか？
224デフォルトの名無しさん
垢版 |
2020/08/20(木) 23:44:18.70ID:iNatz9V0
>>195
そうそう。
カプセル化っていってんだから、オブジェクト指向は関係ない。
Cの構造体でメンバを公開したり非公開にしたりできまっせ。っていうだけのこと。
それを愚かというなら、その程度の規模のプログラムしか作ったことないんだろうね。
225デフォルトの名無しさん
垢版 |
2020/08/20(木) 23:45:52.06ID:iNatz9V0
>>222
君って情報学部の学生さんなんか？
それとも、どっかの会社でプログラマーの卵として頑張ってるのか？
プログラミングの素養が絶望的にないから、他の道で頑張ったほうがいいよ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況