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

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

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

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

とどのつまりカプセル化は理解できないものなんだな？

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

>>366
もしかして低産階級労働者だった？これは申し訳ないことを書いた。失礼

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

>>369
ホントだよ！失礼極まりないよ！

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

低産階級労働者は傷ついているのです

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

私は被害者です

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

どうしてLispにはクラスがないんだろうか
みんなで考えてみよう

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

>>373
クラスを使わないという発想で作られたから
別にいい悪いじゃなくて、ただ単にモットーの問題

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

>>374
でもクラスは便利ですよ

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

クラスがない、つまりカプセル化もできない？

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

手続き型言語でも定数はグローバル変数でも問題無いんだし、関数型言語の変数はほぼ定数みたいなもんだし。
カプセル化の恩恵そのものがあんまり無い希ガス。

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

そもそも仕様書に書くべき問題をソースなんかに記述しようとするからこうなる

なんだよカプセル化って
ガキの使いでソースに手を入れようとしてるキチガイでもサポートしたいの?
ほらほらボクチンここprivateだから他のクラスから触れないからね!

チンカス過ぎる

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

カプセル化はそもそも代入禁止じゃなくて隠蔽なんだが理解して書いてるのか？

SRP原則に則るならカプセル化のほうがいいに決まってる

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

なぜ隠蔽するかって言うと、不用意な変数の書き換えをさせない為。
関数型言語の場合は必ず変数の書き換え(と言うか再生産だが)を行うには関数を経由する。
変数を隠蔽したい場合は、パッケージで変数や関数単位で公開非公開を指定する。

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

>>379
誰から何を隠蔽するためのものなのか明確になってないんだよ

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

例えばライブラリ提供者と使用者
使用者はライブラリ側のソースを一切触ることがなく
提供者は使用者側からの問い合わせや変更依頼を断れない
ここまで立場が明確なときに隠蔽は意味を持つが

すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない

と俺は思う

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

>>380
それだと参照するだけならいいってことになっちゃうよ？
隠蔽するなら不用意な参照もダメだよね。

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

>>380
隠蔽はその変数の操作をそのクラス内に限定するためにある
プロパティを介してprivate変数に代入や参照ができるようにしてるのもそのため
変数の書換禁止ならそれこそfinalつければ済む

>>382
>すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない
誰がいじろうとも修正箇所をクラス内に限定する意味はあるだろ

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

>>384
だからそんなものはアプリケーションの仕様の前には意味を成さないんだよ

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

車とタイヤをオブジェクト指向で表現する場合、車クラスにタイヤ属性を持つのが良いでしょうか

それぞれクラスを持ってる方が良いでしょうか

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

>>383
マルチスレッドでも言われるが、参照だけなら基本問題無い。
上でも書かれている通り、隠蔽したければカプセル化じゃ無くても方法はある。

カプセル化と言うか、クラスと言う型に関数(メソッド)や変数(フィールド)を押し込めるのと、関数プログラミング的な考えはメリット/デメリットがそれぞれある。

クラスは依存関係が出来やすいが、GUIなどの多くの状態を保持するのに向く。
一方の関数プログラミングはデータと関数が分かれるので依存関係を少なく出来るが、状態を関数の引数として引き回すのでGUIに向かない。

関数型言語ではa = 1はそのプログラムではずっと1で、2が欲しければinc a とか、succ aとか関数の結果として2を受け取る。

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

>>385
納品したら終わりってアプリを組むときにはカプセル化なんて確かに無用だけど
そもそもカプセル化とかその先のデータ抽象（抽象データ型）とかは、アプリが動いたり大規模化したあと
それをメンテしつつ運用（ちょっとしたバグ修正だけでなく、拡張や機能改変を含め）し続けるときに
それをやりやすくする技術だからなぁ…

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

>>385
個人開発ならばまぁわからんでもないが発想が危険すぎる
頼むからめんどくさいバグを作り込む前にプログラムから手を引いてくれ

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

