オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/04/21(金) 16:08:41.18

>>424
それは説明したじゃん
402がすべてだよ

**デフォルトの名無しさん** · 2017/04/21(金) 16:14:29.43

>>441
カプセル化反対の二人はカプセル化の利害を全然理解していないよね。
害があるからいらないではなく、わからないからいらないと言っている。

**デフォルトの名無しさん** · 2017/04/21(金) 16:20:27.91

>>443
んでメリットの説明ってあったっけ?

**デフォルトの名無しさん** · 2017/04/21(金) 16:20:44.14

>>442
明確になってねーよ
仮にアレで全てだというなら『まず』とか『ここまで』などと言うな

**デフォルトの名無しさん** · 2017/04/21(金) 16:22:11.78

カプセル化害悪派 <------- 結合度ビーーーーム
死亡

**デフォルトの名無しさん** · 2017/04/21(金) 16:35:15.00

>>444
例えば>>403がそうだ。
自分だけが使い仕様変更があったら変更するつもりのメンバ変数やメンバ関数は
勝手に他人に参照されたり呼びだされると変更できなくなって困る。

**デフォルトの名無しさん** · 2017/04/21(金) 16:41:52.97

どうでもいいけどメリデメって略すの嫌い

**デフォルトの名無しさん** · 2017/04/21(金) 16:43:18.10

カプセル化害悪論って、どっかで聞きかじった継承害悪論とごっちゃになってるんじゃないのか？

あ · 2017/04/21(金) 16:49:15.74

>>423
どちらでも無いと思うよ。少なくともどちらかへの「べき」ではない。
隠したいものは隠せばいいし、機械へのポカヨケを埋め込むのも今もうすでに実行不可なメモリみたいなどこのハーバードアーキテクチャだよみたいなの再発明してんじゃん。

**デフォルトの名無しさん** · 2017/04/21(金) 17:12:45.41

>>449
>>216はごっちゃにしているね。

実装継承は20年前に「継承より委譲」と言われていた。
その後のEJB2の複雑さの反動でPOJOブームが起きた。
でもカプセル化害悪論なんて聞いたことがない。

**デフォルトの名無しさん** · 2017/04/21(金) 17:31:41.72

>>199みたいな、ここまでがっちり結合したコードを良しとする人が、数万行程度コードを書いたらどんなことになるのか見てみたいわ

**デフォルトの名無しさん** · 2017/04/21(金) 18:00:15.36

>>452
おめーのコード出してもらおうか
俺はそれを複雑すぎるとさんざんにこき下ろすから
他人のコードにいちゃもんつけて自分のコードは出しませんなんて
そんなのありえないだろ、ベッドで女のパンツ脱がして
自分はスリーピースをぴっちり着込んでるようなもの
どちらが変態化は言うまでもないよね？

**デフォルトの名無しさん** · 2017/04/21(金) 18:03:14.83

>>451
やはりな、継承はオブジェクト指向に必要ないよな
POJOはたしかに話題にはなったが、まだJavaBeansの呪縛から
脱しきれてない過剰カプセル化によって逆に脆くなった
設計ばかりが出回った

いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
聞いたことがあるというべきだし、すぐれた設計だと
後世に伝えていくべき

**デフォルトの名無しさん** · 2017/04/21(金) 18:04:56.46

>>453
おまえはおまえのコード以外を認めないんだから黙ってろ

**デフォルトの名無しさん** · 2017/04/21(金) 18:05:19.93

>>455
……

**デフォルトの名無しさん** · 2017/04/21(金) 18:07:31.03

>>453
別に俺が出すまでもなく、世の中にはそこそこSOLIDを目指したなかなかのコードが死ぬほど公開されてるんだが

> 俺はそれを複雑すぎるとさんざんにこき下ろすから
それらが読めないとしたら、それは複雑すぎる場合もあるだろうが、大抵は君のスキル不足だろうね
試しにgitfubから有名どころの1万行以上のプロダクトを選択してこきおろしてみたら？

**デフォルトの名無しさん** · 2017/04/21(金) 18:11:31.05

>>454
>いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
>聞いたことがあるというべきだし、すぐれた設計だと
>後世に伝えていくべき

一切論じられてないよ
悪いんだけどどこらで論じてたのか教えてくれる？

**デフォルトの名無しさん** · 2017/04/21(金) 18:11:49.39

>>457
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ

**デフォルトの名無しさん** · 2017/04/21(金) 18:12:34.04

