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

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

[前50を表示]
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メソッドで複雑なことしていない限りそのテストで十

458:分だろうしそれでテストしきれないほど複雑なら別のモジュールに定義し直した方がいいだろう

459:デフォルトの名無しさん
20/06/27 23:02:02.14 kHv6hhb8.net
>>444
それなりに複雑でメソッドを一つずつテストしたいけど
テストのためにオブジェクト分けるなんてイカれてると思うの
だってオブジェクトがテストのためにあるわけじゃないから
テストがオブジェクトのためにあるべきで、そこでですよ
オブジェクト内にテストを内包するのが正しいオブジェクト指向と結論するわけです

460:デフォルトの名無しさん
20/06/27 23:02:14.45 gS37C1rZ.net
>>442
顧客によって覆ることが何の関係があるの？

461:デフォルトの名無しさん
20/06/27 23:02:29.65 kHv6hhb8.net
仕様が覆るのはあたりまえじゃん
それとアクセス修飾子の話は違うわ

462:デフォルトの名無しさん
20/06/27 23:02:36.66 gS37C1rZ.net
>>443
> 内部からのみ処理したいものだからprivateにするんだよ
テスト（外部）から処理したいんだろ
何矛盾したこと言ってるんだよｗ

463:デフォルトの名無しさん
20/06/27 23:03:54.57 gS37C1rZ.net
>>445
> それなりに複雑でメソッドを一つずつテストしたいけど
> テストのためにオブジェクト分けるなんてイカれてると思うの
複雑なメソッドは小さくしてください
設計がそもそも間違っています
テストのために小さく分けるのではなく
そもそも複雑なのが問題なのです。
問題を解決すればテスト可能になります。

464:デフォルトの名無しさん
20/06/27 23:03:58.42 kHv6hhb8.net
>>448
だから、そこにジレンマがあるよねって話を最初からしてるつもりっす

465:デフォルトの名無しさん
20/06/27 23:04:46.01 /AdLJL3G.net
いや、この問題は言語と開発環境の問題だろ
概念は関係ないよ
visualstudioができちゃえば
できますよ
で終わりな話

466:デフォルトの名無しさん
20/06/27 23:05:10.21 kHv6hhb8.net
>>449
僕は複雑なメソッドを大きく作ってるとは言ってないので
小さくしてくださいというアドバイスをいただいても困惑するばかりです

467:デフォルトの名無しさん
20/06/27 23:05:23.02 UrcM2fcl.net
逆に聞きたいけどpythonとかアクセス修飾子ない言語で、大規模プロジェクトがあったら、
ルール以外でアクセスはどう統制とってるの？
そういう言語の経験はWebくらいしか知らないから、全体何百万行(ステップ数でも人月でもいい)くらいのコードでこうしてた(る)ってのあったら教えて欲しい

468:デフォルトの名無しさん
20/06/27 23:06:53.54 gS37C1rZ.net
>>452
なぜできないんですか？

469:デフォルトの名無しさん
20/06/27 23:07:46.64 XQLOkAsO.net
>>454
あいつらサボってるからだろ

470:デフォルトの名無しさん
20/06/27 23:07:46.82 gS37C1rZ.net
誰でもできることができないなんて、能力がないなぁ

471:デフォルトの名無しさん
20/06/27 23:10:28.90 npRplKHX.net
お前らほんとプログラムのことしか知らないのな
品質を改善するときには品質を測るな　これがテストの鉄則
タグチメソッドの入門でもよめ

472:デフォルトの名無しさん
20/06/27 23:12:05.09 gS37C1rZ.net
1．モノを作る前に品質を創れ
2．品質工学は統計ではない
3．科学的思考ではモノは出来ない
4．市場品質はすべて設計できまる
5．完全な設計は試験や検査は不要
6．品質評価はn＝1でよい
7．品質を改善するときには品質を測るな
8．評価はあるべき姿を定義して、安定性はSN比で行う
9．直交表で設計の再現性をチェックする（パラメータ設計）
10．システムは複雑でなければ、改善はできない

473:デフォルトの名無しさん
20/06/27 23:12:06.00 kHv6hhb8.net
>>457
ありがとー！タグっちゃん！

474:デフォルトの名無しさん
20/06/27 23:13:46.29 gS37C1rZ.net
どこから品質の話が出てきたのか知らんが、
品質とテストの話は
> 5．完全な設計は試験や検査は不要
これですかね？

475:デフォルトの名無しさん
20/06/27 23:19:08.91 gS37C1rZ.net
>>458はいくつか日本語の文章に問題があるな
1．モノを作る前に品質を創れ
2．品質工学は統計ではない　　　　　　　　×「品質工学は○○である」と言おう
3．科学的思考ではモノは出来ない　　　　　×「○○的思考でモノは出来る」と言おう
4．市場品質はすべて設計できまる
5．完全な設計は試験や検査は不要　　　　　×「不完全な設計は試験や検査が必要」と言おう
6．品質評価はn＝1でよい
7．品質を改善するときには品質を測るな　　　×「品質を改善するときには○○をしろ」と言おう
8．評価はあるべき姿を定義して、安定性はSN比で行う
9．直交表で設計の再現性をチェックする（パラメータ設計）
10．システムは複雑でなければ、改善はできない　　×「システムは複雑なら、改善ができる」と言おう
こう偉そうなことを言ってるのに、じゃあどうすればいいかを
相手に考えさせるのって、どうなんでしょうかね（苦笑）