>>389
何を言ってるんだよ
誰から何を隠蔽するのか明確にしろよ

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

>>389
お前のソースって読み手が完全な傍観者である場合は意味があるけど
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいんだろ
privateにした変数がクラス内グローバル変数みたいな動作してる典型だよね

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

>>387
だからいくつかある方法のひとつがカプセル化なんだよね？

>>390実装依存しようとしている人間から実装を隠蔽するんじゃね？

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

>>392
全然意味がわからない
対象のクラスに手を入れようとしてる人間に対して隠蔽したいの?

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

「実装依存しようとしている人間から実装を隠蔽する」

これ以上どう簡単に言えるのか？

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

>>391
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいだろ
publicにした変数がクラス外にも波及するグローバル変数みたいな動作してる典型だよね

どこまで影響すると思ってるんだ
調査、設計、対応、試験にかかる工数がとんでもない数値になる

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

>>394
全く意味がわからない
外部設計書とか内部設計書とか
以外の仕様書があってそれに基づいて作成してるの?

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

>>396
ところで全然わかってない自覚があるのになぜ不要と言い張れるの？
不要である理由を明確にしろよ

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

ていうか読み込んだデータに基づいて処理するも
ソースに記述した定数で処理するも仕様書次第じゃないの?
実装依存が何を指して実装依存って言ってるのかわからない

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

>>397
どのレスの不要?
引用して欲しい

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

>>399
カプセル化不要についてだよ

まさかひとつひとつ違うことに対して不要だと言いまくってたの？

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

知らなくてもなくても作れるのだから不要。
極論すればアセンブルでも作れる。

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

>>400
カプセル化の不要についてだね
おｋ

まず処理の動作は設計書に書くものだろう
ソースでprivateやpublicになってるからどうだってんだよ

ここで反論ある?

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

実装がpublicだと他人がその実装に依存して良くないことがありそうだ。参照だけでもマズい。
だからprivateにして実装を隠蔽する。

これのどこに分かりにくい点があるというのか？
設計書とか仕様書とか関係なかろう

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

>>402
ある
利用者は仕様書を確認することなく意図しない方法で利用する

他は？
と言うか一度に全部言ってくれ

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

>>404
利用者って誰?
ソースを改変するソイツ（?）は設計書を記述せずに対象のクラスを変更しようとしてる?
ソイツのことを利用者と呼んでいてお前の環境では存在しうるの?

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

あぼーん

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

個人製作の観点からはカプセル化はいらんな
テンプレートか抽象タイプと多重ディスパッチあれば継承もいらんしミックスインもいらん

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

>>405
実装する人が複数いる時、自分が作ったクラスのメンバ変数やメンバ関数を利用して
その人の担当クラスを実装する他人が自分のクラスの利用者だろう。
自分が作ったクラスも他人が作ったクラスも変更するのは作った人だけだ。

実装を一人で行える規模ではカプセル化の必要を感じないという話なら分かる。
でも前提なしでカプセル化は不要と主張したら大規模ソフトウェアも含まれる。
もしかして大規模ソフトウェアで必要かどうか全然考えてなかったの?

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

だからホリデープログラマーと話しても無駄やて

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

むしろここで仕事の話をする方がおかしいけどな

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

>>408
担当のチェンジは無しなの？

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

>>405
話が止まるからまずは全量を語ってくれ

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

カプセル化されていると、メンバ変数とアクセサは分離され、外部のクラス利用者（ユーザコード）はもっぱらアクセサを呼ぶことになる。
仮にメンバ変数の実装の詳細を変更することになっても、アクセサを変更しない限り、ユーザコードは変更する必要はない。
間接層の導入による変更の局所化やね。

メリットと煩わしさの比較は人により異なりうるが、少なくとも必要なケースは少なからずあると思うが。

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

せっかくカプセル化してもアクセッサなんか作ったら不自由になる。
変数を廃止したり形式の変更をしたりしにくくなる。

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

>>408
じゃあ利用者ってのはクラス使用者（そのクラスには絶対に手を加えない）のことでいいの?

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

