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

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

[前50を表示]
300:デフォルトの名無しさん
20/06/27 08:29:03.79 0UrSdNRf.net
>>286
どうだろ。
staticおじさん(「オブジェクト指向ってしっくりこないんです」の記事を書いて炎上、詭弁を重ねて意固地にstaticを薦めた有名な老害)じゃないのなら、まだ、大丈夫なんじゃね？

301:デフォルトの名無しさん
20/06/27 08:38:52.96 0UrSdNRf.net
それ以前に、カプセル化は絶対駄目の結論に持っていこうとしているのか？
日が変わるとID変わるから、誰が誰だかよくわからなくなってきた...。

302:デフォルトの名無しさん
20/06/27 09:43:50.27 8YCrt6Qf.net
何事も程度次第
ただ丁度良い程度を知るのは少数の天性のセンス持ちだけで
凡人には理解できなかったり極端に走ったりする
俺は凡人とセンス持ちの間、というか凡人の域を超えられないのかなあ
プログラム書くたびにどの程度で済ませるか、いつも迷ってる

303:デフォルトの名無しさん
20/06/27 10:00:13.69 pgI/H4Wp.net
OOP批判の大半はクラス設計の難しさによる
OOPによってもたらされたクラスライブラリが
十分に使いやすいのに対して
自分でクラスやインタフェースを作ろうとしたとき
納得の行かない結果になる
問題の切り分けが出来ず
再利用性のある単位ぴったりにフォーカスできず
一緒にあるべきものを別にしたり
別にあるべきものを一緒にしたり
縦に割る物を横に割ろうとしたり
いろんな判断をあやまった結果
最後に、クラス設計が悪いのではなくてOOPそのものが悪いと断ずる

304:デフォルトの名無しさん
20/06/27 10:09:46.57 twDHZDh4.net
>>287
別に初心者だってオブジェクト指向の恩恵は受けられるだろう。良くあるコンテナや文字列とかの基本的なものだってオブジェクト指向的なものだし。
それに初心者の内からオブジェクト指向について知っておく、慣れておくことは重要だろう。
世の中の便利なライブラリやフレームワーク等の多くはオブジェクト指向で作られているからそれを使えるようになるために必要。
自分で設計するのも初めは難しいが、理屈や理論を学びながら実例に触れ、試行錯誤しながら徐々に慣れていく。
何より、初心者だからとオブジェクト指向をまったく触れずに手続き型のみで経験を積んで、ある程度自分なりのノウハウや経験論を身に付けてから別のパラダイムを取り入れようとすると、中にはアレルギー反応を起こして適応できなくなってしまう人もごく稀にいるから。

305:デフォルトの名無しさん
20/06/27 10:47:57.21 n2G2JMaM.net
長い上に全く中身がないな
スッキリ以上のオブジェクト指向のメリットは出てないからね
これで技術者やってるつもりなんだから早く死ねよ

306:デフォルトの名無しさん
20/06/27 11:57:57.12 0UrSdNRf.net
>>295
お前の無駄口程、無駄な発言は無いけどな。

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

308:デフォルトの名無しさん
20/06/27 12:43:14.13 npRplKHX.net
>>288
いやいや兵隊がよくわからないのに使えるするのが
オブジェクト指向の利点の一つだろ　つかそれができないなら
オブジェクト指向にする意義がない　まあ兵隊がよくわからないのに
使えるぐらいのオブジェクト指向ができるなら、設計した本人たちは
そもそもオブジェクト指向にしなくても出来ちゃうって逆説はあるわな

309:デフォルトの名無しさん
20/06/27 13:14:49.52 e0+LQFD/.net
>>293
その通りだと思う
オブジェクト指向で作られたOSSの、ライブラリは
とても便利だし、役に立つと思う。
なら初心者や凡人へはクラスをインポートして使い方
のみを教えるべきで、クラスの作り方なんて
教えない方が親切だと思う
正直、自分でクラスなんて作りたくないし
組織内のメンバーが作成したローカル内の
クラスなんて利用や継承したくないし
自分が作ったクラスを誰かに利用して
欲しくない、使い捨てで十分。
再利用性は以前自分が書いたコードを複製
して微修正すればいいよ、
自分が書いたコードだから修正箇所は
把握して

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

311:デフォルトの名無しさん
20/06/27 13:26:54.01 eG65KKvD.net
再利用しない前提ならそりゃ無用の長物だわな

312:デフォルトの名無しさん
20/06/27 13:45:44.90 ssxfEnBq.net
そして再利用しようとすると微妙に仕様が変わって結局中身を改造しないといけなくなる罠。
汎用的なパーツ以外はクラス化すると余計手間かかるな。

313:デフォルトの名無しさん
20/06/27 13:51:13.06 eG65KKvD.net
なんというかprivate云々とかそういう次元の話じゃないよねこれ
なんか脱力した

314:デフォルトの名無しさん
20/06/27 13:56:46.31 kHv6hhb8.net
再利用しなくてもテストしやすくなったりするからオブジェクトは素敵な概念だと思うよ