>>453
選ぶの面倒とかいいそうだから、俺が選んでやろう
Javaで実装された超有名プロダクト
https://github.com/kohsuke/jenkins
ほら、駄目だししてみ？

**デフォルトの名無しさん** · 2017/04/21(金) 18:13:54.37

>>458
>>322 この辺とかすごくいい議論ができてるしとても有益でためになると思う

**デフォルトの名無しさん** · 2017/04/21(金) 18:14:43.96

>>460
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ
他人のふんどしで相撲取ろうとするな卑怯者

**デフォルトの名無しさん** · 2017/04/21(金) 18:15:18.80

とうぜんキャットドア問題を解決するコードだ

**デフォルトの名無しさん** · 2017/04/21(金) 18:16:17.62

結局キャットドア問題を解決できたの俺だけじゃん
カプセル化を導入してたらできてなかったと思う
俺は歴史の生き証人

**デフォルトの名無しさん** · 2017/04/21(金) 18:17:40.73

>>462,463
俺には難しすぎて読めませんって白状しろよ

**デフォルトの名無しさん** · 2017/04/21(金) 18:17:51.34

キャットドア問題をオブジェクト指向で解決してください
権威や数の力は不要だ、オブジェクト指向をわかっているなら
自力で解決できるはずだ

**デフォルトの名無しさん** · 2017/04/21(金) 18:18:26.45

>>461
悪いんだけど根拠のない言い合いに意味はないよ
根拠を示してくれる？

**デフォルトの名無しさん** · 2017/04/21(金) 18:18:45.77

>>464
そもそも、キャットドア問題とか知らんし
他人のコード書いてほしけりゃ、仕様示せ

**デフォルトの名無しさん** · 2017/04/21(金) 18:19:13.64

>>465
で、キャットドア問題を解決するオブジェクト指向のお前が書いたコードは？
俺は書いたよ、お前にいちゃもんつけられたけど
だから、俺はお前が書いたコードをボコボコに貶してやる所存だけど
お前はその覚悟もできてるし受けて立つ実力もあるんだよな
じゃあコードを書いてもらおうか

**デフォルトの名無しさん** · 2017/04/21(金) 18:20:45.36

>>468
このスレにいて知らないはありえない
すれを検索すればすぐにでてくる >>6

**デフォルトの名無しさん** · 2017/04/21(金) 18:21:06.06

仕様にいちゃもんつけて逃げたりしてｗ

**デフォルトの名無しさん** · 2017/04/21(金) 18:21:25.26

>>466
>>199程度のコードなら、誰がどう書いても複雑にはならんだろ
俺の>>199の批判ポイントはSOLIDだ

OCPはダメダメらしいが、S,L,I,Dも駄目なら批判しなよ

**デフォルトの名無しさん** · 2017/04/21(金) 18:21:43.58

この手の手合いは他人を否定するけど自分では何も作れない木偶の坊と相場が決まってるからな

**デフォルトの名無しさん** · 2017/04/21(金) 18:22:17.82

さて、どんなコード書くんだろうな、楽しみだわ

**デフォルトの名無しさん** · 2017/04/21(金) 18:23:03.71

>>472
>>199は俺のコードだからパクっちゃだめだぞ、カンニングは卑怯な行為だからな
あくまで仕様を読んで作るんだぞ

**デフォルトの名無しさん** · 2017/04/21(金) 18:23:31.45

>>470
なんだ、>>199と全然違うじゃんか
俺は>>199の範囲で>>199のコードが糞だと断言するわwww

**デフォルトの名無しさん** · 2017/04/21(金) 18:24:37.49

他人を否定すればするほど自分のハードルがあがるけど大丈夫なのかな
結局自分のコード書けないパターンをちゃくちゃくと歩んでるようだけど大丈夫なのかな
逃げ出しそうだぞ、大丈夫なのかな

**デフォルトの名無しさん** · 2017/04/21(金) 18:26:54.78

>>477
カプセル化害悪論の根拠を示してくれるかな？

**デフォルトの名無しさん** · 2017/04/21(金) 18:27:35.87

>>478
……

**デフォルトの名無しさん** · 2017/04/21(金) 18:28:40.65

>>479
あ、根拠ないんだね
了解

**デフォルトの名無しさん** · 2017/04/21(金) 18:29:00.98

……

**デフォルトの名無しさん** · 2017/04/21(金) 18:29:47.23

黙ってろって言われたから黙らざるを得ないのに
それで了解とか自己完結しすぎだと思う、病んでるよ彼は病んでるよ

**デフォルトの名無しさん** · 2017/04/21(金) 18:30:19.40