>>415
そうだよ
javaで言うならStringクラスの利用者はStringクラスの内容を変更しないだろ

いちいち立ち止まらずまずは全量を語ってくれ

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

【全量】全体の重量。全体の容積。

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

>>417
ありがとう

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

>>416
ほうほう
だったら仮にそのクラス自体に手を入れることになった場合は
隠蔽対象者ではないということでおｋ?

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

>>419
うだうだ言ってねーで早く語れ

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

相手にしない方がいいよ時間と労力の無駄
ID:YTf7CJ3Gが楽しんでやっているならとめないけど

あ · 2017/04/21(金) 13:05:41.49

何十年前の話なのかわからなくなるな

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

>>422
いつ何度でも話していいことだと思うが
会話ってそういうものだと思う

人の色恋沙汰なんて4000年前に語りつくされているが
今なお人の心をとらえて離さないだろ

オブジェクト指向にとってカプセル化とは
それくらいの魅力があるものだってこと

会話っていうのは昔々誰々がすでにいったことだから
言っちゃいけない、話しちゃいけないなんてもんじゃない

会話に入りたいって素直に言うべき、カプセル化やめるべきって
ちゃんというべき

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

>>421
ありがとう
うんこタイムの暇潰しなので大丈夫だよ

>>423
べき論はよくわからん
そんなことよりも不要である理由を早く『明確』にしてくれ

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

>>410
仕事の話ではなくオブジェクト指向の話だろ？
おれは１人で好きに作ってるからカプセル化なんていらねー！といわれても会話にならないよ

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

>>425
それはそうだが、誰とどういうレベルで会話するのかってことだろう。
その前にホリデープログラマがどうたらってレスあるから。

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

>>424
お前が明確にするんだよ、カプセル化やめるべきだって言うんだよ
お前の仕事だよ

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

この業界趣味でやってる人の方が技術力高かったりするからね
サンデープログラマを馬鹿にしちゃいけない

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

>>427
俺は必要だと思ってるから無理だな
不要である理由を明確にするのはおまえだ

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

データのカプセル化なんてプログラム上どこまで触って(参照/代入)いいかの線引きを決まりごとからシステム的に制限したかの違いなだけでしょ
c言語のFILE構造体の中身を参照する事はないでしょ。stdio.hに定義されていても
それは暗黙的な決まりごとだからだし、それをアクセス修飾子で明示したのがカプセル化って言葉なだけで昔からの決まりごととしては変わらない

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

>>429
どうして必要だと思ってるのか全量を言えよ、じゃないと理解できない

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

>>430
その決まりが要らないものだったんじゃないかっていうのが
カプセル化害悪論の骨子なんだよ

暗黙的なものは暗黙的なままでよかったんじゃないか？
なぜ明示する必要があったのか、それによってプログラムが
複雑になることを受け入れるのか、プログラムがブラックボックス化することに
歯止めをかけてクリーンなオブジェクト指向を取り戻そうというのが
カプセル化害悪論のモチベーション

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

>>431
聞いてるのはこっちだ
はぐらかすな

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

>>433
聞き返したのは俺だ、ちゃんと全量を示せ、逃げるな

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

質問に対する答えが質問になる程度の考えしか持たぬならもういいわ

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

>>435
捨て台詞まで吐いて逃げるのな？

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

もういいわて、お前は漫才師か！

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

そだね

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

はい逃げた、結局カプセル化を支持するやつって中身のないその場限りの
見栄を張って問い詰められたら逃げるだけの俄かなんだよな

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

そだね

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

>>432
カプセル化害悪論ってのは一理あるし正しいと思うけどね
性善説と性悪説みたいなところだから正解はでないと思うし
ただ、このスレのカプセル化反対の意見はそんなレベルの話じゃない、そもそも議題のカプセル化の認識ズレの話なんじゃないのかな

**デフォルトの名無しさん** · 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
そもそも、キャットドア問題とか知らんし
他人のコード書いてほしけりゃ、仕様示せ