315:デフォルトの名無しさん
20/06/27 13:58:08.98 kHv6hhb8.net
修正が必要になったとき、それを使う側に影響を与えないっていう性質があっていっぱいちゅき

316:デフォルトの名無しさん
20/06/27 13:58:50.41 kHv6hhb8.net
まあ修正の程度にもよるんですけどね！(げきおこ

317:デフォルトの名無しさん
20/06/27 14:06:34 UiFDXh57.net
JavaをdisるJava全否定のスレッドなのね

318:デフォルトの名無しさん
20/06/27 14:13:22 UrcM2fcl.net
このスレタイの主張、可能なら複数の言語で、
オブジェクト指向で書かれたそれなりの量のコードを、
それより機能的で保守性があって行数も少なくて万人が読みやすいようにリファクタリングするとかして証明して欲しいなあ

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

319:デフォルトの名無しさん
20/06/27 14:22:56.55 Z/pHF8i9.net
>>273
カプセル化はC言語でもできる。

320:デフォルトの名無しさん
20/06/27 14:23:12.65 1p1mL4Jd.net
バカなやつほど長文で演説した挙げ句オブジェクト指向のメリットをスッキリ以上のモノを挙げられない
レスしにくるなよ惨めだから

321:デフォルトの名無しさん
20/06/27 14:26:38.74 Z/pHF8i9.net
>>282
一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
データベースに出し入れする際の受け皿となる構造体が1層あるくらいだろ。
そもそもRDBは階層構造そのままぶち込めないし。

322:デフォルトの名無しさん
20/06/27 14:34:40.99 Z/pHF8i9.net
>>307
最近流行りのPythonで作られたシステムを見て回れば？
カプセル化は言語仕様で禁止されてるから強制的に >>1の言うとおりに作るしかない。

323:デフォルトの名無しさん
20/06/27 14:37:58 Z/pHF8i9.net
>>307
というか最初の開発で問題になるようなことではないからソースコードでは比較できないでしょ。
機能追加・改修案件で発生する問題の話だし。

324:デフォルトの名無しさん
20/06/27 14:50:29.02 1p1mL4Jd.net
初めに赤字が出たら続きはねーよｗ

325:デフォルトの名無しさん
20/06/27 15:01:24.90 Z/pHF8i9.net
これオブジェクト指向の善し悪しじゃないよね。
改修発生時に雲の上で決まった無茶な追加仕様にどれだけ耐えられる構造にできるかという話だ。
ただオブジェクト指向は昔ながらの教科書どおりにやると耐えられない構造になりがち。
もちろんオブジェクト指向でなくても発生する。
C言語でも発生する。
そうならないようコーディングの約束事を決めよう。
そうなってないかコードレビューはしっかりやろう。

326:デフォルトの名無しさん
20/06/27 15:03:08.36 kHv6hhb8.net
>>311
へーPythonにはアクセス修飾子がないんだ知らなかった
命名規則でこれはprivateなものだよと示すわけね
JavaScriptみたい

327:デフォルトの名無しさん
20/06/27 15:04:29.05 qJyof1ZF.net
>>311
>カプセル化は言語仕様で禁止されてるから
ソースは？

328:デフォルトの名無しさん
20/06/27 15:09:38.92 kHv6hhb8.net
Pythonにアクセス修飾子がないことはググればわかるじゃん

329:デフォルトの名無しさん
20/06/27 15:09:51.10 kHv6hhb8.net
ソースは僕だ！

330:デフォルトの名無しさん
20/06/27 15:10:07.03 Z/pHF8i9.net
>>316
URLﾘﾝｸ(www.python.org)

331:デフォルトの名無しさん
20/06/27 15:10:51.38 kHv6hhb8.net
マヨネーズの君とソースの僕

332:デフォルトの名無しさん
20/06/27 15:12:52.88 qJyof1ZF.net
>>310
構造体が別の構造体を参照してる

333:データ構造は階層構造とは呼ばないということかな？階層構造の深さがカプセル化やオブジェクト指向と何の関係があるの？

334:デフォルトの名無しさん
20/06/27 15:13:38.77 kHv6hhb8.net
そう言えば日本の業務形態には貧血ドメインの方がよく適合するなんて話があったなあ
貧血って言うと悪い印象があるからシンドメインとかスリムドメインに言い換えて
スリムドメインの方が優れてるんだって風潮がそろそろ出てきても良いと思う

335:デフォルトの名無しさん
20/06/27 15:14:18.21 qJyof1ZF.net
>>317
“アクセス修飾子がない” == “カプセル化が言語仕様で禁止されてる”
=> False

336:デフォルトの名無しさん
20/06/27 15:15:51.79 Z/pHF8i9.net
>>321
それただのポインタだろ

337:デフォルトの名無しさん
20/06/27 15:18:13.32 e0+LQFD/.net
そもそも、一昔前ならソフトウェアは
製品化して値段を付けて売るって考えがあったから
保守や仕様変更の影響範囲について関心が高かった。
だからオブジェクト指向は必要だったかもしれない
だが現在ではソフトウェアは基本無料が当たり前だし
プロジェクト依頼元の依頼を受けてオーダーメイドで
システムを作るから依頼元だけが金を払ってくれるの
であって
あとはスマホアプリを無料配布して
そのアプリで課金してもらって金を稼ぐみたいな
稼ぎ方だから、ソフトウェア自体に売却する価値はない。
売却する資産価値がないからオブジェクト指向で
保守する価値がない、使い捨てにすればいい。
実際、スマホアプリとかのほとんどが軽微なバグ
とか沢山潜んだままリリースされていて、ずっと
放置されてたりするじゃん。

338:デフォルトの名無しさん
20/06/27 15:19:44.46 Z/pHF8i9.net
>>321
ポインタは横の繋がり
上下関係ではない
深い階層化というのは、雲の上で決まった仕様に底辺開発者は意見できないということ。
深い階層化というのは、底辺開発者が受けてるパワハラなど雲の上は知らないということ。

339:デフォルトの名無しさん
20/06/27 15:20:21.12 kHv6hhb8.net
>>323
では君と僕のカプセル化の定義が異なるだけじゃん
君のカプセル化の定義で僕が言ってることを解釈するからFalseになる
僕が言ってることは僕の定義で解釈したらTrueになる
アクセス修飾子が存在することをカプセル化可能と定義します
よろしくおねがいします

340:デフォルトの名無しさん
20/06/27 15:23:36.87 qJyof1ZF.net
>>327
“カプセル化可能” == “言語仕様でカプセル化を禁止している”
#=> False

341:デフォルトの名無しさん
20/06/27 15:25:23.02 kHv6hhb8.net
>>328
だからさー君のカプセル化の定義を知らないしそれを言ってもらわないことには
真偽値だけ言われても僕どうしたらいいかわからないよーえーん(T_T)

342:デフォルトの名無しさん
20/06/27 15:26:25.05 kHv6hhb8.net
カプセル化とはアクセス修飾子でprivateにできることを言います

343:デフォルトの名無しさん
20/06/27 15:28:46.34 UrcM2fcl.net
本当に？

344:デフォルトの名無しさん
20/06/27 15:31:32.87 qJyof1ZF.net
>>326
>>310
>一般的な業務システムはデータベースに出し入れするだけだから深い階層構造にはならない。
このレスに書いてる”階層構造”の定義を聞いてるに
全く違う”階層化”の話を出されても困る
特に考えてなかったんなら別にそれで構わない

345:デフォルトの名無しさん
20/06/27 15:32:44.69 qJyof1ZF.net
>>328
バグってた
“カプセル化不可能” == “言語仕様でカプセル化を禁止している”
#=> False

346:デフォルトの名無しさん
20/06/27 15:40:51.44 Z/pHF8i9.net
>>332
データベースで深い階層化が起こるとすれば、
・データベースの出し入れはストアドプロシージャ経由のみ
・誰かが作ったストアドプロシージャを叩くライブラリ
・末端開発者が見えるのはライブラリのみ
という状況

347:デフォルトの名無しさん
20/06/27 15:45:38.60 kHv6hhb8.net
>>331
ホントっす

348:デフォルトの名無しさん
20/06/27 15:46:26.65 ut+wnsgT.net
ちがうよ

349:デフォルトの名無しさん
20/06/27 15:46:32.04 kHv6hhb8.net
>>333
なんでFalseになるか説明できる？
できないんだったら君は間違ってる

350:デフォルトの名無しさん
20/06/27 15:47:10.15 kHv6hhb8.net
>>336
何が違うんですか！？なんでですか？説明してください！

351:デフォルトの名無しさん
20/06/27 15:47:49 UrcM2fcl.net
内包してない？

352:デフォルトの名無しさん
20/06/27 15:48:03 ut+wnsgT.net
>>338
定義が違うから説明しろと言われても困る

353:デフォルトの名無しさん
20/06/27 15:48:32 kHv6hhb8.net
>>340
説明くらいできるだろハゲ、横着すんな

354:デフォルトの名無しさん
20/06/27 15:48:33 PPBVSkWl.net
ぬるぽ

355:デフォルトの名無しさん
20/06/27 15:52:34 ut+wnsgT.net
>>341
>>294

356:デフォルトの名無しさん
20/06/27 15:53:17 ut+wnsgT.net
>>341
安価ミス
>>297

357:デフォルトの名無しさん
20/06/27 15:53:25 kHv6hhb8.net
>>343
なるほどね、アレルギーが、そういうことね

358:デフォルトの名無しさん
20/06/27 15:53:46 kHv6hhb8.net
恥かいた

359:デフォルトの名無しさん
20/06/27 15:54:37 kHv6hhb8.net
安価ミスってんじゃないよ！！
納得した僕が馬鹿みたいでしょうが！！

360:デフォルトの名無しさん
20/06/27 15:55:00 ut+wnsgT.net
馬鹿なんじゃないの？

361:デフォルトの名無しさん
20/06/27 15:56:18 e0+LQFD/.net
ああもうめちゃくちゃだよ！

362:デフォルトの名無しさん
20/06/27 16:01:21 7UzCd1n0.net
何やってんだおめーら。
そのへんでやめとき。

363:デフォルトの名無しさん
20/06/27 16:02:43 kHv6hhb8.net
カプセル化には強度があります。

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

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

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

364:デフォルトの名無しさん
20/06/27 17:08:00.05 WDOSBdwF.net
カプセル化こそ
すでに時代遅れだったんじゃねーの？

365:デフォルトの名無しさん
20/06/27 17:38:28.03 ut+wnsgT.net
>>351
頭悪そう

366:デフォルトの名無しさん
20/06/27 17:59:51.27 kHv6hhb8.net
>>353
嘘つき！

367:デフォルトの名無しさん
20/06/27 18:27:35.27 e0+LQFD/.net
>>351
これまでの話を統合した結論として、
いまはgitなどバージョン管理差分確認ツールや
エディタやIDEの機能が充実してるから
言語機能でカプセル化して
「内部を意識しない」ように隠蔽したり制限するのではなく
開発ツールを駆使して内部を意識はするけど
ソースの仕様変更切り替えに対応しやすくなっている
やり方が主流
開発ツール進化によりカプセル化はその役割を終えた。
継承や抽象クラスやオーバーライドも非推奨
これをやると同じ名前のメソッドが沢山あって
IDEによるプロジェクト内キーワード全文検索を
阻害するから

368:デフォルトの名無しさん
20/06/27 18:38:03.92 kHv6hhb8.net
>>355
カプセル化しなかったら仕様変更がしやすいのか、なるほど

369:デフォルトの名無しさん
20/06/27 18:45:55.84 e0+LQFD/.net
>>356
読解を間違えています
カプセル化をしないことで仕様変更しやすくなるのではなく
カプセル化を「しなくても」代わりに
開発ツールが充実してるから
ブランチ切り替えや差分確認でスマートな
仕様変更と仕様切り替えが可能です。
だからカプセル化はもう不要になりました。

370:デフォルトの名無しさん
20/06/27 18:50:33.85 UrcM2fcl.net
それはカプセル化の使用有無に関係ないのでは

371:デフォルトの名無しさん
20/06/27 18:52:34.90 kHv6hhb8.net
>>357
カプセル化せずに発生するオブジェクトを破壊するような変更を
差分確認で見つけ出せるわけですね、差分確認が重要ですね

372:デフォルトの名無しさん
20/06/27 18:54:31.03 twDHZDh4.net
>>355
×これまでの話を統合した結論として
◯これまでの話はすっ飛ばしてボクの言いたいことだけを言うと

373:デフォルトの名無しさん
20/06/27 19:01:29.07 7UzCd1n0.net
IDEの助けがあるとは言え、grepした時の重複は勘弁して欲しい。
どれやねんっていつも思う。
本当にOOPってメンテしやすいんだろうか？

374:デフォルトの名無しさん
20/06/27 19:03:28.66 kHv6hhb8.net
わかりました、grepを禁止します！

375:デフォルトの名無しさん
20/06/27 19:07:51.73 kHv6hhb8.net
世界的超人気言語はC言語、Java、Pythonと変遷していってるわけだけれども
たしかにカプセル化の機能は時代とともに弱まってるように見える

376:デフォルトの名無しさん
20/06/27 19:10:52.99 e0+LQFD/.net
>>359
そのオブジェクト破壊って一体何を意味してる？
多少オブジェクトが破壊されたところで
アプリは動くしすぐバグになる訳じゃないだろう。
多少経験あるプログラマなら知らないオブジェクトへの
破壊的代入は軽率にはやらないだろうし、
オブジェクトのバックアップ変数作ったり少し考えれば
それくらいやるだろう。
やる時はどうしてもやる時はそうせざるを得ないからやる訳で
破壊するのにもそれなりの理由があるんだよ。
それをprivateとかprotectedするなんて余計なお節介
もいいところ
そして、そういう操作の是非は
gitでコードレビューできるだろ。

377:デフォルトの名無しさん
20/06/27 19:13:53.12 npRplKHX.net
カプセル化って一種の安全装置なわけだし、作業性とはトレードオフに
なるわな　どちらかを選択するなら当然安全装置を選択するが

378:デフォルトの名無しさん
20/06/27 19:26:08.84 D2Sdnpa5.net
使い捨てだの再利用しないだの
素晴らしい含蓄をみずほレベルの巨大案件に適用してれば歴史が変わっていたかも知れない

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

380:デフォルトの名無しさん
20/06/27 19:37:50.49 kHv6hhb8.net
たとえばこの先Pythonが、名前が_から始まるメンバに外からアクセスすると
構文エラーになるようになった場合、動作するプログラムにカプセル化を破壊するような
操作がないことは明白になるのでとても便利だと思います

381:デフォルトの名無しさん
20/06/27 19:42:29.28 npRplKHX.net
Pythonぐらいの緩さが一番バランスいい気がする
人気があるのも納得

382:デフォルトの名無しさん
20/06/27 19:44:24.05 7UzCd1n0.net
>>368
dart的な感じ？

383:デフォルトの名無しさん
20/06/27 19:50:55.69 kHv6hhb8.net
>>370
そうです、そのdart的な感じです
dartを使ったことがないので僕は知りませんけど

384:デフォルトの名無しさん
20/06/27 19:53:28.59 kHv6hhb8.net
アクセス修飾子でアクセス制限をかけてしまうと
テストすることさえできなくなります
これがカプセル化の圧倒的な弱点です

385:デフォルトの名無しさん
20/06/27 19:55:33.60 kHv6hhb8.net
privateではありつつもテスト時などにアクセス可能なバックドアが必要で、それが現代のプログラミング言語には欠けていると思います

386:デフォルトの名無しさん
20/06/27 20:15:27.61 7UzCd1n0.net
>>373
そのへんJavaとかリフレクション駆使して回避してるので構造的、致命的な欠点とは言い切れないと思うよ。
リフレクションがバックドアと言われたらそれはその通りなので反論できないけど。

387:デフォルトの名無しさん
20/06/27 20:17:13.10 mehAi5n4.net
グローバル変数使用禁止の
public staticが唯一無二の解決策だというのにわからん奴がいるな

388:デフォルトの名無しさん
20/06/27 20:34:22.57 gS37C1rZ.net
>>373
テストでアクセスするならそれはpublicにすべきもの
言い換えると、テストですらアクセスしないものをprivateにする

389:デフォルトの名無しさん
20/06/27 20:35:14.22 gS37C1rZ.net
>>372
テストするならpublicにすればいいだけ

390:デフォルトの名無しさん
20/06/27 20:39:11.40 e0+LQFD/.net
まず重要な前提として
システムの仕様変更というのは
appのソースコードの変更だけではない。
データベースの変更や接続してる外部サーバや
ストレージに関連する仕様変更とかもある。
そして、カプセル化を初めとするオブジェクト指向の
設計技法はメモリ内の瞬間的なごく狭い範囲の
事しか考えてない。
外部環境の仕様が変わったり、フェイルオーバーなどの
不具合が起きてシステム全体のデバッグしたり
不具合調査するときに、app層がカプセル化されていたり
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
想像に難くないと思う。
仮想化やクラウド化が進んでる最近では
こういう外部環境の隠蔽は逆に困るんだよ。

391:デフォルトの名無しさん
20/06/27 20:46:30.95 npRplKHX.net
>>378
オブジェクト指向の技法が使われているほど
それらが邪魔になってやりにくくなるのは
逆説的だがこれが利点の一つなんだ　手続き型だと
直したつもりになることが多々あり　新たなバクを生む
時間が多少かかっても形式的に処理するべき

392:デフォルトの名無しさん
20/06/27 20:59:08.97 kHv6hhb8.net
>>376
それはないわー
テストは全メソッドやるでしょ
全部publicにしなければいけないなんて間違ってると思います！
僕はそれ間違ってると思います！

393:デフォルトの名無しさん
20/06/27 21:00:30.56 kHv6hhb8.net
>>377
publicにしたら別のオブジェクトからアクセスされちゃうじゃん
そのメソッドは内部の状態と深い関わりがあって勝手に呼ばれると困っちゃうの
みたいなことあるじゃんテストのときだけpublicにするのはヤリマンだし

394:デフォルトの名無しさん
20/06/27 21:03:21.73 kHv6hhb8.net
テストを別オブジェクトにするのが間違ってるのかもわからんね
データと関数をセットにしたものをオブジェクトと呼ぶように
データと関数とテストをセットにした自己メンテナンス完結型のものをアクターと呼ぶことにしようよ！

395:デフォルトの名無しさん
20/06/27 21:13:44.71 gS37C1rZ.net
>>380
> テストは全メソッドやるでしょ
全メソッドやるかどうかはその人次第
テストするならpublicにする
それだけの話
テストするということは、そのインターフェースは
外部から使用しても良いということを意味する
テストされてるんだから仕様が変わったりしない

396:デフォルトの名無しさん
20/06/27 21:14:19.20 gS37C1rZ.net
>>381
> publicにしたら別のオブジェクトからアクセスされちゃうじゃん
アクセスしても問題ないだろ？
アクセスしても問題ないようにテストしてるんだから

397:デフォルトの名無しさん
20/06/27 21:32:11.55 kHv6hhb8.net
>>384
いやいや、公開する必要のないメソッドを公開する意味がない
呼ばれちゃいけないタイミングはある、テストしてるかどうかとは関係ない
テストしてないコードはバグってるよ
人の問題で片付けてはいけない

398:デフォルトの名無しさん
20/06/27 21:33:25.71 kHv6hhb8.net
テストやるときって前提となる状態を作ってからやるじゃん
公開して自由にアクセスできたら前提が成り立たない状態でアクセスされちゃうじゃん
テストエアプかい？

399:デフォルトの名無しさん
20/06/27 21:34:14.35 kHv6hhb8.net
ちなみにだけど僕は自動化テストは書いたことがない
書いたことないけど僕はテストにすごく詳しいんだ、わからないことがあったら聞いて

400:デフォルトの名無しさん
20/06/27 21:36:38.34 kHv6hhb8.net
privateなメソッドにテストが必要ないと思ってる人がいるのが僕は不思議
むしろprivateなメソッドこそテストするべきでpublicなメソッドはただのインターフェース

401:デフォルトの名無しさん
20/06/27 21:38:48.09 kHv6hhb8.net
privateなメソッドにロジックが書かれていてそのテストを内包してるオブジェクトのことをアクターと呼ぶことにしようか

402:デフォルトの名無しさん
20/06/27 21:45:24.83 OC6QjUii.net
publicにしたからと言って緩和するだけで結局状態の保持をされて意味不明な動作をするところは変わらんで
staticおじさんの言うことを聞きなさい

403:デフォルトの名無しさん
20/06/27 22:12:18.34 gS37C1rZ.net
>>385
> いやいや、公開する必要のないメソッドを公開する意味がない
テストするのだから公開する必要があるだろ
なにいってんだおめぇ

404:デフォルトの名無しさん
20/06/27 22:15:42.36 kHv6hhb8.net
>>391
お前が何いってんだハゲ
privateだとテストできないのが困るのよねえと言ってんだろうが

405:デフォルトの名無しさん
20/06/27 22:16:57.07 kHv6hhb8.net
テストエアプか？
テストのためだけにpublicにするなんてありえない

406:デフォルトの名無しさん
20/06/27 22:18:03.01 pxtmQ7+k.net
>>393
じゃあ、どうすんだよ
って聞いてみたい

407:デフォルトの名無しさん
20/06/27 22:19:08.38 UrcM2fcl.net
外部からアクセスするテストをしなくて済むのがprivateだと思います^^

408:デフォルトの名無しさん
20/06/27 22:19:09.22 kHv6hhb8.net
>>394
同じオブジェクトにテスト書けば良いと僕は思います
データ、メソッド、テストを備えたオブジェクトを特別にアクターと呼ぶことにしましょうという
のが僕の提案です

409:デフォルトの名無しさん
20/06/27 22:20:26.71 gS37C1rZ.net
>>388
テストをするということは、それはインターフェースとして仕様がきっちりしていて
長い期間にわたって変更しない（されにくい）ということなんだよ
インターフェースが適当だったり変わりやすいものは
変わるたびにテストも変えなくてはいけなくなる
つまりテストのメンテナンスのコストが増えてしまう
インターフェースが適当だったり変わりやすいものを作るなという話じゃない
そういうのは作ってもいいがprivateにして、他のpublicメソッドを通して間接的にテストする
privateはテストしなくていいとかテストできないとかじゃなくて
インターフェースが（まだ）明確に決きめずに後回しにできるというメリットが有る
一方テスト可能な段階になったなら、それはインターフェースの仕様が明確に定義されているということ
（明確に定義されてないものをテストなんかできない）
明確に定義されたのならpublicにしていいわけ

410:デフォルトの名無しさん
20/06/27 22:20:30.54 nVWlQ22s.net
ジャップにオブジェクト指向は100年早いみたいだな
脳死で全てにpublic staticって書いとけ

411:デフォルトの名無しさん
20/06/27 22:20:37.43 kHv6hhb8.net
>>395
あら、あーたはprivateなメソッドのテストはなさらないの？
それで平気

412:なの？

413:デフォルトの名無しさん
20/06/27 22:22:06.34 gS37C1rZ.net
>>393
テストというのはオブジェクトを使用するときの例でもあるんだから
テストがやってることは、テスト以外でもやって良いんだよ
テストでしか呼び出してないからって、privateにする必要はない

414:デフォルトの名無しさん
20/06/27 22:22:39.57 kHv6hhb8.net
>>397
そんなの関係なくメソッド書いたらテストもするでしょ
テストされてないコードはすべてバグだよ
public通してテストするのは粒度が大きすぎる

415:デフォルトの名無しさん
20/06/27 22:23:50.09 gS37C1rZ.net
>>401
だからprivateをテストするということは、
そのメソッドは仕様が明確に決まったということなので
publicにしていいんだよ

416:デフォルトの名無しさん
20/06/27 22:23:52.28 gUUFl8tS.net
>>400
じゃあ、全部テストするときは全部publicだね

417:デフォルトの名無しさん
20/06/27 22:24:28.59 kHv6hhb8.net
>>400
テストするときは前提の状態を用意してからやるもので
テストは実装が正しいか確認するためにやる
publicにして他のオブジェクトから自由に呼び出して良いですというものとはわけが違う
テストで呼んだから別のところでも呼んでいんだなんて道理は存在しない
テストエアプか？

418:デフォルトの名無しさん
20/06/27 22:25:10.97 kHv6hhb8.net
>>402
言い訳がない、privateにするのはよそからアクセスさせないため
テストするためにpublicにしていいわけがない、オブジェクト指向エアプか？

419:デフォルトの名無しさん
20/06/27 22:25:22.83 gS37C1rZ.net
>>403
仕様が明確に決まってないようなものは
privateにしてテストをサボることができる
サボると言ってもpublicメソッド経由でテストするわけだが
あくまでメソッド単体でのテストをサボるだけ

420:デフォルトの名無しさん
20/06/27 22:25:38.25 zbAPoACG.net
>>404
だからどうすんだよ

421:デフォルトの名無しさん
20/06/27 22:26:14.09 gS37C1rZ.net
>>405
> privateにするのはよそからアクセスさせないため
テスト（よそ）からアクセスするのでpublicです

422:デフォルトの名無しさん
20/06/27 22:27:02.78 kHv6hhb8.net
>>407
そこで、僕に名案があります
テストを同じオブジェクトの中に用意するんです
そうしてデータ、メソッド、テスト、この3つを備えたオブジェクトをアクターと呼ぶことにしましょう
プログラミングパラダイムはアクターが主流の時代に突入します

423:デフォルトの名無しさん
20/06/27 22:28:17.85 kHv6hhb8.net
>>408
テストのためにpublicにしたらオブジェクトが壊れるため
テストのためにpublicにするのはオブジェクト指向的にありえない
オブジェクト指向エアプか？

424:デフォルトの名無しさん
20/06/27 22:28:55.27 gS37C1rZ.net
>>410
> テストのためにpublicにしたらオブジェクトが壊れるため
壊れないよ。

425:デフォルトの名無しさん
20/06/27 22:30:05.59 kHv6hhb8.net
テストという概念がオブジェクト指向の中にないからこのようなジレンマに陥るのです
そこで、オブジェクトの中にテストを入れてしまおうというのが僕が提唱する新時代の
プログラミングパラダイム、アクター指向です

426:デフォルトの名無しさん
20/06/27 22:30:26.61 kHv6hhb8.net
>>411
壊れるに決まってるだろ、いい加減なこと言うなハゲ

427:デフォルトの名無しさん
20/06/27 22:30:40.41 kHv6hhb8.net
privateなめんなよ

428:デフォルトの名無しさん
20/06/27 22:30:57.83 gS37C1rZ.net
>>413
なんだよｗ根拠言えないのかよｗ

429:デフォルトの名無しさん
20/06/27 22:31:24.07 kHv6hhb8.net
>>415
お前が根拠言えよ

430:デフォルトの名無しさん
20/06/27 22:31:41.00 kHv6hhb8.net
壊れないことを証明してみせろ

431:デフォルトの名無しさん
20/06/27 22:32:50.72 gS37C1rZ.net
壊れる要因がないので壊れない

432:デフォルトの名無しさん
20/06/27 22:33:18.25 kHv6hhb8.net
早くしろよおら、全部publicにしてプログラム書いてみろよ、ぶち、壊してやるから

433:デフォルトの名無しさん
20/06/27 22:36:21.73 kHv6hhb8.net
アクセス修飾子はテストのために変えるものじゃない
そこに現行のオブジェクト指向の限界がある
そこでオブジェクト内にテストまで用意しましょうというのが新時代のアクター指向

434:デフォルトの名無しさん
20/06/27 22:37:15.69 paNjyoZf.net
現状のオブジェクト指向言語がウンコってことでいいよね

435:デフォルトの名無しさん
20/06/27 22:38:06.59 gS37C1rZ.net
> アクセス修飾子はテストのために変えるものじゃない
当たり前だろうｗ
テストというのは外部からインターフェースの仕様が明確に決まってるからこそできること
外部からのインターフェースの仕様が明確に決まったなら
それはpublicにしてよい

436:デフォルトの名無しさん
20/06/27 22:38:47.14 kHv6hhb8.net
>>422
そんなの当たり前だろ

437:デフォルトの名無しさん
20/06/27 22:39:05.28 gS37C1rZ.net
だから当たり前の話をしてる

438:デフォルトの名無しさん
20/06/27 22:40:35.80 kHv6hhb8.net
>>421
はい、そう言わざる得ないのが現状です
言語が悪いんじゃないプログラミングパラダイムにまだ進化の余地があると
前向きに捉えるのが良いと僕は思います
アクター指向言語がこれから出てくることを祈ります

439:デフォルトの名無しさん
20/06/27 22:40:49.92 kHv6hhb8.net
>>424
だから当たり前だろ

440:デフォルトの名無しさん
20/06/27 22:41:07.23 kHv6hhb8.net
あ・た・り・ま・え

441:デフォルトの名無しさん
20/06/27 22:41:23.91 5gWgsM/a.net
え？privateなメソッドをテストしないって正気？
単に現状のオブジェクト指向言語と開発環境がテストのサポートできてないだけだろ

442:デフォルトの名無しさん
20/06/27 22:42:31.56 kHv6hhb8.net
>>428
ねー意味分かんないよねー、ドン引きだよねー

443:デフォルトの名無しさん
20/06/27 22:43:30.93 UrcM2fcl.net
>>399
リフレクション使ってでもやれって言うときはやりますけど？
そこら辺はルール作ってるはずで設計以前で明言されるべき
private要素に外部からアクセスしまくるようなことを許す設計やルールはどうかと思いますけどね
というか他の読み手が安心感を得るためでもある気がしますね
全部publicなプロダクトがあったとしてそれに新しいクラスやらを追加しろって言われたら神経質にならなければいけないw
逆にアクセス修飾子なしの言語はルールだけでやってるよね、あれ怖いわ
まあだいたいが単純なプロジェクトしかなさそうな言語だけど。。

444:デフォルトの名無しさん
20/06/27 22:43:37.12 gS37C1rZ.net
privateなメソッドをテストしないんじゃなくて
仕様が明確に固まってないからテストしてもメンテナンスのコストが増えるだけ
そういうのはprivateにしてpublicメソッド経由でテストする
それがやりにくいーっていうなら、そのprivateなメソッドの
仕様を明確に決めればpublicにすることができる
ようするに今やるか後回しにするかの問題でしか無い

445:デフォルトの名無しさん
20/06/27 22:44:43.36 kHv6hhb8.net
>>431
仕様が固まってないからprivateにするんじゃねーんだよ
おめーさてはプログラミングエアプか？

446:デフォルトの名無しさん
20/06/27 22:45:21.19 qZEydISP.net
>>431
いやいやテストプロジェクトではprivateにアクセスできるってだけでいいでしょ

447:デフォルトの名無しさん
20/06/27 22:45:36.87 kHv6hhb8.net
>>430
じゃあprivateでもテストすればいんじゃないでしょうか

448:デフォルトの名無しさん
20/06/27 22:52:10.82 kHv6hhb8.net
テストオブジェクトから呼び出すためだけに
オブジェクト内部の処理をpublicにするのはありえない
publicメソッド経由で呼び出すのは粒度が大きすぎて話にならない
リフレクション使えばテストできるんだからそういう機能を持ったテストライブラリを使うべき

449:デフォルトの名無しさん
20/06/27 22:53:18.84 e0+LQFD/.net
インターフェース仕様にまだ決まってないだとか
確定なんて明確な区切りなんてものは
現実にはない。
まだ確定してなくても仮のものを仮定して
実装はできる。
確定した後にインターフェースを変えたくなったり
ある日根底から覆ったりする。
privateで制限した内容は顧客要求より強い効力を持つの？
だったら凄く有効だよな
でもそうじゃないだろ

450:デフォルトの名無しさん
20/06/27 22:55:59.77 kHv6hhb8.net
リフレクションはオブジェクト指向にとっては黒魔術でしかないので正当なやり方ではない
この問題の本質はオブジェクト指向にテストの概念がないことにある
オブジェクト指向は規模の大きなシステムの品質を担保するために作られたわけだが
現代ではそれにテストも入れるべきなんだよ
データ、メソッド、テストこの3つを内包するオブジェクトを作ることこそが真のオブジェクト指向

451:デフォルトの名無しさん
20/06/27 22:56:59.64 gS37C1rZ.net
>>432
じゃあ何のためにprivateにするんだよ？
テスト（外部）からアクセスするんだろ

452:デフォルトの名無しさん
20/06/27 22:57:06.02 UrcM2fcl.net
>>434
メソッドレベルのテストをリフレクション使ってまでやれって言われたことないですけどねw
inoutがテストしなければならないほど複雑になる１つのメソッドを書くことがおかしいし、
粒度が大きすぎてって、それはinoutを整理しきれてない設計がおかしいのでは？
何でも値が入ってきます、全部１つのメソッドで作ってテストしてください、なんて無茶ぶりだとおもいますねw

453:デフォルトの名無しさん
20/06/27 22:57:18.00 gS37C1rZ.net
>>436
設計したこと無いの？

454:デフォルトの名無しさん
20/06/27 22:57:58.35 kHv6hhb8.net
>>436
privateはプログラムの話だから客は関係ないだろ
客がメソッドコールするわけじゃないからな

455:デフォルトの名無しさん
20/06/27 22:58:22.25 e0+LQFD/.net
>>440
あるよ、そしてそれが何度も顧客によって
覆ったこともな。

456:デフォルトの名無しさん
20/06/27 23:00:01.68 kHv6hhb8.net
>>438
内部からのみ処理したいものだからprivateにするんだよ
テストはしたいけどテストのためだけに他のオブジェクトからも
呼び出せるようにはしたくないよねって話をしてるんだ僕は

457:デフォルトの名無しさん
20/06/27 23:00:03.74 8YCrt6Qf.net
privateをテストするしないっていう想定自体が理解できない
privateメソッドなら当然それを呼び出しているpublicなメソッドがあるはずで
そのpublicメソッドのテストに当然privateなメソッドのテストも含まれるはず
よっぽどprivateメソッドで複雑なことしていない限りそのテストで十

次ページ