476:デフォルトの名無しさん
20/06/27 23:24:56.40 gS37C1rZ.net
「品質が欲しければ、品質を測るな！」は
「品質が欲しければ、機能を測って改善しろ！」という意味みたいですな
つまりオブジェクトの品質を上げたければ
テストできるように機能を改善しろということですな
privateメソッドであれば、

477:インターフェースを明確にして機能に昇格させればpublicになるわけです。

478:デフォルトの名無しさん
20/06/27 23:31:52.99 npRplKHX.net
>>462
ホントにタグチメソッド知らなかったのか？
その割には理解が早いな
ようするにバクをなくしたいのだろ？
それならバクがでるかどうかのテストをすることが自体がずれてるんだ
そんなことは最終段階でやることじゃないんだ　どうせモグラたたきになる　　
最初の設計段階で徹底的にいじめ抜け
どれだけ変更に強いかをテストするんだ
品質が欲しければ，機能を測れ　これにつきる

479:デフォルトの名無しさん
20/06/27 23:40:30.32 gS37C1rZ.net
>>463
では「機能を測る」とは？
どうやって測るのかを言ってみましょう
できるかな？ｗ

480:デフォルトの名無しさん
20/06/27 23:41:10.95 ZFnYFbMi.net
単体テストとどう違うの？

481:デフォルトの名無しさん
20/06/27 23:41:18.54 gS37C1rZ.net
>>463
> その割には理解が早いな
あんなもん当たり前のことを誰かがまとめただけだからね
デザインパターンと一緒。
よく知られたものに、名前をつけてるだけ

482:デフォルトの名無しさん
20/06/27 23:42:26.37 gS37C1rZ.net
>>465
複雑なものを複雑のままテストをしても意味がない
シンプルにテスト可能な形に設計を変えることがテストの目的の一つ
ようはprivateはpublicになるように設計を変えろということ

483:デフォルトの名無しさん
20/06/27 23:43:10.60 ZFnYFbMi.net
単体テストって結合してからテストするの？

484:デフォルトの名無しさん
20/06/27 23:46:52.77 ZFnYFbMi.net
王家秘伝のレシピ教えてやるよ。
#define private public
皆には内緒だぞ。

485:デフォルトの名無しさん
20/06/28 01:34:12.55 wUTwjqhp.net
>>469
#define ディレクティブを使用して、通常 C および C++ で行うように定数値を宣言することはできません。
C# の定数は、クラスまたは構造体の静的メンバーとして定義することができます。
そのような定数がいくつかある場合は、それを保持するための "Constants" クラスを個別に作成することを検討してください。

486:デフォルトの名無しさん
20/06/28 02:01:57.56 pODeKu4C.net
privateメソッドの直接テストしたいけど可視性を変えたくない場合は
リフレクションを簡単に使えるようにしてるテストフレームワークだったりライブラリ使えばいい
ちなみにGoやRustはprivateもテストできる仕組み持ってる

487:デフォルトの名無しさん
20/06/28 05:51:03.49 qNzQpEfW.net
>>469
あざーす！国王あざーす！

488:デフォルトの名無しさん
20/06/28 05:51:56.56 qNzQpEfW.net
>>471
ええなー

489:デフォルトの名無しさん
20/06/28 09:51:30.71 lfkBrldT.net
>>463
ソフトウェアの作り方も知らずにタグチメソッド真に受けたら、
糞みたいな品質のものしかできんぞｗ
単体テストってのは設計の一部なんだよ。品質テストとは全く異なる。
抽象論でタグチメソッドを適用しようとしてる輩が一番ヤバい。

490:デフォルトの名無しさん
20/06/28 10:22:04 4vfVPlvE.net
なんだミニ四駆のモータに学ぶことでもあんのか？って思ったら
品質100%の更に上の話じゃねーか

現場の単体テストもロクにやらないクソが問題になってるITでそんなもんいらん

491:デフォルトの名無しさん
20/06/28 12:40:59.37 L5Cpw8A4.net
中の磁石が強いほどトルクが上がって回転数が下がる
磁力が弱いほどトルクが下がって回転数が上がる

492:デフォルトの名無しさん
20/06/28 13:22:34.10 S7usk0qp.net
>>326
わかりやすい

493:デフォルトの名無しさん
20/06/28 18:21:30.86 3Si3AZJb.net
privateのテストってリファクタリングの妨げじゃないのか

494:デフォルトの名無しさん
20/06/28 18:55:54.96 nHckGJvd.net
開発体制が複数の会社でピラミッド状の階層化されてたら指揮系統的に相当厳しいだろうね。

