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

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

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

**デフォルトの名無しさん** · 2017/04/19(水) 20:01:49.80

>>224
依存しないように実装すれば良いが

**デフォルトの名無しさん** · 2017/04/19(水) 20:02:59.08

>>226
んなアホな、それは言い過ぎだわ
話盛ってるわ

**デフォルトの名無しさん** · 2017/04/19(水) 20:05:24.07

>>228
間違ってしちゃうかもしれないし、どっかで誰かがしちゃってるかもしれんだろ

**デフォルトの名無しさん** · 2017/04/19(水) 20:07:46.83

あまりにもオブジェクト指向が当たり前になりすぎて、それがもたらしてくれるものを忘れてるだけだ

Cに++なんてついてなかった時代
配列を関数に渡すとき一緒に配列の長さを引数で渡してた
地獄のような時代があったんだぞ…

**デフォルトの名無しさん** · 2017/04/19(水) 20:11:22.44

>>229
言い過ぎじゃない
カプセル化の意図は隠蔽と独立

ガス欠で動かなくなった車に対してタイヤ交換はしなくていい
問題を切り分けて問題解決の速度を向上させるためにカプセル化はとても有効

**デフォルトの名無しさん** · 2017/04/19(水) 20:23:32.33

>>227
ちょっと絵に描いてみなよ

**デフォルトの名無しさん** · 2017/04/19(水) 20:26:00.72

『"このパーツの動作は保障されている"がないとプログラムは工業製品にならない』
ってのが始まりだしね。

ある意味「企業向けオーダーメードプログラムを手作業で人月かけてやるのが
職業プログラマって仕事なんだよっ！！」って請負業者がプログラマ名乗って
コンシュマーに売る工業製品としてのアプリケーションプログラム販売が傍流みたいになってる日本じゃ
「動きゃいい」が蔓延するのもしかたがないこと

**デフォルトの名無しさん** · 2017/04/19(水) 20:33:37.46

>>233
UMLでこの図なんていうんだっけ、名前は忘れたけどきちんと設計できる
https://www.fastpic.jp/images.php?file=0258982613.png

**デフォルトの名無しさん** · 2017/04/19(水) 20:34:11.59

端末変えたからID変わってるから

**デフォルトの名無しさん** · 2017/04/19(水) 20:35:16.70

>>232
それただのたとえ話じゃん
バグが寸分の狂いもなく立ちどころにわかるってのは言い過ぎだよ

**デフォルトの名無しさん** · 2017/04/19(水) 20:36:51.30

>>231
構造体に配列の長さと配列をセットで持たせればいいのに

**デフォルトの名無しさん** · 2017/04/19(水) 20:37:47.92

>>237
それは設計不足

**デフォルトの名無しさん** · 2017/04/19(水) 20:41:15.47

>>239
カプセル化に夢見すぎだよ
バグってる場所が3秒でわかるとか大嘘もいいところだよ
絶対嘘だね、どんなバグかもわかんないしさ

**デフォルトの名無しさん** · 2017/04/19(水) 20:41:33.40

まぁまぁ　ロジックの中が見えてバグがどこで発生しているかもすぐに分かる純粋関数が最強ってことで

**デフォルトの名無しさん** · 2017/04/19(水) 20:42:40.87

カプセル・スリー・セカンド

**デフォルトの名無しさん** · 2017/04/19(水) 20:44:01.82

>>240
誰が三秒って言ったのよ
速度向上と言ったまでさ

繰り返しになるけど所詮価値観の違いなので合わせてもらわなくていい

**デフォルトの名無しさん** · 2017/04/19(水) 20:46:48.18

>>243
速度向上ならわかるけど

**デフォルトの名無しさん** · 2017/04/19(水) 20:49:45.97

>>241
純粋関数ってメソッドの中でも再代入を許さないんだっけ？
それって遅くない？　モナド使わないと現実的に厳しくない？
すべてがモナドになればよくない？　そうしてできたのがC言語です

