カプセル化の有害性、オブジェクト指向は愚かな考え

**デフォルトの名無しさん** · 2020/06/18(木) 23:47:36.69

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。

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

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

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/06/27(土) 07:01:10.93

>>285
きっと>>282は
小さな趣味プログラムでも大きな業務プログラムでも
ほらね、カプセル化したコーディングだとあーだこーだ
だからいったじゃん
「カプセル化は絶対にやめろ！」
という結論にもっていきたいだけだお

**デフォルトの名無しさん** · 2020/06/27(土) 07:42:28.66

「オブジェクト指向は高度で複雑な事をやる技術者
だけが恩恵を受けられるもので簡単なシステム
書いてるような凡人プログラマは恩恵を
感じにくい。」

だったら入門書でそんなもの教えるな
初心者プログラマにソケット通信や
システムコールやカーネルみたいな話を
いきなり教えるんか？

**デフォルトの名無しさん** · 2020/06/27(土) 07:44:28.06

凡人にとってオブジェクト指向は
邪魔でしかないんだよ。

高度な技術者の勝手な利便性を
凡人に押し付けるな。
凡人の方が大多数なんだよ。

**デフォルトの名無しさん** · 2020/06/27(土) 07:54:23.66

何でプログラムやってるんだ？
もっと簡単なことがあるだろ

**デフォルトの名無しさん** · 2020/06/27(土) 08:29:03.79

>>286
どうだろ。
staticおじさん(「オブジェクト指向ってしっくりこないんです」の記事を書いて炎上、詭弁を重ねて意固地にstaticを薦めた有名な老害)じゃないのなら、まだ、大丈夫なんじゃね？

**デフォルトの名無しさん** · 2020/06/27(土) 08:38:52.96

それ以前に、カプセル化は絶対駄目の結論に持っていこうとしているのか？
日が変わるとID変わるから、誰が誰だかよくわからなくなってきた...。

**デフォルトの名無しさん** · 2020/06/27(土) 09:43:50.27

何事も程度次第
ただ丁度良い程度を知るのは少数の天性のセンス持ちだけで
凡人には理解できなかったり極端に走ったりする

俺は凡人とセンス持ちの間、というか凡人の域を超えられないのかなあ
プログラム書くたびにどの程度で済ませるか、いつも迷ってる

**デフォルトの名無しさん** · 2020/06/27(土) 10:00:13.69

OOP批判の大半はクラス設計の難しさによる
OOPによってもたらされたクラスライブラリが
十分に使いやすいのに対して
自分でクラスやインタフェースを作ろうとしたとき
納得の行かない結果になる

問題の切り分けが出来ず
再利用性のある単位ぴったりにフォーカスできず
一緒にあるべきものを別にしたり
別にあるべきものを一緒にしたり
縦に割る物を横に割ろうとしたり
いろんな判断をあやまった結果

最後に、クラス設計が悪いのではなくてOOPそのものが悪いと断ずる

**デフォルトの名無しさん** · 2020/06/27(土) 10:09:46.57

>>287
別に初心者だってオブジェクト指向の恩恵は受けられるだろう。良くあるコンテナや文字列とかの基本的なものだってオブジェクト指向的なものだし。

それに初心者の内からオブジェクト指向について知っておく、慣れておくことは重要だろう。
世の中の便利なライブラリやフレームワーク等の多くはオブジェクト指向で作られているからそれを使えるようになるために必要。
自分で設計するのも初めは難しいが、理屈や理論を学びながら実例に触れ、試行錯誤しながら徐々に慣れていく。

何より、初心者だからとオブジェクト指向をまったく触れずに手続き型のみで経験を積んで、ある程度自分なりのノウハウや経験論を身に付けてから別のパラダイムを取り入れようとすると、中にはアレルギー反応を起こして適応できなくなってしまう人もごく稀にいるから。

**デフォルトの名無しさん** · 2020/06/27(土) 10:47:57.21

長い上に全く中身がないな
スッキリ以上のオブジェクト指向のメリットは出てないからね

これで技術者やってるつもりなんだから早く死ねよ

**デフォルトの名無しさん** · 2020/06/27(土) 11:57:57.12

>>295
お前の無駄口程、無駄な発言は無いけどな。

**デフォルトの名無しさん** · 2020/06/27(土) 12:40:58.84