>>482
じゃあ黙り続けろよ

**デフォルトの名無しさん** · 2017/04/21(金) 18:30:38.43

>>483
……

**デフォルトの名無しさん** · 2017/04/21(金) 18:30:56.12

俺のことは寡黙な人と呼んでくれ

**デフォルトの名無しさん** · 2017/04/21(金) 18:31:20.37

>>485
黙ってねーじゃねーか

**デフォルトの名無しさん** · 2017/04/21(金) 18:32:01.93

>>486
クソレスすんなハゲ

**デフォルトの名無しさん** · 2017/04/21(金) 18:33:35.27

>>487
ごめんね
ハゲでごめんね^^

**デフォルトの名無しさん** · 2017/04/21(金) 18:36:02.42

ハゲもプログラム書けんの？
書けるんだったらオブジェクト指向でキャットドア問題に調整してほしい

あ · 2017/04/21(金) 18:39:02.82

あのドアってこういう話の発端から出てきた問題だったんだな。
オブジェクト指向で、ってそういう事か、なるほど。
ナンセンスだな。

何を以ってドアと成立するか定義できてるようで出来てない。
定義1を死守したければ、俺なら定義1は定義0の子クラスにして、定義2は定義1を継承せずに定義0から作るわ。
定義0は最終的にObjectに収斂する。

クラス設計を破壊せずに性質を追加ってのが矛盾してる。
ワイン樽と泥水の問題。

**デフォルトの名無しさん** · 2017/04/21(金) 18:42:27.87

↑こうやって仕様に文句を付けて
コードから逃げる人間は飽きるほど見てきた

オブジェクト指向のコードをかける人間はいないのか

あ · 2017/04/21(金) 18:45:08.24

>>491
俺どっかで書いたぞ

**デフォルトの名無しさん** · 2017/04/21(金) 18:46:48.77

>>492
それどこよ？　どれよ？　どこなのよ？　どこーーー！！

**デフォルトの名無しさん** · 2017/04/21(金) 18:47:06.08

取り乱してしまいまして

あ · 2017/04/21(金) 18:48:45.01

もちろん、オブジェクト指向が役に立ちづらい、リアルな機械はそもそもコンポーネント指向で作るとも書いたし、コード自体適当なのも確かだが。
860 あ sage 2017/04/14(金) 08:00:23.71 ID:6kAIEFCu
ゴルーチンでドアとノブとストッパーとオートクローザーと個々に置いて、Channelで疎通させたらgoっぽい現実解になった。
ドアノブがあるとは限らんし、ドアノブとは別に鍵があるかもしれんし、とか思うと埋め込みではうまくいかんな。
この辺は機械と同じでコンポーネントにしとかないと後でわけわからん便利ボタン作られたときに面倒くさいと構えてしまったわ。
ラダーのほうがわかりやすいのかけるかも。
しかしideoneすげえな。
866 あ sage 2017/04/14(金) 10:26:30.48 ID:6kAIEFCu
>>862
http://ideone.com/yvttId

あ · 2017/04/21(金) 18:53:00.35

何でわざわざ関数作ったのに放棄してクロージャ変数にしてるか見たら、カプセル化がオブジェクト指向の専売でもなけりゃ普遍的に便利なものか気づくだろ。

**デフォルトの名無しさん** · 2017/04/21(金) 18:59:03.34

>>496
クロージャがカプセル化じゃないとしたら
カプセル化害悪論には賛成していただけるよね？

あ · 2017/04/21(金) 19:05:27.23

>>497
クロージャはカプセル化で、カプセル化害悪論には大反対だ。
カプセル化されてるから、ドアは責任を持ってイベントに対して好きなことを好きなだけできるし、他人はそれに関与せずにイベントの投げ合いで済む。
鍵のないドアだってあるんだから。

あ · 2017/04/21(金) 19:06:54.30

見せたくないものを隠すんだけじゃない。
見て不快なものが目に入らないようにするためにも使えるんだよ。
NHKの入らないテレビみたいなもんだ。

**デフォルトの名無しさん** · 2017/04/21(金) 19:27:31.37

>>499
具体的に誰に対してやってるの?

**デフォルトの名無しさん** · 2017/04/21(金) 19:29:06.55

>>498
カプセル化害悪論に反対しているとのことだけれども
もしクロージャがカプセル化ではないと仮定したら
カプセル化害悪論に反対する理由もなくなると思うんだよ