**デフォルトの名無しさん** · 2017/04/19(水) 20:58:24.07

>>245
そして構造化プログラミング、モジュールプログラミング、オブジェクト指向のカプセル化と来て
関数型に戻るわけですな

**デフォルトの名無しさん** · 2017/04/19(水) 21:02:34.85

>>246
極端なところに正解はないと思うんだよ
バランスが取れているのが現実的に最も優れている
カプセル化してないオブジェクト指向が最高ってことになるのかな？とどのつまり

**デフォルトの名無しさん** · 2017/04/19(水) 21:08:35.02

ちょっとは人の話きけりょ

**デフォルトの名無しさん** · 2017/04/19(水) 21:10:34.01

カプセル化してないオブジェクト指向のメンバーなんて
読みにくいグローバル変数みたいなもんじゃない？

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

>>248
聞く、どうぞお話どうぞ

**デフォルトの名無しさん** · 2017/04/19(水) 21:20:38.66

>>249
グローバル変数とは全然違う
フィールドはオブジェクトに属しています
オブジェクトがなければありません
オブジェクトを作って初めて使うことができます
オブジェクトのライフサイクルと運命をともにするからこそ
オブジェクト指向なんです
finalをつけるのがデフォ

**デフォルトの名無しさん** · 2017/04/19(水) 21:41:01.53

>>247
極端だろうが何だろうが正解なんかないさ
おまえはおまえの思いでやればいい

すべてを同じ枠に押し込めようとして八方塞がりにならないよう気をつけなよ

**デフォルトの名無しさん** · 2017/04/19(水) 21:56:25.91

>>252
俺が俺の思いでやるのは当たり前のことだと思うんだよ
雨が降ったら傘をさせばいいと言ってるようなもの
当たり前じゃん？いう意味なくない？
プールで泳ぐときは服を脱げばいいみたいな
出かけるときは靴を履けばいいみたいな
価値観の違いにこだわってるのはそっちのほうなんじゃないかなって思いました

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

カプセル化しないオブジェクト指向がモダンで優れた設計っていうのは
>>252と俺の共通認識としてあるわけだから、その上で思いを語っていただけたら

**デフォルトの名無しさん** · 2017/04/19(水) 22:03:04.69

>>254
俺はカプセル化推奨だぞ

**デフォルトの名無しさん** · 2017/04/19(水) 22:06:05.25

>>255
フィールドが全部finalだったらprivateなんて必要ないだろ？
つまり、カプセル化って必要なくない？

**デフォルトの名無しさん** · 2017/04/19(水) 22:07:41.10

隠すメリットより公開するメリットの方が莫大だと思わない？

**デフォルトの名無しさん** · 2017/04/19(水) 22:18:28.62

公開するメリット隠すデメリットを考えよう

**デフォルトの名無しさん** · 2017/04/19(水) 22:22:01.02

思わないなぁ
カプセル化って無駄を省いてわかりやすいものにして再利用しやすいよう作ることと思ってるからね

そもそもカプセル化はフィールドだけじゃない
インターフェースを用いて処理を委譲させるように設計してしまえばデータだけじゃなく処理を丸ごと隠蔽できるしオブジェクト間の依存関係も稀薄にできる

**デフォルトの名無しさん** · 2017/04/19(水) 22:26:31.08

>>259
なるほどね、それはあるね

**デフォルトの名無しさん** · 2017/04/19(水) 22:27:13.48

カプセル化完全に理解した

**デフォルトの名無しさん** · 2017/04/19(水) 22:34:52.50

おめでとう
まぁ俺はまだまだ勉強中だからうらやましいよ

**デフォルトの名無しさん** · 2017/04/19(水) 23:01:17.77

>>256
通りすがりだが、年齢フィールドとか一定の幅に制限したい時に勝手に300歳とか設定されたら困るだろう。
だからprivateにしてメソッドやプロパティで0-120なりの範囲に制限するようにするんじゃないの？

