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

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

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

**デフォルトの名無しさん** · 2017/04/17(月) 21:56:46.03

>>181
> コーヒーを飲むって動作は誰にさせると上手くいきますか？
メソッド＝動詞を実行できる人

>>182
2つの物体の相互作用は、それぞれの物体の作用に分解できる

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

>>183
それを設計するとナメるという行為と石原さとみのおっぱいのたゆみ、それによるコーヒーの流れ、流れに応じた舌の移動、さらに石原さとみの悶えという不確定要素など複数のオブジェクト間のフィードバックループを形成しないといけない
現実をプログラムにするというのは非常に難しいものだ

**デフォルトの名無しさん** · 2017/04/17(月) 22:16:18.42

オブジェクトはメソッド実行するときはたいてい目的語
でもたまに、処理を移譲するよなときは主語になる

一定してないから混乱の原因
自信ついたあたりで現実のモデリングをしようとすると面食らう

**デフォルトの名無しさん** · 2017/04/17(月) 22:26:26.94

だいぶ前にこの類いのスレ立ててる奴が
「コーヒー」クラスが「ドリンク」メソッドで「プログラマー」に代入されてるジョークTシャツ持ってきて
「だからオブジェクト指向は～」ってやってたのの本人による再放送でしょ。
キャットドア誰も相手してくれなくなったから。

**デフォルトの名無しさん** · 2017/04/17(月) 23:55:38.00

メソッドは状態が変化する物に帰属させないとオブジェクト志向の意味ないよね

**デフォルトの名無しさん** · 2017/04/18(火) 00:38:27.27

>>188
そんなことはないよ。

**デフォルトの名無しさん** · 2017/04/18(火) 07:13:33.23

去年.NET3.5の新規開発で
VB9.0を選択しちゃうウチの職場は
未だにオブジェクト指向を導入していません

そろそろオブジェクト指向開発を調査した方がいいでしょうか

**デフォルトの名無しさん** · 2017/04/18(火) 09:09:55.12

その程度の仕事しかしてないということなので不要です

**デフォルトの名無しさん** · 2017/04/18(火) 09:59:29.58

キャットドア問題も解決できないオブジェクト指向は不要

**デフォルトの名無しさん** · 2017/04/18(火) 12:33:10.21

NGワード：キャットドア
これでスッキリ

**デフォルトの名無しさん** · 2017/04/18(火) 13:42:04.65

キャットドア厨はオブジェクト指向以外で問題解決してみてから言えよ
これやらないからカスなんだよ

**デフォルトの名無しさん** · 2017/04/18(火) 17:45:27.51

>>194
オブジェクト指向以外に解決策を求めてる時点で草ｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2017/04/18(火) 17:58:40.72

cat.open(door), cat.open_door()
person.drink(cofee)

**デフォルトの名無しさん** · 2017/04/18(火) 20:10:28.20

何通りか解決してただろ
なんでリセットされてるんだよ

**デフォルトの名無しさん** · 2017/04/18(火) 20:35:48.45

>>197
悪魔の証明と化してる

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

>>192
朗報だ
キャットドア問題をオブジェクト指向で完全に解決した
https://paiza.io/projects/9D_RVq0fdaUXDugXFTpp2g

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

オブジェクト指向のおかげです

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

オブジェクト指向完全に理解した、超簡単だった

**デフォルトの名無しさん** · 2017/04/18(火) 22:37:17.80

人間だけ中身からっぽでわろｗ

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

恣意的な

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

>>189
カプセル化しないの？

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

>>199
n種類の操作主体がいて、m種類の操作対象があるとき、DoorOpener的なクラスをm個作り、それぞれにnこのメソッドを作るのか？
操作主体が一つ増えると、既存のm個のクラスにそれぞれ一つのメソッドを追加する必要がある
また、操作対象が一つ増えると、あらたにn個のメソッドを作成する必要がある

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

>>205
ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな

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

>>204
カプセル化は頭空っぽの木偶の坊のためにある
オブジェクト指向の本質とは程遠い

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

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

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

複数性が重要事項

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

文字コードを相互に変換するときいったんウニコードに変換するように、対象や主体をそれぞれ抽象化オブジェクトに変換すればよいのかもね

対象と主体の操作は抽象化オブジェクトに対して行うようにしておけば、対象や主体が増えたとしても抽象化オブジェクトへの変換だけ実装すればよい

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

抽象化オブジェクトに変換を行うトランスフォーマクラスと抽象化オブジェクトに対する操作を行うプロセッサクラスがある

具象オブジェクトが追加されたときはトランスフォーマとプロセッサを変える必要がある

見通しはいいかもわからんね、抽象化オブジェクトの関係は一箇所に集約されるから

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

pコードみたいだな

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

やっぱオブジェクト指向最高だな

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

>>207
木偶の坊が何か実装するときに何も考えさせないためにカプセル化するんだと思ってたわ

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

>>206
> ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな
まあ、あのコードが最小限だとして、その範囲ですらOCPに違反してるんじゃないですかねって指摘なんだが。

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

>>215
ocpは耄碌したメイヤおじさんの考えだろ
オブジェクト指向がブラッシュアップされる前の
無駄の塊だった頃の話だ

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

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

>>214
オブジェクト指向が浸透するまでは有益だったかもしれないが、今や誰もがオブジェクト指向を熟知し使いこなす時代、カプセル化はロジックを不鮮明にするノイズでしかない

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

メイヤおじさんは実装の継承を推奨する老害だからな
バージョン管理ソフト使えよと

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

プレインクラスこそオブジェクト指向の本質

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

>>217
不鮮明となるのであればそれは用件が曖昧であるためカプセル化できてないと俺は考える
エンジンの仕組みを知らなくてもアクセルを踏めば車は動くようにわざわざ考える必要もない事は隠蔽しちゃおうぜ！ってのがカプセル化だと思ってる

まぁ解釈はそれぞれだから合わせてもらわなくていいけどね

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

フスマと回転扉で同じキャットドアで済むわけないじゃん
これを違うものとして組めないコードは問題

結局、キャットドアなんだよ

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

>>220
それもそうだな

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

>>221
ドアクラスの変数名をふすまにすればいと思うの
難しく考えずにシンプルな解決策を探そうよ

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

>カプセル化はロジックを不鮮明にするノイズでしかない
寝言にもほどがある

中が丸見えで依存しまくってたら
何かするたびに処理の全体追わなきゃいけなくなるだろうが

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

>>223
フスマと回転扉で同じキャットドアが使えると思ってらっしゃる?

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

>>224
ほんとこれ

カプセル化のおかげでどこにバグがあるかもはっきりする

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

>>225
はい

**デフォルトの名無しさん** · 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

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