クロージャってどちらかというとローカル変数じゃない？
クロージャオブジェクトを使うところって関数内に限られると思うんだよ
そう考えるなら結局クロージャってローカル変数ってことになるわけじゃん？
だからクロージャを使ってもカプセル化害悪論には反しないんだよ

あ · 2017/04/21(金) 20:03:29.23

>>500
自分かも知れないし、他人かもしれないけど、それを考えたくない場面でそれが目に入らないようにしてる。
その関数以外書いてるときに、その関数なんて考えたくないじゃん。

>>501
だからクロージャは一つのカプセル化だって言ってるんよ。
ローカル変数って言葉が良くないが、ローカル変数には違いない。ただ、お前が思ってるローカル変数よりも限定的で、そして並行的だよ。
関数内に限られるわけではない。mallocして何かに帰そうが勝手だよ。
クロージャの中でいくつかのコールバックに渡したりするならなおさら。
つまるところ、オブジェクト指向のインスタンスのメンバ変数とあまり変わらん。

**デフォルトの名無しさん** · 2017/04/21(金) 20:07:05.07

>>502
はぁ?
ちゃんと設計書は書いてる前提でいいんだよね?

あ · 2017/04/21(金) 20:17:17.21

>>503
うん。書いてるから何？
書いてるから触ってはいけないとわかるはずだ、なら、無意味かつ実務知らなすぎだな。
書いてて触ってはいけないならば、触れることができてはいけないんだよ。本来は。
AppleのMacOSのUIのデザイン規約くらいの時代から書いてた話。
感電するよって書いてたら覆いをしなくたって良いなんて機械はありえないのと同じ。

**デフォルトの名無しさん** · 2017/04/21(金) 20:22:47.97

包丁は料理にのみ使われるものだから傷害事件で扱われる刃物は包丁以外であるって理屈

**デフォルトの名無しさん** · 2017/04/21(金) 20:32:03.02

>>504
じゃ、君の想定してる環境って

本来なら設計書を記述してから修正すべきなのに
それがやりにくい現場ってことでいいのかな?

カプセル化は設計書を記述する手順を踏んだとき役に立たない?

**デフォルトの名無しさん** · 2017/04/21(金) 20:45:20.00

車のブレーキだけを踏んでたら全然進まないのでプレーキを踏んでもちゃんと進むように修理する工場だな

**デフォルトの名無しさん** · 2017/04/21(金) 20:51:25.16

カプセル化の意義を誤解するものはfriendの意義も誤解する

あ · 2017/04/21(金) 21:04:20.97

>>506
本来なら設計書を記述するどころか設計変更申請出して承認を経て設計書と設計変更書を出して、実装を変更して設計変更書から起こされた上がってきたテスト仕様書でテストして完了するけど、何もやりにくくないでしょ。

カプセル化は役に立つよ。担保となる元の設計書で使ってる部品の設計書を出来る限り見ずに済むし、
なんなら部品ごと新しく変えてもIFさえあってれば良い証左になるんだから。

>>507
プレーキとやらの定義が、踏めば進むというものであるならそう治すべく修理なり改修なりするわな。
このパンチメタルで穴が空いてる部品は共有部品で、AT車ならフットレスト、MT車ならクラッチペダルにつける部品の首がよく腐るから設計変更するなら、
押してクラッチが切れるかもしれない部品であり、押しても何も起こらない部品を同時に設計変更してる事になるが。
お前らのドアってこのパンチメタルの板くらいフワフワした定義。

**デフォルトの名無しさん** · 2017/04/21(金) 21:09:39.74

>>509
設計書書いてるんだよね?

だったら今回の開発でそのメソッドを呼び出す奴は決まってる
今後増える予定を想定することの記述も設計書にはないでしょ?

この状態でprivateとpublicになんの意味があるの?

**デフォルトの名無しさん** · 2017/04/21(金) 21:11:56.33

>>509
全面的に同意
ふわっふわしまくってるせいでカプセル化が害だとか言うバカみたいな考えなしの意見が出てくるんだと思う

あ · 2017/04/21(金) 21:16:51.77

>>510
呼び出すやつは決まってる、今後呼び出し方が変わる予定も無い。
ならばそいつはそれがインターフェイスで良いと思うけど、インターフェイスが無いわけではない。そいつがそのものであるだけで。
その上で、疎通にはこれを使おうね、これは使ってくれるなよ、と言う設計は無為味だし、むしろそうならばモジュラーにせずにそれごと機械に埋めてしまえとなる。
そうでは無くて、壊れたらこれだけ変えられるようにしとこう、とか、これだけを改良できるようにしよう、とか、
不具合が出たときに特定しやくすしとこうとなると、ある意味不自由を強制する形で決まった形で疎通させるのは当然でしょ。
お前のパソコンがノートパソコンならタッチパッドは前者、USBマウスは後者だよ。