**デフォルトの名無しさん** · 2017/04/19(水) 23:08:00.65

>>263
入力チェックをデータがやっていいものか
これは議論が別れるところですよ

**デフォルトの名無しさん** · 2017/04/19(水) 23:10:42.57

>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？

**デフォルトの名無しさん** · 2017/04/19(水) 23:12:01.85

>>265
代数的データ型とはなんぞや？

**デフォルトの名無しさん** · 2017/04/19(水) 23:13:00.35

「300歳なんてあるわけないからカチカチに型で数字の範囲を絞ればいいんだよ」
「300歳なんて異常な数字を送らないように送り手が責任を持つべきだ」
「300歳が送られてきても"数字がおかしい"って返事するようにすれば良くね」

どれがいいと思うかで、その人のそもそものスタンスとセンスがわかるな。

**デフォルトの名無しさん** · 2017/04/19(水) 23:16:21.53

>>267
俺ならチェックせずに文字列のフィールドにそのままセットしちゃうね、純粋オブジェクト指向

**デフォルトの名無しさん** · 2017/04/19(水) 23:19:37.80

type c = a or b
みたいな？

**デフォルトの名無しさん** · 2017/04/19(水) 23:20:37.20

これもオブジェクト指向と言ってもいいでしょう！

**デフォルトの名無しさん** · 2017/04/19(水) 23:21:42.97

ちなみに最後のがいちばんオブジェクト指向っぽくて
大きな仕様変更に強いゆるさがあると思うけど
カチカチが好きなタイプのプログラマーは"ゆるさ"の部分が
許せないのだろうな。

**デフォルトの名無しさん** · 2017/04/19(水) 23:23:56.87

>>264
え、でもそうでもなきゃ、データの外部でデータチェックとかは関数型言語や構造化プログラミング的な発想だけど。
副作用あるのに、その発想は危険過ぎない？
他の誰かがその外部のチェック用クラスを使ってくれる保証は無いよ？

**デフォルトの名無しさん** · 2017/04/19(水) 23:30:11.23

>>272
必要なら必要になったとき必要な人が自分で作れば良いじゃん、自由と自己責任の精神だよ、ルールで縛られたガチガチのオブジェクトじゃままならぬ事もあるでしょう！

**デフォルトの名無しさん** · 2017/04/19(水) 23:33:14.31

>>267
オブジェクトが各々責任を持つとするなら、それぞれのクラスでデータチェック(ダブルチェック)が正解なんだろうね。
じゃないと、その二つのクラスは二つで一つになる。
依存関係が出来てしまう。
違うクラスでも、年齢に関するデータなら受け取れるようにした方がいいんじゃ無いかな。

実際には依存関係呑み込んでどっちかしかチェックしないってのが多そうだが。

**デフォルトの名無しさん** · 2017/04/19(水) 23:34:21.76

"誰がその数値に責任を持ってるか"っしょ。
それを明確にできてればそこを修正すればいいけれど
「私は知らない」「私は受け付けない」「私の責任ではない」って
例外の責任が見えないと責任者探しから始めなくちゃいけなくて
後から来たプログラマが死ぬ。

**デフォルトの名無しさん** · 2017/04/19(水) 23:37:47.94

。。。オブジェクト指向は事なかれ文化の日本と相性悪いんじゃ無いかと思えてくる文言ダネ＾＾;

**デフォルトの名無しさん** · 2017/04/19(水) 23:39:15.89

テストすれば良いじゃん

**デフォルトの名無しさん** · 2017/04/19(水) 23:41:15.55

ちゃんとオブジェクトが連携できてるかなって
そうだよ僕たちには結合テストがあるじゃないか

**デフォルトの名無しさん** · 2017/04/19(水) 23:46:37.27

値を変換するコンバータクラスと値をチェックするバリデータクラスがあれば良いじゃないか
責務の分離だよ

