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

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

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

**デフォルトの名無しさん** · 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
だからカプセル化について推奨派って言ってんじゃねーか
推奨派が必要ないと考えるわけねーだろーが

少しは考えて発言しな

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

>>326
秘密鍵はパスワードとかそういう類の物だからそもそもプログラム内に持たないんだよ

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

>>329
プライベート変数は、ファイルに保存しろって言いたいわけ？

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

>>330
秘密鍵はプログラムに書くものじゃないと言いたいのさ

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

>>331
だから秘密にしたいデータ（他のクラスから参照されたくないデータ）は
プログラムに入れずにファイルにしておけってことだろ？

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

>>328
派閥でどうこう言うんじゃなくていち個人として良心から発言していただきたい、カプセル化が必要ないんだという思いと向き合うべきだと言ってるんだよ

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

こいつ相当のバカだな

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

>>332
違う違う秘密鍵はプログラムに書くものじゃないと言ってるんだよ

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

リピートアフターミー
秘密鍵はプログラムに書くものじゃない

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

カプセル化はオブジェクト指向じゃない

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

>>335
じゃあ他のクラスから秘密にしたいデータは？

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

>>338
公開しなさい

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

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

違う違う。それは「暗号化ロジック」は公開しろって話なんだよ。

リピートアフタミー「暗号化ロジック」は公開しろ。

それ以外の話は公開しろって意味じゃない。

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

>>339
なんで？

秘密にしたいデータは、暗号化ロジックじゃないよね？
公開する理由がない。

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

>>340
暗号化ロジックは式という形式のデータです

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

password.txtに書いてgithubにコミットやろjk

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

>>342

暗号化ロジック = 式という形式のデータ

故に

式という形式のデータ = 暗号化ロジック

と言ってる？
それは明らかに間違いだよ。

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

式という形式のデータ、
そこにはいろんなロジックがある。
その沢山の種類のロジックの中で
暗号化ロジックだけは公開しろ

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

>>333
べき論はよくわからんが、そこまで言うなら個人として伝える

カプセル化は絶対必要である
なんならオブジェクト指向のキモだとも考える
目的に特化させ再利用できるようにデザインすること
きちんとネーミングすること
多様性を持たせるならばインターフェースを用いて処理を実装し移譲すればよい

以上

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

ID:rIlDsUIc = ID:Rk6y34sG だよね?
昨日はシラフで今日は酔っ払っているのかな?

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

>>343
冗談じゃなくそういうのあるらしいね
awsのなんかあれ

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

OOPに必要かどうかしらんけど
カプセル化は単に便利だよね
スコープ的な意味で

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

横からカプセル化の話題を眺めていたが、素晴らしいカプセル化のアイデアが湧いてきた！

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

>>325
最初はクラスの下にでも書いたらいいよ
少なくとも中に書くよりは読みやすいし
後は必要に応じて慣れやね

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

インターフェースこそオブジェクト指向だという意見に全面的に同意。
継承自体はクラス目線でモジュール化を進めた結果で得られる構造なだけであって、
インターフェースのように型を意識させることはない。
結果的にはインターフェース+基底クラスパターンが最強だと思うわ

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

アルゴリズムを試行錯誤している時はグローバルな構造体の方が楽。
デバッグや保守の時はカプセル化されたオブジェクトの方が楽。
これはmutableとimmutableにも同じことが言える。

カプセル化しないmutableオブジェクトの方が考えやすいなら
プロトタイプ開発ではそうすればよい。
設計が決まったらできるだけカプセル化したimmutableオブジェクトに変えよう。

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

>>351
関数の名前に構造体の名前を入れるん？　面倒じゃない？

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

>>353
不変のものをカプセル化する意味あるのか？
フルオープンでよくね？