カプセル化って別に外部からのアクセスを不能にすることじゃないよ
外部から『直接的』にアクセスさせることを避けて、そのかわり外部向けにわかりやすい何かを提供すること
現実のカプセルのように、扱いにくいものを隠して扱いやすく提供すること
別にカプセル化してもリフレクションやその他諸々で遠回りなアクセスが可能なこともある
カプセル化ってのはかなり意味の広い言葉で、「臭いものに蓋」みたいなこと全般をカプセル化と呼ぶ
極端な例だと、関数にわかりやすい名前をつけることで関数内部を見なくて済むようにすることもカプセル化と呼ぶ

**デフォルトの名無しさん** · 2020/06/27(土) 12:43:14.13

>>288
いやいや兵隊がよくわからないのに使えるするのが
オブジェクト指向の利点の一つだろ　つかそれができないなら
オブジェクト指向にする意義がない　まあ兵隊がよくわからないのに
使えるぐらいのオブジェクト指向ができるなら、設計した本人たちは
そもそもオブジェクト指向にしなくても出来ちゃうって逆説はあるわな

**デフォルトの名無しさん** · 2020/06/27(土) 13:14:49.52

>>293
その通りだと思う
オブジェクト指向で作られたOSSの、ライブラリは
とても便利だし、役に立つと思う。

なら初心者や凡人へはクラスをインポートして使い方
のみを教えるべきで、クラスの作り方なんて
教えない方が親切だと思う

正直、自分でクラスなんて作りたくないし
組織内のメンバーが作成したローカル内の
クラスなんて利用や継承したくないし
自分が作ったクラスを誰かに利用して
欲しくない、使い捨てで十分。
再利用性は以前自分が書いたコードを複製
して微修正すればいいよ、
自分が書いたコードだから修正箇所は
把握してる。

JavaScriptやpyみたいな言語はオブジェクト指向
導入してるけどクラスの作成は必須じゃない
だけどJavaみたいな静的言語はクラスの作成が
必須になってる。ここがおかしいと思う。
クラス作ること強制してる言語仕様やフレームワークは
おかしいと思う。

**デフォルトの名無しさん** · 2020/06/27(土) 13:26:54.01

再利用しない前提ならそりゃ無用の長物だわな

**デフォルトの名無しさん** · 2020/06/27(土) 13:45:44.90

そして再利用しようとすると微妙に仕様が変わって結局中身を改造しないといけなくなる罠。
汎用的なパーツ以外はクラス化すると余計手間かかるな。

**デフォルトの名無しさん** · 2020/06/27(土) 13:51:13.06

なんというかprivate云々とかそういう次元の話じゃないよねこれ
なんか脱力した

**デフォルトの名無しさん** · 2020/06/27(土) 13:56:46.31

再利用しなくてもテストしやすくなったりするからオブジェクトは素敵な概念だと思うよ

**デフォルトの名無しさん** · 2020/06/27(土) 13:58:08.98

修正が必要になったとき、それを使う側に影響を与えないっていう性質があっていっぱいちゅき

**デフォルトの名無しさん** · 2020/06/27(土) 13:58:50.41