**デフォルトの名無しさん** · 2017/04/19(水) 23:48:34.03

データ保持するクラスがチェックまでやるのは複雑すぎるよ、素直じゃない

**デフォルトの名無しさん** · 2017/04/19(水) 23:51:12.30

オブジェクトも大事だがコラボレーションも大事

**デフォルトの名無しさん** · 2017/04/19(水) 23:52:23.70

連投せずにまずは落ち着くのが大事

**デフォルトの名無しさん** · 2017/04/19(水) 23:57:15.78

目的の動きを満たせばだいたい正解なんだから熱くなるなよ
自分の意見を押し通したいのはわからんでもないがな

**デフォルトの名無しさん** · 2017/04/20(木) 00:29:25.65

208 デフォルトの名無しさん[sage] 2017/04/19(水) 12:20:37.70 ID:rIlDsUIc

継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向

265 デフォルトの名無しさん[sage] 2017/04/19(水) 23:10:42.57 ID:2dTlCsss

>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？

266 デフォルトの名無しさん[sage] 2017/04/19(水) 23:12:01.85 ID:qOdNs+TP

>>265
代数的データ型とはなんぞや？

269 デフォルトの名無しさん[sage] 2017/04/19(水) 23:19:37.80 ID:qOdNs+TP

type c = a or b
みたいな？

270 デフォルトの名無しさん[sage] 2017/04/19(水) 23:20:37.20 ID:qOdNs+TP

これもオブジェクト指向と言ってもいいでしょう！

こんなん草生える

**デフォルトの名無しさん** · 2017/04/20(木) 07:19:48.83

チェックも色々とデータが必要なとき多いしな

**デフォルトの名無しさん** · 2017/04/20(木) 11:36:45.75

>>216
> ocpは耄碌したメイヤおじさんの考えだろ
> オブジェクト指向がブラッシュアップされる前の
> 無駄の塊だった頃の話だ
そうでもないけどね。
https://ja.wikipedia.org/wiki/%E9%96%8B%E6%94%BE/%E9%96%89%E9%8E%96%E5%8E%9F%E5%89%87
今でも、OOPの五大原則のひとつとしてあげられるのが普通。

> 最新のオブジェクト指向では継承もカプセル化も
> 害悪でしかないことがわかってる
そうなんだ、それは知らなかったよ。

**デフォルトの名無しさん** · 2017/04/20(木) 14:18:44.61

継承は特定の親に縛られすぎるのであまりよくないね。ってなってるが
カプセル化はむしろ危険な直接アクセスを防ぐ意味で常識になってる気が。

**デフォルトの名無しさん** · 2017/04/20(木) 20:00:36.90

やっぱりインターフェースこそオブジェクト指向だよな

**デフォルトの名無しさん** · 2017/04/20(木) 20:17:41.83

>>287
でもカプセル化って汎用性悪いじゃん
変数１つアクセスできないだけで実現したいことできなくなっちゃうかもよ?

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

それもうわざわざクラス使わずに構造体使っちゃいなよ

**デフォルトの名無しさん** · 2017/04/20(木) 20:29:03.08

悪い依存関係はそのコードの利用者にコピベプログラムを強いる
これ経験則な

**デフォルトの名無しさん** · 2017/04/20(木) 20:37:59.47

汎用性ならインターフェースと抽象クラスじゃねーの？

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

>>286

> 最新のオブジェクト指向では継承もカプセル化も
> 害悪でしかないことがわかってる

まーたくだらない嘘をつく
すぐにバレるのわかってるだろｗ

害悪でしかないならば、lintなどのツールで使うなって警告が出るはずだ。
そういったlintツールがない（継承やカプセル化を使った時にエラーにする方法がない）
もとから、害悪でしかないっていうのは完全に間違いだ。

反論があるならどうぞ

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

>>289
それ汎用性ちゃうで。
そんな内部実装の細かいとこ勝手に使われたら、バグ修正すらなんの影響があるか怖くてできんくなる。
結局特定用途にしか使えなくなる。

