カプセル化は愚かな考え
■ このスレッドは過去ログ倉庫に格納されています
■危険性
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（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) >>262
いきなりメソッドの中身を見る話になってんじゃん
見る必要ないんだろ？ｗ >>264
だから修正するときと使う時の話をごっちゃにするな
使うときはメソッドの中身なんか見ない 何度言っても理解できない。アホなのか？本当のアホなのか？ 引数で渡すと、この値なんなんですか？ってなる
「内部で使用するフラグです。」
初期化関数を呼んだら内部で必要なデータを返しますので
次呼ぶときに渡してください。
ファイルハンドルっていうんです。
みたいなね。
内部情報が一つだけならいいが
複数あったらどうするのか？
ファイルハンドルは内部に確保したメモリに
シーク位置を紐付けて保存してるんですよ
なんてことになるｗ >>247
ボタンごときに膨大なプロパティがあるのがおかしい
整理できてないｗ
さておき、実際にはほとんどデフォルトで使うから、「クラスなら面倒がない」と言いたいのかな
関数でも名前付き引数、あるいはコレクション渡しで未設定ならデフォルト、で省略できると思うが
まあコレクションはオブジェクト指向の基礎なので、これを使えば既にオブジェクト指向なんだろうけど
WinAPIもスタティック関数でオブジェクトを動かすので、スタティック関数は別にオブジェクト指向の対立概念ではないが >>267
内部で～はお前が出してるメッセージの問題だよね？ >>265
じゃあ、エラーもトレースも外に出すなよ
お前が作ったモノは、ただ、ただ、わけもわからず落ちろ >>268
> ボタンごときに膨大なプロパティがあるのがおかしい
現実見ろよ
お前が言う方法で、create_button関数作ってみ
ボタンの属性として、ボタンの値、無効ボタンかどうか、
位置x、y、z座標、文字の色、ボタンの色、枠のスタイル、
ボタンの余白、文字の右寄せ・左寄せ、フォント、
まだまだあるが、これぐらいでいいだろう？
ボタンを作ったらこれだけの属性が初期設定として
設定される
はい、引数で作ってみてください
あと将来の拡張性も考えてね。
増えるかもしれない >>272
構造体はグローバル変数やろ？
どこを書き換えるのかわからんのだから
それとも一つのクラスになってるから
それは一つの引数だ！っていうつもりか？
あ、間違った一つの構造体だったｗ 結局、引数で複数の情報を与えるのはずらずら何十個の並べれば
また可能だとしても、戻り値が一つしかないから現実的じゃないんだよね
クラスを使うのは、一つのメソッドで
複数のプロパティを操作することがあるからなわけ
例えばcreate_buttonだったら複数のプロパティを初期化する
戻り値で複数の値を返せないし、戻り値を構造体とかクラスにして返すとしたら
結局それはお前の言うクラス内のグローバル変数と同じになってしまう
引数の構造体（クラス）のうちどこを変更するかわからないからね 引数で渡すと将来の修正時の拡張性と互換性が犠牲になる
これはいい知見だ 変数のスコープと型の違いも区別できてないようだと
どういうやり方しても泥スパゲッティしか出来上がらない 関数型は否定してないよ
少数の引数と一つの戻り値だけで実現できることなら関数型でやればいい
それができないことまで無理してやろうとするのはデメリットしか無いという話
引数で渡せばメリットが有る、だから引数で渡すようにしよう！
これは間違いで
引数で渡せる場合は、関数型にメリットが有るが
そうでない場合にはむしろろデメリットになる
条件に応じて関数型にするかに分岐するのであって
関数型にするために条件を無理やり歪めてはいけないということ 構造体でまとめることによって引数で渡せるようになるのなら、そうした方が関数型的な考え方に親和的ということはない？
戻り値が引数以外に依存するのはできるだけ避けるというのが関数形的な発想かと思っていたが、 >>279
そうすると結局、クラス内のメンバ変数のどこがいじられるかわからないというのが
引数の構造体のどこがいじられるかわからないという問題に変わるだけで
関数型を使うメリットが無くなる
じゃあもうクラスでいいじゃんとなる
何度も言うように、関数型が優れてるから関数型に移行するのではなく
関数型が優れてる場合は限られてるので、そこだけ関数型にすればいい
関数型にメリットがないならオブジェクト指向にすればいい
その例が、ボタンの生成のように一つの関数で
複数のメンバ変数を初期化するような例 × 戻り値が引数以外に依存するのはできるだけ避ける
○ 戻り値が引数以外に依存するのが "避けられる場合に限って" 関数型を使いましょう 関数型を実践したこともないのに
知ったかして関数型関数型と連呼しちゃうのは
日本を出たこともなく日本のことしか知らないのに
欧米では～欧米では～と連呼してるのと同じ じゃあグローバル変数を使って大規模なプログラムを組み上げたことがない人はグローバル変数を批判してはいけないのか
実践せずともわかるだろうが、関数型も欧米も想像で十分 だから多数のプロパティを持つcreate_buttonを関数型で実装してほしい 1クラス1メソッドの原則なんて言葉はお前が考え出したものだろ？ｗ ボタン自体は状態を持つものだから、オブジェクト指向で実装するのが自然でしょ？（関数型でも抜け道があるのかもしれないが、自分は関数型には詳しくないのでわからない）
しかし、上でされていた議論はそういう話ではなくて、関数の戻り値が依存する情報を、①全て引数として与えることも、②一部はメンバ変数から引っ張ってくることもできるという状況の場合に、どちらを選択するかという問題設定だと思っていたんだが。 >>290
関数型の主張が「どんな場合でも引数で渡して戻り値で戻したほうがいい」だから
オブジェクト指向の主張は元から、内部にプロパティが多数ある場合の話をしてる グローバル変数未使用で関数のみを使って状態にも対処できる！
オブジェクト指向なんて選択肢はない！
と言い張る子の霊圧が消えた．．． >>252
ぉ？Javaディスってんのか？
>>290
> ボタン自体は状態を持つものだから、オブジェクト指向で実装するのが自然でしょ？
いや、別にオブジェクト指向で実装するのが自然っていうのは乱暴だろ。
ほんと、ソース貼れよ。引きこもりのアマグラマーがw もう死んでね？ｗ
ボタンを関数型で作れなかったんだから >>271
たしかC++ってそういうもんだがｗ
しかも同じく嫌いだよｗ
整理できてない
で、なんでクラスだとそれが楽になるのかね
＞さておき、実際にはほとんどデフォルトで使うから、「クラスなら面倒がない」と言いたいのかな
こういうことかね、て先回りして聞いてるんだが そんなにうじゃっとしてないか
https://bituse.info/winapi/5
//ボタンコントロール作成
hwnd_button=CreateWindowA("button","ボタン",WS_VISIBLE | WS_CHILD | BS_PUSHBUTTON,
50,50,100,100,hwnd,(HMENU)CHILD_ID,hInstance,NULL);
親ウィンドウの準備がイラっとするのかな そんなお膳立てされたAPI使っていいって誰が言った？ ちなみに多くの人が、「クラスオブジェクト指向な記述で」を「オブジェクト指向で」と言ってるようだね
スタティック関数で動かすオブジェクト指向もあるので（C++、WinAPI）
略すなら「クラスで」と言った方がいい（これも不正確だが） システムワイドでReduxのような仕組みを適用するのは無理だろうか？ 思うに、このスレに集まってる人らの
業務内容が違うんから議論がズレるんじゃないか？
Web系の場合メモリ上の
オブジェクトは一瞬で役目を終えるから
正直カプセル化とかいらない
node.jsやPHPでデータベースのへselect文投げると
連想配列オブジェクトの配列が帰ってくるから
つまりテーブルから動的にクラスののオブジェクトが
生成するから正直クラス定義もいらない
staticでなんの問題もないと思う。
状態管理は特有のセッションに保持するだろう。
でもゲーム系だとキャラのHPみたいなゲージ管理や
持ち物、装備品などいつまでもメモリ上に
居座って状態管理が必要だからオブジェクト指向
とカプセル化は大切。 うーん。
職業プログラマが5chで情報交換してたら、ちょっとひどすぎない？
俺は自分の職業の板なんて行かない。
見たことはもちろんあるけど、素人が玄人のフリしてうんちく述べてるだけで、俺らが何か書き込むことは無いと思うよ。
それとも職業プログラマってそんなに程度低い？
素人とうんちく語り合うほど？ プロが匿名掲示板で情報交換して得るものなんてないでしょ。
あったら怖いわｗ >>309
常駐プログラム云々いっちゃうと、GCが優れてる！いや、C++のデストラクタの方が！
とか、そういう話にもなっちゃうからオブジェクト指向云々は関係ないような。
優秀なCプログラマならCでもリークしないプログラム書くでしょ。
static云々言ってるバカは、オブジェクト指向でもリーク起こすと思うわ。 オブジェクトのライフサイクルとカプセル化がなんの関係あるんだ？ 素人が玄人のフリしてうんちく述べてるのがうざいから消えてほしいとは思ってる
でも中にはプロっぽい人も紛れてる いや、無いない。
素人が適当なこと書いてるから訂正するか？
無い無い。
レベルが違いすぎるのよ。
それとも何か？
プログラマという職業に限ってそんなにレベルが低いか？
素人と言い争うほどか？ 自分が素人って認めたんかpublic staticくん >>304
誰もWinAPIの話とは言ってないが、それボタンはウインドウハンドルを返すのよ
つまりクラスのメンバ変数に状態を持ってインスタンスのポインタを返してるのと同じ
オブジェクト指向なんだよね
こういうのって本質的に複数の状態を持ってるわけだから
関数型で作るの大変でしょ？ Windows自体がオブジェクト指向だから、関数型と相性悪いのかもしれないな。
もしかすると、それが原因でWindowsが無くなるのかもしれないな。 >>319
だからWindowsの話はしてないんだって
勝手にWin32の話にしておいてWindowsのせいにするなよ
なんでもいいから関数型で複数のプロパティを持つボタンのようなもの作ってみろって
一つの関数で複数のプロパティを操作することもある
そして将来の拡張性も考えないといけない
関数型でできるんか？ ホビーの奴と話し合うことなど、一ミリたりとも無いけどな。
レベルが全く違う。
プログラマに限っては、そんなにレベルが低いか？
アマチュアと話し合うことがあるのか？ >>321
ウェブ界では、状態をすべて外に追い出すのが流行ってるようだけどな。 関数型っていうのは結局ガイドラインみたいなもんやろ
引数だけから戻り値が決定する関数はテストがしやすいから
可能であればそうするようにしましょう
実際には可能でない場合が多い
何十個の引数と専用の戻り値型でも作れば
理論上は可能かもしれないが使いづらくなる >>323
それって結局グローバル変数なんだけどねｗ あおりではなく
カプセル化をうまく説明してあるサイトを長い間探しているんだが
決定版はどこ? いや俺は状態をすべて外に追い出すというのが目からうろこよ。
最終的にどうなるのか知らんけど、これは突き詰めて結果を導いてほしいな。 頑張ったけど駄目でしたという場合もあるだろうけどな。
その結果が納得できるところまで突き詰めてほしいな。 ウェブでは状態を全て追い出いたために、巨大な「状態オブジェクト」ができて
複数の関数から、共有の状態オブジェクトを変更するようになってしまってる
引数から戻り値が決まる関数型とは別のものだよ
分離された状態オブジェクトを読み書きして
状態オブジェクトが変更される >>309
ゲームの種類にもよるけどアクションやシューティングの場合
基本は以下3ステップの無限ループでTODO管理アプリみたいなものと核は同じ
1. 入力を処理
2. 状態を更新
3. 出力を生成
ReactでもElmでもRxでも関数型のパラダイムなら
直前の状態と入力(ユーザー操作やタイマーや衝突など)から
新しいバージョンの状態を作ってそれをもとに出力を生成して画面を更新する >>330
「状態」がオブジェクト、つまり配列と連想配列の組み合わせで
どこが必要なのかわからないから、テストが困難になる アマチュアと話し合ってるんじゃなくて
アマチュアがボケ倒してるからつっこんでるんだろｗ Reactなんかでいう「状態」というのはオブジェクトのこと >>332
逆かもしれんぞ？
状態が外に記録されているので、把握しやすくなる。
それどころか状態の圧縮など、自動化されやすくなり、テストが容易になる。 もともとC++のクラスっていうのは構造体の拡張なんだよね
この構造外がReactなんかでいう状態のこと
関数(状態=構造体へのポインタ, 引数1, 引数2, ...)
というのが
構造体へのポインタ->関数(引数1, 引数2, ...)
に変わったのがC++
この2つは書き方が違うだけで本質的には同じもの >>333
無い無い。
小学生がごっこ遊びしてるところにプロが違う違うと口挟むか？
自分の職業の板を見てもそんな感じよ。
突っ込もうなんて思わないし、実際突っ込んでるプロも見たことが無い。
素人同士でわいわい言い争ってる。
レベルが違いすぎんのよ。
輪に入るわけがない。
職業プログラマは素人の輪に入れるのか？ >>335
> 状態が外に記録されているので、把握しやすくなる。
状態が外にあっても中にあっても本質的には同じ
どちらにしろオブジェクト指向 考えてみろよ。
園児が模型の飛行機でブーンとやってるところに、職業パイロットが通りすがったら、違う違う対気速度が低下するからこうだなどと口をはさむか？
そのくらいのレベルの差があるわけよ。
それともなに？
職業プログラマは素人と大した変わらんとでも？ >>339
状態遷移表などは圧縮できるし、事前の検査も可能。
ここを否定せずに、研究してみてはどうか？
新しいモノは中国に期待するべきか？ >>341
そりゃオブジェクト指向でもそれは可能なんだから当たり前やろｗ >>151-152
ついにこのへんに言及したレスが出てきたな
状態がある問題をプログラミングする以上
どっちの方法がマシかを問うのが次に取るべき立場
状態は悪、関数型は神、みたいな話はもうみんな飽きたろ？ 俺は容赦なく模型飛行機で遊んでいる園児（お前）を空爆する >>344
だからお前はアマチュアとバレてるわけよ。 >>343
状態と計算を分離する結果、関数型の恩恵にあずかれるなら、分離する方向に行くのが正しいのではないか。 >>343
前から言ってるが、関数型は少数の値型と一つの戻り値で十分な関数としての要件を
満たしているときに便利なもので、そうでないものを無理やり対応させても不便なだけという話
関数型が優位なのは理論上の話で、理論上の話だと数十個の引数でもOKという扱いだから >>280
オブジェクトの内部状態が変わるのと戻り値だけが変わるのとでは影響範囲が違うだろう。
それこそグローバル変数とローカル変数のスコープの違いみたいに。 >>346
> 状態と計算を分離する結果、関数型の恩恵にあずかれるなら、分離する方向に行くのが正しいのではないか。
「関数型の恩恵にあずかれるなら」
結局そこ
「関数型の恩恵にあずかれるなら」関数型
「関数型の恩恵にあずかれないなら」オブジェクト指向
適切なものを組み合わせて使うべき
「関数型の恩恵にあずかれない」例の一つがボタン >>348
> オブジェクトの内部状態が変わるのと戻り値だけが変わるのとでは影響範囲が違うだろう。
今話をしてるのは
オブジェクトの内部状態 "すべて" を "一つの" 戻り値にしたとき
影響範囲はオブジェクトの内部状態を変えるのと同じことになってるという話をしてる
例えばボタンのスタイルは前景色、背景色、座標、フォント、余白などいろんなスタイルあるが
オブジェクト指向ではボタンのスタイルとしてオブジェクトの内部状態に組み込んでる
これらの前景色、背景色、座標、フォント、余白などをあわせてスタイルオブジェクトとして
関数からスタイルオブジェクトを返すからテストしやすい！といっても
何がテストしやすいのさっぱりわからない 色を変える関数を作るとするならば
スタイルオブジェクト = setColor(スタイルオブジェクト, 色）
これが関数型
この時、setColorがどの属性をいじるかなんてコードを見ないとわからない ボタンのスタイルオブジェクトの場合、関数型ではこうなるのだろうか？
ボタン.スタイル = setColor(ボタン.スタイル, 色）
本質的に関数型に適合しないようなものを
無理やり関数型にしても意味ないよ どこに状態持っとくかで状態管理のしやすさが変わるんだよな
あるComponentでそれと関係のない状態変数が無造作に置かれてるよりは
必要な場所からのみアクセスできるようになってるほうがありがたい
必要ない場所でその状態変数について気にしなくていいから >>353はドットでつないでるから関数型には見えないｗ
実際はこうなのだろうか？
ボタン = setStyleColor(ボタン, 色）
ボタンには色以外の複数のスタイル属性や
ボタンの有効無効などの属性を持っている
つまりsetStyleColorという関数は
ボタンという連想配列データの一部分をいじる関数になる
それはオブジェクト指向でボタン.スタイル.setColor(色）の場合に
色というメンバ変数を書き換えてるのと大差ない >>354
そうやってできたのがオブジェクト指向やなｗ 関数型Windowsが出せなければ、Windowsは無くなるだろな。 >>358
何年以内に？ｗ
ま、それを明言するだけの勇気はお前にないだろうね >>351
オブジェクトとして永続的に存在するものと単なる戻り値が同じわけないだろう。
戻り値として返されたオブジェクトをすぐに破棄するってんならまぁわかるが。 俺はこれはある意味何かが起きると思ってんだよ。
賢い奴ら数名は気が付いているようだが。
今頃オブジェクト最強とか言ってるようでは気づけんだろうけど。 >>362
いつまでに？
そのうち何かが起きるという予言は
宇宙の歴史から見ればそのうち当たるだろう
程度の話でしかないよ 30年かかると思うよ。
でもWindowsは3年でなくなるだろな。
Windowsが30年かけて地位を築いたように。
関数型ウィンドウも30年かけて地位を築く。 ■ このスレッドは過去ログ倉庫に格納されています
