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

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

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

**デフォルトの名無しさん** · 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
不変のものをカプセル化する意味あるのか？
フルオープンでよくね？

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

>>355
不変だからこそカプセル化するんだよ

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

不変というのはコンパイル時に決まるってわけじゃないからな。
初期状態から変わらないってだけで、
初期状態というものは存在する。
当然それを隠したい場合も存在する。

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

>>354
そうか？俺は元々Lisperだし、全く面倒とは思わん
でももし面倒と思うんなら、特にC++とかならオーバーロードがあるんだから構造体名入れなくてもなんとかなるでしょ
この先UFCSも導入される予定みたいだし

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

びっくりするくらい低レベルな会話しててわろた
ホリデープログラマーが語りだすとこうなる

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

>>356
どうして不変だからカプセル化するんだよ？

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

>>357
なぜ隠すのか？
なぜ？　どうして？

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

>>358
LisperにとってJavaのクラスはどう？

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

自分で考えてみな

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

>>362
個人的には作業効率が落ちる感じがして好きじゃない
でも低産階級労働者を縛る鎖としてはいいんじゃない？

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

>>363
説明できないのな、じゃあいいわ

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

>>364
バイアスがすごいな
Lisperはやっぱ屑だな

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

>>365
聞く耳持たないヤツに対して説明できるほど理解は深くないんでね
何度も同じことを繰り返しても仕方ない

**デフォルトの名無しさん** · 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
ほうほう
だったら仮にそのクラス自体に手を入れることになった場合は
隠蔽対象者ではないということでおｋ?