**デフォルトの名無しさん** · 2017/04/20(木) 21:44:56.84

結局、privateっていうのは、

この変数は外部から直接触ることを想定していません。
決められた値以外を入れた時の保証はしませんし、
将来の変更で互換性がない形に変更する必要がありますので
参照しないでください

とコメントで書くわかりに、コンピュータでも理解できる
言語で書くってだけの話なんだよね。

**デフォルトの名無しさん** · 2017/04/20(木) 21:46:00.98

あ、もちろんprivateを使ったほうが良いって話だよ。

コメントで長々書いても読まないし、
ソースを見ないかもしれない。

そういう時にコンピュータでも理解できる言語で書いていれば
コンパイル時にしっかりチェックしてくれる。間違いがない。

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

>>294
クラスなんて使わなければいいのでは?

**デフォルトの名無しさん** · 2017/04/20(木) 21:53:58.83

>>293
帰納的な推理は往々にして間違うものなんだよ

**デフォルトの名無しさん** · 2017/04/20(木) 21:55:36.70

>298
ちょっと邪魔しないで、

反論が出てくるかどうか待っている所だからｗ

**デフォルトの名無しさん** · 2017/04/20(木) 21:56:45.24

マンコが本当にあるなら俺のチンコが純粋であることの説明がつかないみたいな

**デフォルトの名無しさん** · 2017/04/20(木) 21:57:23.53

>>299
反論がでない＝正当性が証明された
などと言うつもりかい？

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

純粋チンコ型論理

**デフォルトの名無しさん** · 2017/04/20(木) 22:03:33.81

>>297
クラスわ使わないでどうやってデータを管理する？
配列か？

**デフォルトの名無しさん** · 2017/04/20(木) 22:07:49.44

カプセル化は正しい方向性だというのは賛成だが
lintで警告が出ないからという権威主義的な根拠はどうなのか

**デフォルトの名無しさん** · 2017/04/20(木) 22:10:46.32

>>290
構造体を使うとしてその構造体に連関する関数をどうやって整理する？

構造体ごとにファイルを分けるのは面倒だし、認知行動学的に考えて厳しくない？

整理することこそプログラミング、そのコストが低い言語が良い言語だと思うんだよね

**デフォルトの名無しさん** · 2017/04/20(木) 22:12:10.00

>>297
せやな。
必要性がないと判断したんなら使わなければいいんじゃないか？
間違ってないと思うで。

ただまあ、構造体が必要になる所では、ほぼ間違いなくクラス化した方が使い方の見通しが良くなるで。

**デフォルトの名無しさん** · 2017/04/20(木) 22:12:52.70

自分で考えるってことをしないんだろ

他人の定めたルールが正当である
それが目に見える形とならねば虚構である

むなしいね

**デフォルトの名無しさん** · 2017/04/20(木) 22:13:09.41

>>301
それで何か問題あるの？

**デフォルトの名無しさん** · 2017/04/20(木) 22:14:14.53

俺様が決めたルール（＝害悪でしかない）が正当であると思ってるんだろうねｗ

だから俺様以外が決めたルールであるかどうかを確認している。
さて反論は？

**デフォルトの名無しさん** · 2017/04/20(木) 22:15:28.83

俺は今ガリレオさんの気持ちだ

**デフォルトの名無しさん** · 2017/04/20(木) 22:17:39.49

>>308
おまえが満足するならそれでかまわないよ
別に誰かに認められるために学んでるわけじゃないし

もっとも残念ながら俺はカプセル化については推奨派なので反論とかするまでもなくどーだっていい
ただおまえの発想はかわいそうだと思うだけ

**デフォルトの名無しさん** · 2017/04/20(木) 22:18:02.65

死に際にそれでも地球は回っていると言ってのけたガリレオさんも気持ちだ

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

>>311
そういうことは最初から言わないか？

