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

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

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

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

**デフォルトの名無しさん** · 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
ある
利用者は仕様書を確認することなく意図しない方法で利用する

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