495:デフォルトの名無しさん
20/06/28 19:33:26.78 JoVMtTbA.net
Javaの修飾子宣言鬱陶しくて�

496:ﾙんと嫌い

497:デフォルトの名無しさん
20/06/29 14:12:08 EmVrB3rr.net
明示的な状態管理は、（不可能ではないにせよ）管理すべき状態の量が増えてくると非常に困難になってくるところ、関数型言語の考え方を取り込むことによってその負担を軽減できるのではないかーーという意見もあるようだけど、
このスレの人（カプセル化肯定派・否定派いずれも）としてはどう？

498:デフォルトの名無しさん
20/06/29 19:41:29.30 bVpw4tuk.net
カプセル化の可否はともかく
階層化の有害性についてはこう思います。
例えばディレクトリを階層化のすると
親ディレクトリと子ディレクトリに同じデータを重複格納
する人が出たりしてデータの二重管理が発生
しやすくなると思います。
そのうちどれが正なのか分からなくなります。
あと単純に子供に格納するほどデータのアクセスパスが
長くなってどこにあるのか探し出すのが大変になると
思います。
これはオブジェクトの階層構造でも
JSONなどの構造についても言えることだと思います。

499:デフォルトの名無しさん
20/06/29 20:06:40.16 cYsf6eW3.net
プログラムで階層化なんて意識したことないけど問題起こったことない
分野が違うのかな

500:デフォルトの名無しさん
20/06/29 20:18:08.97 6d9dL1u1.net
そう、問題が起こるのはいつも人間関係です

501:デフォルトの名無しさん
20/06/29 20:19:42.34 tYVp58Ca.net
つまり、人間関係の問題を持ってきても、技術を否定したことにはならないのです。

502:デフォルトの名無しさん
20/06/29 21:42:10.57 P3P3vIj6.net
>>483
>>1に書いてあることが理解できない？

503:デフォルトの名無しさん
20/06/29 23:35:22 L39gVdue.net
>>482
そこで挙げている階層化の問題だが、階層化せずフラットに格納すれば解決するのか？
階層化しないということは同じレベルに大量の物が同格に並ぶわけだが、そうなると目的の物を探すのが困難になりすでにあるデータと同じものを重複して格納する危険性があるだろう。
またアクセスパスが長くなるというが、フラットな構造で多数の物を適切に命名しようとすれば階層的な名前付けが役立つはずだが、それすら長くなると忌避するなら場当たり的に短い名前を着けていっていずれ収集が着かなくなるだけでないの？
お前さんが挙げた階層化の問題は階層化の仕方が悪い(下手な)だけで、階層化をしなければ解決するというものではなかろう。

504:デフォルトの名無しさん
20/06/30 05:33:42.93 v2qXZCJh.net
結局、分類だったり抽象化のやり方がクソってだけの話だろ。
フラットにしようが階層にしようが、クソな分け方したらどうにもならんてだけの話だ。

505:デフォルトの名無しさん
20/06/30 08:05:51.26 GiU27GCt.net
URLﾘﾝｸ(monobook.org)

506:デフォルトの名無しさん
20/06/30 08:11:00.58 PIU/381m.net
>>486
ぴえ？

507:デフォルトの名無しさん
20/06/30 10:40:18.75 J3IrN4Ey.net
>>1が例に上げてるRFC3439は「Layering Considered Harmful」という強い言葉を使ってるが
レイヤ化は万能じゃなくデメリットもあるという当たり前のことを書いてるだけ
もちろん「カプセル化は絶対やめろ」なんてことは書いてない
メリット・デメリットを把握した上で
状況に応じたトレードオフの判断ができない人(>>1)には
ソフトウェアの設計はできない

508:途中から見た。
20/06/30 19:35:05 g7PLkMcM.net
なんか、privateメソッドのテストでもめているけど、なんで。
そもそも、privateメソッドを外部から呼び出してテストしないといけない場面が想像できないのだが。
クラスライブラリのコードを紛失したとか笑えないケースを想定しているの？

509:デフォルトの名無しさん
20/06/30 19:48:43 MKfuvp+I.net
gitや自動ビルドツールの存在がなかった時代の
オブジェクト指向技術は淘汰されてもいいんじゃない？

昔はこれらがなかったからカプセル化で神経質に
防御してたけど
今は無理にパッケージを固めてやり取りすることが
なくなって

gitでソースを差分転送して再ビルドする方式に
切り替わった
旧仕様はブランチを切り分けといて復旧が簡単に
なって、仕様変更に対してそこまでビビらなくて良くなった。

それと自作のアプリのオブジェクトで
webからインストールしたライブラリや
フレームワークが自動生成して提供するもの以外で
それほど長時間状態を保持するような巨大なオブジェクト
構造を自作設計して作成することがあるか？
あるとすれば
webのセッションや
オープンワールドやFPSみたいなゲームくらいか

次ページ