なんで俺に「反論がでない＝正当性が証明されたなどと言うつもりかい？」と聞いた？
最初から「反論が言えなくても、正当かもしれないだろ！」と言えばいいじゃないか？

それがお前が本当に言いたいことだろ？

それならそれで俺は最初からこう答えるよ。
だから、お前が言っていることを正当だと他人に認めてもらうために、
お前は反論（信頼性があるソース）を出せって。

はい、で、信頼性があるソースは？

**デフォルトの名無しさん** · 2017/04/20(木) 22:24:14.04

それでもカプセル化は必要ない
lintはろくでも無いクラス設計がまかり通っていたときの負の遺産だ、javabeansやcomが盛んに作られた時代の名残だ、隠蔽して守られるより公開して守られるクラス設計を目指すべき

**デフォルトの名無しさん** · 2017/04/20(木) 22:25:02.69

>>313
ソースは俺

**デフォルトの名無しさん** · 2017/04/20(木) 22:25:24.28

補足しておくと「継承やカプセル化が害悪でしかない」という仮説が
正しいという信頼性がある（俺様が決めたルールではないとう）ソースを出せ。
という話ね

**デフォルトの名無しさん** · 2017/04/20(木) 22:26:09.67

ソースは現代のガリレオです
よろしくお願いします

**デフォルトの名無しさん** · 2017/04/20(木) 22:27:09.43

>>313
見識が狭すぎるのは大変だよって言いたいだけさ

繰り返しになるけど俺はカプセル化について推奨派なので反論するつもりは全くない
おまえの論調は嫌いだがな

**デフォルトの名無しさん** · 2017/04/20(木) 22:29:33.08

>>318
それを言うなら相手が違うだろ。

見識が広いやつに対して、
お前の広さを（証拠を出すことで）示してやれ！と言うべきだ。

それが俺も言っていることなんだけどなｗ

で、信頼性があるソースはよ

**デフォルトの名無しさん** · 2017/04/20(木) 22:30:20.01

>>305
俺の経験上はだけど、それオブジェクト志向じゃない方がむしろやりやすいで

**デフォルトの名無しさん** · 2017/04/20(木) 22:30:37.36

ソースは？の問いに対して
有無以外のレスを繰り返す相手を
それ以上いじめてはいけない

**デフォルトの名無しさん** · 2017/04/20(木) 22:31:02.97

昔は暗号化のロジックも隠すことで安全性を担保しようとしていたけど、駄目だったんだよ、現代ではロジックを公開できる暗号化こそが真に安全性を備えていることがわかっている

それと全く同じことでいくらプライベートにしようがリフレクション使いまくる現代のプログラミングでは役に立たない、パブリックにしても問題ないように作るのが真のオブジェクト指向

**デフォルトの名無しさん** · 2017/04/20(木) 22:32:10.96

>>319
ソースは今お前の目の前に居る
さあ

**デフォルトの名無しさん** · 2017/04/20(木) 22:32:34.93

>>319
そうかい
ならば俺にソースを求めることが見当違いだということにも気づいてくれ

**デフォルトの名無しさん** · 2017/04/20(木) 22:33:31.06

>>320
どうやるん？　クラス作らないとできなくない？

**デフォルトの名無しさん** · 2017/04/20(木) 22:33:55.62

>>322
その理屈を使いたいならば、ロジックは公開すべきある。
共通鍵暗号方式でも公開鍵暗号方式でも、秘密鍵（データ）は隠すことで安全性を保っている。

そのことから・・・と話をするべきだ。

**デフォルトの名無しさん** · 2017/04/20(木) 22:35:08.71

>>324
カプセル化が必要ないことを説明しろよ

**デフォルトの名無しさん** · 2017/04/20(木) 22:37:17.66

>>327
だからカプセル化について推奨派って言ってんじゃねーか
推奨派が必要ないと考えるわけねーだろーが

少しは考えて発言しな