まあ修正の程度にもよるんですけどね！(げきおこ

**デフォルトの名無しさん** · 2020/06/27(土) 14:06:34.44

JavaをdisるJava全否定のスレッドなのね

**デフォルトの名無しさん** · 2020/06/27(土) 14:13:22.91

このスレタイの主張、可能なら複数の言語で、
オブジェクト指向で書かれたそれなりの量のコードを、
それより機能的で保守性があって行数も少なくて万人が読みやすいようにリファクタリングするとかして証明して欲しいなあ

それがプログラマの矜持ってもんだと思う
コードで語れってね

**デフォルトの名無しさん** · 2020/06/27(土) 14:22:56.55

>>273
カプセル化はC言語でもできる。

**デフォルトの名無しさん** · 2020/06/27(土) 14:23:12.65

バカなやつほど長文で演説した挙げ句オブジェクト指向のメリットをスッキリ以上のモノを挙げられない
レスしにくるなよ惨めだから

**デフォルトの名無しさん** · 2020/06/27(土) 14:26:38.74

>>282
一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
データベースに出し入れする際の受け皿となる構造体が1層あるくらいだろ。

そもそもRDBは階層構造そのままぶち込めないし。

**デフォルトの名無しさん** · 2020/06/27(土) 14:34:40.99

>>307
最近流行りのPythonで作られたシステムを見て回れば？
カプセル化は言語仕様で禁止されてるから強制的に>>1の言うとおりに作るしかない。

**デフォルトの名無しさん** · 2020/06/27(土) 14:37:58.51

>>307
というか最初の開発で問題になるようなことではないからソースコードでは比較できないでしょ。
機能追加・改修案件で発生する問題の話だし。

**デフォルトの名無しさん** · 2020/06/27(土) 14:50:29.02

初めに赤字が出たら続きはねーよｗ

**デフォルトの名無しさん** · 2020/06/27(土) 15:01:24.90

これオブジェクト指向の善し悪しじゃないよね。
改修発生時に雲の上で決まった無茶な追加仕様にどれだけ耐えられる構造にできるかという話だ。

ただオブジェクト指向は昔ながらの教科書どおりにやると耐えられない構造になりがち。
もちろんオブジェクト指向でなくても発生する。
C言語でも発生する。

そうならないようコーディングの約束事を決めよう。
そうなってないかコードレビューはしっかりやろう。

**デフォルトの名無しさん** · 2020/06/27(土) 15:03:08.36

>>311
へーPythonにはアクセス修飾子がないんだ知らなかった
命名規則でこれはprivateなものだよと示すわけね
JavaScriptみたい

**デフォルトの名無しさん** · 2020/06/27(土) 15:04:29.05

>>311
>カプセル化は言語仕様で禁止されてるから

ソースは？

**デフォルトの名無しさん** · 2020/06/27(土) 15:09:38.92

Pythonにアクセス修飾子がないことはググればわかるじゃん

**デフォルトの名無しさん** · 2020/06/27(土) 15:09:51.10

ソースは僕だ！

**デフォルトの名無しさん** · 2020/06/27(土) 15:10:07.03

>>316
https://www.python.org/downloads/source/

**デフォルトの名無しさん** · 2020/06/27(土) 15:10:51.38

マヨネーズの君とソースの僕

**デフォルトの名無しさん** · 2020/06/27(土) 15:12:52.88

>>310
構造体が別の構造体を参照してるデータ構造は階層構造とは呼ばないということかな？

階層構造の深さがカプセル化やオブジェクト指向と何の関係があるの？

**デフォルトの名無しさん** · 2020/06/27(土) 15:13:38.77

そう言えば日本の業務形態には貧血ドメインの方がよく適合するなんて話があったなあ
貧血って言うと悪い印象があるからシンドメインとかスリムドメインに言い換えて
スリムドメインの方が優れてるんだって風潮がそろそろ出てきても良いと思う

**デフォルトの名無しさん** · 2020/06/27(土) 15:14:18.21

>>317
“アクセス修飾子がない” == “カプセル化が言語仕様で禁止されてる”
=> False

**デフォルトの名無しさん** · 2020/06/27(土) 15:15:51.79

>>321
それただのポインタだろ

**デフォルトの名無しさん** · 2020/06/27(土) 15:18:13.32

そもそも、一昔前ならソフトウェアは
製品化して値段を付けて売るって考えがあったから
保守や仕様変更の影響範囲について関心が高かった。
だからオブジェクト指向は必要だったかもしれない

だが現在ではソフトウェアは基本無料が当たり前だし
プロジェクト依頼元の依頼を受けてオーダーメイドで
システムを作るから依頼元だけが金を払ってくれるの
であって
あとはスマホアプリを無料配布して
そのアプリで課金してもらって金を稼ぐみたいな
稼ぎ方だから、ソフトウェア自体に売却する価値はない。
売却する資産価値がないからオブジェクト指向で
保守する価値がない、使い捨てにすればいい。

実際、スマホアプリとかのほとんどが軽微なバグ
とか沢山潜んだままリリースされていて、ずっと
放置されてたりするじゃん。

**デフォルトの名無しさん** · 2020/06/27(土) 15:19:44.46

>>321
ポインタは横の繋がり
上下関係ではない

深い階層化というのは、雲の上で決まった仕様に底辺開発者は意見できないということ。

深い階層化というのは、底辺開発者が受けてるパワハラなど雲の上は知らないということ。

**デフォルトの名無しさん** · 2020/06/27(土) 15:20:21.12

>>323
では君と僕のカプセル化の定義が異なるだけじゃん
君のカプセル化の定義で僕が言ってることを解釈するからFalseになる
僕が言ってることは僕の定義で解釈したらTrueになる
アクセス修飾子が存在することをカプセル化可能と定義します
よろしくおねがいします

**デフォルトの名無しさん** · 2020/06/27(土) 15:23:36.87

>>327
“カプセル化可能” == “言語仕様でカプセル化を禁止している”
#=> False

**デフォルトの名無しさん** · 2020/06/27(土) 15:25:23.02

>>328
だからさー君のカプセル化の定義を知らないしそれを言ってもらわないことには
真偽値だけ言われても僕どうしたらいいかわからないよーえーん(T_T)

**デフォルトの名無しさん** · 2020/06/27(土) 15:26:25.05

カプセル化とはアクセス修飾子でprivateにできることを言います

**デフォルトの名無しさん** · 2020/06/27(土) 15:28:46.34

本当に？

**デフォルトの名無しさん** · 2020/06/27(土) 15:31:32.87

>>326

>>310
>一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。

このレスに書いてる”階層構造”の定義を聞いてるに
全く違う”階層化”の話を出されても困る
特に考えてなかったんなら別にそれで構わない

**デフォルトの名無しさん** · 2020/06/27(土) 15:32:44.69

>>328
バグってた

“カプセル化不可能” == “言語仕様でカプセル化を禁止している”
#=> False

**デフォルトの名無しさん** · 2020/06/27(土) 15:40:51.44

>>332
データベースで深い階層化が起こるとすれば、
・データベースの出し入れはストアドプロシージャ経由のみ
・誰かが作ったストアドプロシージャを叩くライブラリ
・末端開発者が見えるのはライブラリのみ

という状況

**デフォルトの名無しさん** · 2020/06/27(土) 15:45:38.60

>>331
ホントっす

**デフォルトの名無しさん** · 2020/06/27(土) 15:46:26.65

ちがうよ

**デフォルトの名無しさん** · 2020/06/27(土) 15:46:32.04

>>333
なんでFalseになるか説明できる？
できないんだったら君は間違ってる

**デフォルトの名無しさん** · 2020/06/27(土) 15:47:10.15

>>336
何が違うんですか！？なんでですか？説明してください！

**デフォルトの名無しさん** · 2020/06/27(土) 15:47:49.36

内包してない？

**デフォルトの名無しさん** · 2020/06/27(土) 15:48:03.17

>>338
定義が違うから説明しろと言われても困る

**デフォルトの名無しさん** · 2020/06/27(土) 15:48:32.24

>>340
説明くらいできるだろハゲ、横着すんな

**デフォルトの名無しさん** · 2020/06/27(土) 15:48:33.70

ぬるぽ

**デフォルトの名無しさん** · 2020/06/27(土) 15:52:34.57

>>341
>>294

**デフォルトの名無しさん** · 2020/06/27(土) 15:53:17.57

>>341
安価ミス
>>297

**デフォルトの名無しさん** · 2020/06/27(土) 15:53:25.63

>>343
なるほどね、アレルギーが、そういうことね

**デフォルトの名無しさん** · 2020/06/27(土) 15:53:46.87

恥かいた

**デフォルトの名無しさん** · 2020/06/27(土) 15:54:37.70

安価ミスってんじゃないよ！！
納得した僕が馬鹿みたいでしょうが！！

**デフォルトの名無しさん** · 2020/06/27(土) 15:55:00.35

馬鹿なんじゃないの？

**デフォルトの名無しさん** · 2020/06/27(土) 15:56:18.48

ああもうめちゃくちゃだよ！

**デフォルトの名無しさん** · 2020/06/27(土) 16:01:21.18

何やってんだおめーら。
そのへんでやめとき。

**デフォルトの名無しさん** · 2020/06/27(土) 16:02:43.02

カプセル化には強度があります。

C言語のヘッダやJavaのprivateといった言語機能として
カプセル化できることを強カプセル化と言います

JavaScriptやPythonのように命名規則によって使用者に
知らせるカプセル化のことを弱カプセル化と言うのです。

>>348 僕のこと見直してくれてもいいです

**デフォルトの名無しさん** · 2020/06/27(土) 17:08:00.05

カプセル化こそ
すでに時代遅れだったんじゃねーの？

**デフォルトの名無しさん** · 2020/06/27(土) 17:38:28.03

>>351
頭悪そう

**デフォルトの名無しさん** · 2020/06/27(土) 17:59:51.27

>>353
嘘つき！

**デフォルトの名無しさん** · 2020/06/27(土) 18:27:35.27

>>351
これまでの話を統合した結論として、

いまはgitなどバージョン管理差分確認ツールや
エディタやIDEの機能が充実してるから

言語機能でカプセル化して
「内部を意識しない」ように隠蔽したり制限するのではなく
開発ツールを駆使して内部を意識はするけど
ソースの仕様変更切り替えに対応しやすくなっている
やり方が主流

開発ツール進化によりカプセル化はその役割を終えた。
継承や抽象クラスやオーバーライドも非推奨
これをやると同じ名前のメソッドが沢山あって
IDEによるプロジェクト内キーワード全文検索を
阻害するから

**デフォルトの名無しさん** · 2020/06/27(土) 18:38:03.92

>>355
カプセル化しなかったら仕様変更がしやすいのか、なるほど

**デフォルトの名無しさん** · 2020/06/27(土) 18:45:55.84

>>356
読解を間違えています

カプセル化をしないことで仕様変更しやすくなるのではなく

カプセル化を「しなくても」代わりに
開発ツールが充実してるから
ブランチ切り替えや差分確認でスマートな
仕様変更と仕様切り替えが可能です。
だからカプセル化はもう不要になりました。

**デフォルトの名無しさん** · 2020/06/27(土) 18:50:33.85

それはカプセル化の使用有無に関係ないのでは

**デフォルトの名無しさん** · 2020/06/27(土) 18:52:34.90

>>357
カプセル化せずに発生するオブジェクトを破壊するような変更を
差分確認で見つけ出せるわけですね、差分確認が重要ですね

**デフォルトの名無しさん** · 2020/06/27(土) 18:54:31.03

>>355
×これまでの話を統合した結論として
◯これまでの話はすっ飛ばしてボクの言いたいことだけを言うと

**デフォルトの名無しさん** · 2020/06/27(土) 19:01:29.07

IDEの助けがあるとは言え、grepした時の重複は勘弁して欲しい。
どれやねんっていつも思う。
本当にOOPってメンテしやすいんだろうか？

**デフォルトの名無しさん** · 2020/06/27(土) 19:03:28.66

わかりました、grepを禁止します！

**デフォルトの名無しさん** · 2020/06/27(土) 19:07:51.73

世界的超人気言語はC言語、Java、Pythonと変遷していってるわけだけれども
たしかにカプセル化の機能は時代とともに弱まってるように見える

**デフォルトの名無しさん** · 2020/06/27(土) 19:10:52.99

>>359
そのオブジェクト破壊って一体何を意味してる？

多少オブジェクトが破壊されたところで
アプリは動くしすぐバグになる訳じゃないだろう。
多少経験あるプログラマなら知らないオブジェクトへの
破壊的代入は軽率にはやらないだろうし、
オブジェクトのバックアップ変数作ったり少し考えれば
それくらいやるだろう。

やる時はどうしてもやる時はそうせざるを得ないからやる訳で
破壊するのにもそれなりの理由があるんだよ。
それをprivateとかprotectedするなんて余計なお節介
もいいところ
そして、そういう操作の是非は
gitでコードレビューできるだろ。

**デフォルトの名無しさん** · 2020/06/27(土) 19:13:53.12

カプセル化って一種の安全装置なわけだし、作業性とはトレードオフに
なるわな　どちらかを選択するなら当然安全装置を選択するが

**デフォルトの名無しさん** · 2020/06/27(土) 19:26:08.84

使い捨てだの再利用しないだの
素晴らしい含蓄をみずほレベルの巨大案件に適用してれば歴史が変わっていたかも知れない

**デフォルトの名無しさん** · 2020/06/27(土) 19:29:44.84

>>364
Javaでいうところのprivateやprotectedの値を書き換えたり参照したりといったことを
オブジェクトの破壊と言ってます
コードレビューできるっていうのはそれをやらないと洗い出せないってことでしょ
カプセル化の機能を使っていれば実装時に気付けることをレビューまで先延ばしにすることによって
得られることがそんなに多いのですかね

**デフォルトの名無しさん** · 2020/06/27(土) 19:37:50.49

たとえばこの先Pythonが、名前が_から始まるメンバに外からアクセスすると
構文エラーになるようになった場合、動作するプログラムにカプセル化を破壊するような
操作がないことは明白になるのでとても便利だと思います

**デフォルトの名無しさん** · 2020/06/27(土) 19:42:29.28

Pythonぐらいの緩さが一番バランスいい気がする
人気があるのも納得

**デフォルトの名無しさん** · 2020/06/27(土) 19:44:24.05

>>368
dart的な感じ？

**デフォルトの名無しさん** · 2020/06/27(土) 19:50:55.69

>>370
そうです、そのdart的な感じです
dartを使ったことがないので僕は知りませんけど

**デフォルトの名無しさん** · 2020/06/27(土) 19:53:28.59

アクセス修飾子でアクセス制限をかけてしまうと
テストすることさえできなくなります
これがカプセル化の圧倒的な弱点です

**デフォルトの名無しさん** · 2020/06/27(土) 19:55:33.60

privateではありつつもテスト時などにアクセス可能なバックドアが必要で、それが現代のプログラミング言語には欠けていると思います

**デフォルトの名無しさん** · 2020/06/27(土) 20:15:27.61

>>373
そのへんJavaとかリフレクション駆使して回避してるので構造的、致命的な欠点とは言い切れないと思うよ。
リフレクションがバックドアと言われたらそれはその通りなので反論できないけど。

**デフォルトの名無しさん** · 2020/06/27(土) 20:17:13.10

グローバル変数使用禁止の
public staticが唯一無二の解決策だというのにわからん奴がいるな

**デフォルトの名無しさん** · 2020/06/27(土) 20:34:22.57

>>373
テストでアクセスするならそれはpublicにすべきもの
言い換えると、テストですらアクセスしないものをprivateにする

**デフォルトの名無しさん** · 2020/06/27(土) 20:35:14.22

>>372
テストするならpublicにすればいいだけ

**デフォルトの名無しさん** · 2020/06/27(土) 20:39:11.40

まず重要な前提として
システムの仕様変更というのは
appのソースコードの変更だけではない。
データベースの変更や接続してる外部サーバや
ストレージに関連する仕様変更とかもある。

そして、カプセル化を初めとするオブジェクト指向の
設計技法はメモリ内の瞬間的なごく狭い範囲の
事しか考えてない。

外部環境の仕様が変わったり、フェイルオーバーなどの
不具合が起きてシステム全体のデバッグしたり
不具合調査するときに、app層がカプセル化されていたり
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
想像に難くないと思う。

仮想化やクラウド化が進んでる最近では
こういう外部環境の隠蔽は逆に困るんだよ。

**デフォルトの名無しさん** · 2020/06/27(土) 20:46:30.95

>>378
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
逆説的だがこれが利点の一つなんだ　手続き型だと
直したつもりになることが多々あり　新たなバクを生む
時間が多少かかっても形式的に処理するべき

**デフォルトの名無しさん** · 2020/06/27(土) 20:59:08.97

>>376
それはないわー
テストは全メソッドやるでしょ
全部publicにしなければいけないなんて間違ってると思います！
僕はそれ間違ってると思います！

**デフォルトの名無しさん** · 2020/06/27(土) 21:00:30.56

>>377
publicにしたら別のオブジェクトからアクセスされちゃうじゃん
そのメソッドは内部の状態と深い関わりがあって勝手に呼ばれると困っちゃうの
みたいなことあるじゃんテストのときだけpublicにするのはヤリマンだし

**デフォルトの名無しさん** · 2020/06/27(土) 21:03:21.73

テストを別オブジェクトにするのが間違ってるのかもわからんね
データと関数をセットにしたものをオブジェクトと呼ぶように
データと関数とテストをセットにした自己メンテナンス完結型のものをアクターと呼ぶことにしようよ！

**デフォルトの名無しさん** · 2020/06/27(土) 21:13:44.71

>>380
> テストは全メソッドやるでしょ

全メソッドやるかどうかはその人次第
テストするならpublicにする
それだけの話

テストするということは、そのインターフェースは
外部から使用しても良いということを意味する
テストされてるんだから仕様が変わったりしない

**デフォルトの名無しさん** · 2020/06/27(土) 21:14:19.20

>>381
> publicにしたら別のオブジェクトからアクセスされちゃうじゃん

アクセスしても問題ないだろ？
アクセスしても問題ないようにテストしてるんだから

**デフォルトの名無しさん** · 2020/06/27(土) 21:32:11.55

>>384
いやいや、公開する必要のないメソッドを公開する意味がない
呼ばれちゃいけないタイミングはある、テストしてるかどうかとは関係ない

テストしてないコードはバグってるよ
人の問題で片付けてはいけない