**デフォルトの名無しさん** · 2017/04/21(金) 21:25:56.38

>>512
何?次の開発を想定してるの?
よくわからないんだけど?

問題があったら設計書を修正してレビューしてソース修正する流れでいいんだよね?

**デフォルトの名無しさん** · 2017/04/21(金) 21:29:21.44

ここまでの流れで面白いのは>>414の視点だけ
カプセル化がどうの
その是非がどうのとはさんざん繰り返されがちだが

アクセッサ自体が意外と臭いよねって観点まで到達できる人は少ない
また、そこから先の議論についてもあまり見かけない

**デフォルトの名無しさん** · 2017/04/21(金) 21:31:37.27

>>514
そもそもアクセサなんてものはモダン言語では自動生成なので論外

**デフォルトの名無しさん** · 2017/04/21(金) 21:33:08.50

>>513
いつもよくわかってないな

**デフォルトの名無しさん** · 2017/04/21(金) 21:34:14.81

その自動生成ってのを嬉しがる精神性が問題
アクセッサなんか書きにくいほうが健全
きみにはまだ伝わらないと思うし
これ以上言葉費やす予定もない

あ · 2017/04/21(金) 21:35:03.27

>>513
一般的に開発ってこんなもんだろ。
物理的な製造業から何まで、本来は。

問題があったら、設計変更の起案からだよ。
設計変更より作り直したほうが安くつくとか考えないといかんだろ。
ソース修正した後に、何を担保にしてその修正が妥当か、どういうテストが妥当かを定義するときに、組み合わせ爆発が起こらんようにIF定義するんじゃん。

>>514
アクセサのあるprivateなメンバなんか、ちょっと運が良ければチェックロジックなんか入ってるかも？運が悪ければ違う値まで変わっちゃうかも？みたいな、余計に面倒くさい奴だしな。

**デフォルトの名無しさん** · 2017/04/21(金) 21:40:55.19

>>518
修正した設計書通りでしょ?
これがすべてに優先されるんでいいんだよね?っていうかそうじゃなかったらびっくりだわ

前のソースは関係ないよ
privateやpublicに意味なんかないよ

あ · 2017/04/21(金) 21:44:00.25

>>519
修正した仕様書の妥当性はどう計測して、修正したソースの妥当性はどう計測するの？
インアウトが確実に2つずつなら、ステートマシンでも組み合わせ数は知れてるだろうが、
インアウトの数が担保できなければそんなもの検証しようがない。

あ · 2017/04/21(金) 21:46:20.92

逆に言うわ。publicなものの組み合わせを検証する必要が本当に正しいと証明するためにはある。それはnCmで増える。
だから、組み合わせを減らしたい。

**デフォルトの名無しさん** · 2017/04/21(金) 21:47:22.88

>>517
いーやわかってないのはおまえ
アクセサの必要性が低いなんてことは歴史的背景ふまえググれば中学生でもわかること
ではなぜ事実上、必須になっているか
そこまで考えてはじめて俺と同じ土俵に立てる
出直せ

あ · 2017/04/21(金) 21:51:18.83

>>522
アクセサは自動生成されるべきじゃないし、される言語も少なくないか？アクセサ作ったらメンバが生えるのはあるだろうけと。

**デフォルトの名無しさん** · 2017/04/21(金) 21:51:19.37

publicフィールド = 何の制限もかけられないアクセッサだよ

つまりいずれにしろアクセッサ相当のものを使っているわけで、
問題はアクセッサがいるかどうか？ではなく、
制限をかける必要があるかどうか？

で考えたほうが良い。

あ · 2017/04/21(金) 21:52:38.91

>>521
意味わからん文になってた。証明するためには全パターンを網羅する必要がある、だな。

**デフォルトの名無しさん** · 2017/04/21(金) 21:58:52.01

>>523
されるべきなんだよ
何故なら90%のメンバ変数はアクセサなんて必要としないから
残り10%のために手書きなんてバカらしいだろう

**デフォルトの名無しさん** · 2017/04/21(金) 21:59:11.05

>>520
設計書通りに動くことを確認するよ

これができなくなっちゃうって言ってる?

あ · 2017/04/21(金) 22:07:30.53

>>526
メンバ変数を見ればいいなら、メンバ変数見れば良くない？
アクセサがない限り、見れない書けない方が健全だとは思うが。

>>527
似てるようで違う。
設計書が正しいかが組み合わせ全てを用いないと証明できないし、設計書通りかどうかも同様に証明できない。
インが4本なら16通りだけど、10本だと1024通りだよ。

**デフォルトの名無しさん** · 2017/04/21(金) 22:11:46.98

設計書が正しければ、正しいプログラムができるはずだ！

**デフォルトの名無しさん** · 2017/04/21(金) 22:15:10.16

設計書が正しいことをきちんとテストする必要がある。

つまり、設計書のテスト仕様書が必要だ。

そしてそのテスト仕様書通りに設計書が
正しいかをテストする人間も必要になる。

そこで重用なのは、テストの手法である。
設計書が正しいことをどうやってテストするか？
つまり設計書を書いた人間への聞き取り作業である。

設計書に書き漏れがないか？設計書に書かれた言葉に矛盾がないか？
テスト仕様書に従って設計書を見ながら設計者を問い詰める。
これが設計書に対する優れたテスト方法である

あ · 2017/04/21(金) 22:21:07.33

揶揄してるようだが、設計書をテストする設計書にあたるものが、設計変更申請書だよ。
それはヒアリングやら検証実験やら、承認者の首やら、人の手で担保するもの
大規模開発した事ないのかな。

**デフォルトの名無しさん** · 2017/04/21(金) 22:22:18.55

>>528
アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要
だからモダン言語にはプロパティというものがある
プロパティに出来てpublic変数に出来ないことを考えればおのずとプロパティでいいよねという結論にたどり着くと思うがね

**デフォルトの名無しさん** · 2017/04/21(金) 22:23:36.50

うーん
ぶっちゃけそれとカプセル化との関連が不明
もはや何を主張したいのか滅茶苦茶な気がするんだけど

**デフォルトの名無しさん** · 2017/04/21(金) 22:24:22.02

> 設計書をテストする設計書にあたるものが

意味わからん。

設計書をテストするものは、設計書のテスト仕様書だ。

つまりその設計には、○○の場合の処理は抜けていないか？
○○の場合に不整合は起きないか？
などというものが書かれいいるもので無ければ、
設計書のテスト仕様書とはよべない。

**デフォルトの名無しさん** · 2017/04/21(金) 22:25:20.57

>>520の発言内容はカプセル化と関係ないよね?

**デフォルトの名無しさん** · 2017/04/21(金) 22:26:41.05

>>532
> アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要

アクセッサはアクセス制限ではなく、アクセスした後に入れようとした値が
正常値かどうかを判断するもの。
型だけでは表現できない特殊なルールを記述する所
アクセス修飾子は単にアクセスできるかどうかしか記述できない。

**デフォルトの名無しさん** · 2017/04/21(金) 22:32:34.16

>>536
それは俺にレスするな
>>528の疑問に答えただけだから>>528にいえよ

俺の主張はgetter、setterの是非なんてものは時代遅れもいいところでその解がプロパティだろってことだけだ

あ · 2017/04/21(金) 22:32:51.15

>>532
プロパティはメンバ関数だよ。
C#ならIL見ればわかるけど、確かアンスコついた変数出来てる。
プロパティ自体もフツーに関数。
何で見えない変数が必要なのか、ってのは、副作用があるプロパティを書くことが出来る限り不必要にならない。
Queueみたいなもののgetのアクセサが、デキューして返すみたいなコードだと、デキューせずに先頭を見る方法が無くなる。

>>534
段取りがおかしい。「設計書のテストの仕様書」が成立するためには、「設計書の設計書」が必要。
なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。
「xxの処理は漏れていないか」は「xxの処理が必要だと定義されている」から書ける。
そのための要件は、すり合わせと設計変更申請のレビューと相手方、担当者の連名の捺印で担保する。

>>535
あるよ。
組み合わせが妥当な手段ではこれ以上ないと言う事が、数が少なくなればなるほど簡単になる。

**デフォルトの名無しさん** · 2017/04/21(金) 22:34:09.19

>>538
> なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。

設計書を書く → その設計書のテストを書く
何の問題もないじゃないか

あ · 2017/04/21(金) 22:34:35.69

>>537
getter,setterとプロパティってシンタックスシュガー以上の違いある？Kotlinとか、getterとsetterを暗黙のプロパティに変換してくれるが。

あ · 2017/04/21(金) 22:35:44.20

>>539
おまえふざけんなよw