カプセル化は愚かな考え★3

**デフォルトの名無しさん** · 2020/09/17(木) 06:37:21.26

■危険性

かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。

大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。

ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)

**デフォルトの名無しさん** · 2020/09/17(木) 06:37:28.60

※前スレ
https://mevius.5ch.net/test/read.cgi/tech/1596010678/

**デフォルトの名無しさん** · 2020/09/17(木) 06:38:11.32

※前々スレ
カプセル化の有害性、オブジェクト指向は愚かな考え
https://mevius.5ch.net/test/read.cgi/tech/1592491656/

**デフォルトの名無しさん** · 2020/09/17(木) 06:38:36.19

■仕様変更
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。

オブジェクト指向云々ではない。

**デフォルトの名無しさん** · 2020/09/17(木) 06:55:37.46

クソスレ立てるな

**デフォルトの名無しさん** · 2020/09/17(木) 10:53:48.09

関数型OSは、日本が主導したいものですな。

**デフォルトの名無しさん** · 2020/09/17(木) 11:15:42.88

主導以前にそんなOSはどこの国からも実用化されません。
今のところ私の予言は的中しています。

**デフォルトの名無しさん** · 2020/09/18(金) 13:38:30.43

BSD系は基本的にそんな感じでしょ。
>>1のカプセル化は机上では素晴らしいが実際には云々というのも元祖BSDの開発者たちだし。

**デフォルトの名無しさん** · 2020/09/18(金) 13:39:56.81

BSD系OSを積むiPhone
その主力であるobjective-cもswiftもカプセル化なんてないからね

**デフォルトの名無しさん** · 2020/09/18(金) 16:03:39.49

カプセル化という言葉を理解せずにカプセル化を語りたがるスレ主w

クソスレだがNGするのに役立ってる

**デフォルトの名無しさん** · 2020/09/19(土) 20:40:29.18

publicでいいからな

**デフォルトの名無しさん** · 2020/09/19(土) 20:41:28.06

関数型が流行ったのもカプセル化の問題点をなんとかしようとした結果だろうしね

**デフォルトの名無しさん** · 2020/09/19(土) 20:54:42.74

オブジェクト指向が間違って広まったのが悲劇の始まりだよね

**デフォルトの名無しさん** · 2020/09/19(土) 20:55:48.52

カプセル化の問題点をなんとかしようとした結果じゃなくて
「ある種の問題」ではコードをシンプルに書けるからなだけだよｗ

だから関数型を使うと言っても全体を関数型言語で書くわけじゃなくて
「ある種の問題」に限って部分的に取り入れてる

**デフォルトの名無しさん** · 2020/09/19(土) 20:56:03.13

見えない内部状態で関数の挙動が変わるとか
常識的に考えて頭おかしいからな

**デフォルトの名無しさん** · 2020/09/19(土) 20:57:12.54

ひとりで書いてる時は問題ないんだけどね。

**デフォルトの名無しさん** · 2020/09/19(土) 20:57:27.89

零細企業で書いてる時も問題ない

**デフォルトの名無しさん** · 2020/09/19(土) 20:58:40.17

ひとつのシステムに複数の会社が絡むときにヤバくなる。
「あの会社が作った」と手を出せない。

**デフォルトの名無しさん** · 2020/09/19(土) 20:59:20.05

状態は1個の構造体にまとめるべきだよね

**デフォルトの名無しさん** · 2020/09/20(日) 10:07:39.93

>>12
関数型言語は並列・並行処理を簡単に書けるってので、オブジェクト指向プログラミングでの並列・並行処理に限界を感じてたゲーム業界とかが注目してたね。
コアの数が増え続ければ今C++なのが関数型言語に置き換わるかもとかnvのおっさんが話してたのも今は懐かしい・・・。

当時は理論先行で思ったより簡単じゃ無かったんだけど、ライブラリも整備されて理論に実態が追い付いてきたんだけど、もう注目されないかも？
見限られるのが早過ぎたんや・・・。

**デフォルトの名無しさん** · 2020/09/21(月) 09:34:25.96

nodejsみたいな関数型は理解に苦しむ人が多かったけど、
pythonの大流行で「カプセル化禁止のオブジェクト指向」が一般人にも広まった。

**デフォルトの名無しさん** · 2020/09/21(月) 10:36:14.65

カプセル化禁止のオブジェクト指向は
Python以外のどこで使われてるというの？

**デフォルトの名無しさん** · 2020/09/21(月) 10:39:59.83

pythonの大流行で「カプセル化の代わりにネームマングリングを使うオブジェクト指向」が一般人にも広まった。
と言うべきでは？

https://qiita.com/mounntainn/items/e3fb1a5757c9cf7ded63

> pythonにはprivate変数はありません。
> しかしprivate変数に近いことは実現できます。

> PEP8上のコーディング規約としては
> 「_」1つのprefixをclass内のみで利用する変数とされています。
> しかし、この変数はインスタンス化したオブジェクトからのアクセス時には
> 物理的な機構はなくカプセル化としての役目は果たせません。

_を付ける方法はカプセル化にはならない

> 「__」2つのprefixをつけた場合、
> ネームマングリング機構が働きます。
> 該当の変数名は「_class名」のprefixがついた変数名へと置換されます。

__をつけるとネームマングリングによって変数名が変わるので
よりよい擬似的なカプセル化の方法になる

**デフォルトの名無しさん** · 2020/09/21(月) 10:59:25.78

>カプセル化禁止

そもそもメンバーの可視性制御ができなきゃカプセル化してないというわけでもないと思うが。

**デフォルトの名無しさん** · 2020/09/21(月) 13:24:59.53

>>22
objective-cだろ
昔はiPhoneアプリ開発で利用強制されたから否応なしにその世界に足を突っ込んだやつは多い

**デフォルトの名無しさん** · 2020/09/21(月) 14:06:16.49

オブジェクト指向における「カプセル化」は情報隠蔽のことじゃないんだよ

データとそれを扱うメソッドをオブジェクトという単位にまとめることがカプセル化

前者の意味で使ってるとしても可視性の制御は必須ではない

**デフォルトの名無しさん** · 2020/09/21(月) 14:08:03.22

Pythonのオブジェクト指向言語機能はショボいので本格的にOOやるやつは少数派

Objective-Cは可視性の制御可能
Cでもできるけどね

**デフォルトの名無しさん** · 2020/09/21(月) 16:30:05.44

カプセル化はPythonのようにネームマングリングを使う方法がオブジェクト指向として一般的！

**デフォルトの名無しさん** · 2020/09/21(月) 16:52:34.51

Java Silver, Goldの試験問題の答えがカプセル化とは、フィールドをprivateにすることだった。

だから、時々、ややこしい議論が生じる。

毎回意味不明なテンプレでスレが建つけど、>>1の言うカプセル化が何を意味しているのか誰も知らない。>>1も知らない。

つまりクソスレ

**デフォルトの名無しさん** · 2020/09/21(月) 16:53:08.49

>>26
privateは何のためにあるの？

**デフォルトの名無しさん** · 2020/09/21(月) 16:53:56.49

>>30
ネームマングリングがあるPythonでは不要
publicのまま名前を変更するから呼び出しにくくなる！

**デフォルトの名無しさん** · 2020/09/21(月) 16:54:44.02

>>29
「カプセル化とはprivateではない」と書いてある教科書みたことないぞ。
ソース出せよ。

**デフォルトの名無しさん** · 2020/09/21(月) 16:56:00.38

>>32
前スレみれば。俺に言うな。

**デフォルトの名無しさん** · 2020/09/21(月) 16:57:19.25

>>29
Java Gold SE7対策問題 ? 問7
https://tech.pjin.jp/blog/2015/10/31/java-gold-se7%e5%af%be%e7%ad%96%e5%95%8f%e9%a1%8c-%e5%95%8f7/

Javaにおけるカプセル化について間違っているものを選んでください。
1. カプセル化とは、属性と操作を一体化させることである。
2. カプセル化されたクラスでは、インスタンス変数に対してむやみにアクセスされることを防ぐためにアクセス修飾子を「private」にすることが多い
3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
5. カプセル化を行うことで各オブジェクトの結びつきが弱くなり、プログラムの再利用性が高くなる
6. カプセル化を行うことで個々のオブジェクトの独立性が高まり、オブジェクト内部の変更が外部に影響しにくくなる。
7. カプセル化を行うことでソフトウェアの保守性や開発効率が高まり、プログラムの部分的な再利用も安易になる。

正解は「(5)」となります。

(5)以外の説明はカプセル化の説明としてどれも正しいものになります。特に抑えておいていただきたい選択肢は以下の2つでしょうか。

**デフォルトの名無しさん** · 2020/09/21(月) 16:57:48.73

世間でカプセル化と呼ばれてるものの99.9999%はprivateのことだな。
愚かなデファクトスタンダード

**デフォルトの名無しさん** · 2020/09/21(月) 16:59:45.88

https://qiita.com/tamekaji/items/6c19e3d05621741ee929

参考：「徹底攻略 Java SE 11 Silver 問題集」から引用：

カプセル化は、ソフトウェアを分割する際に、関係するデータと
そのデータを必要する処理を1つにまとめ、無関係なものや関係性の低いものを
クラスから排除することで「何のためのクラスなのか？」というクラスの目的を
明確化するために行い、ほかのクラスに重複するデータや処理がない状態を目指すものです。

**デフォルトの名無しさん** · 2020/09/21(月) 16:59:56.56

でも、privateが無い言語でもカプセル化ってあるけど？とかいう主張をしている人がいて衝突していた気がする。

**デフォルトの名無しさん** · 2020/09/21(月) 17:01:18.08

>>37
Pythonではprivateの代わりにネームマングリングを使います！

**デフォルトの名無しさん** · 2020/09/21(月) 17:01:59.62

>>37
衝突も何も「教科書」にはカプセル化はprivateにすることなんて書いてない
オブジェクト指向理解した気になってるなんちゃってが言ってるだけ

**デフォルトの名無しさん** · 2020/09/21(月) 17:04:39.17

逆に必要なものを「publicにすること」と書いてあるなｗ
同じ意味のように見えて同じではない。
なぜなら全て必要なら全てpublicにしても「publicにすること」という
条件を守っているからカプセル化の定義とは矛盾しない

http://e-words.jp/w/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96.html

カプセル化とは、オブジェクト指向プログラミングにおいて、互いに関連するデータの集合と
それらに対する操作をオブジェクトとして一つの単位にまとめ、
外部に対して必要な情報や手続きのみを提供すること。
外から直に参照や操作をする必要のない内部の状態や構造は秘匿される。

**デフォルトの名無しさん** · 2020/09/21(月) 17:04:54.88

>>32

> >>29
> 「カプセル化とはprivateではない」と書いてある教科書みたことないぞ。

もしかして、じゃなくて、「カプセル化とはprivateにすることである」のソースを求めてる？

だいぶ前に試験を受けたときの記憶だから...ちょっと教科書探すよ。

**デフォルトの名無しさん** · 2020/09/21(月) 17:06:58.85

>>39
capsuleでもprivateでもなくuntouchableじゃん？
そもそもpublicなら「遮蔽」にならんじゃん？

**デフォルトの名無しさん** · 2020/09/21(月) 17:08:09.08

>>42
> そもそもpublicなら「遮蔽」にならんじゃん？

カプセル化はprivateにすることではない
カプセル化は（必要なものを）publicにすることだ

必要ないものをどうするかなんて決まっていない

**デフォルトの名無しさん** · 2020/09/21(月) 17:08:59.13

> カプセル化されたクラスでは、 … アクセス修飾子を「private」にすることが多い

前スレの人ってのは、これを　カプセル化＝アクセス修飾子を「private」にすること　と解釈したんだろうか？

**デフォルトの名無しさん** · 2020/09/21(月) 17:09:40.98

「触るな危険」と「隠された真実」はかなり違うだろ。

**デフォルトの名無しさん** · 2020/09/21(月) 17:10:21.60

カプセル化において、必要ないものを
publicにしてコメントで内部用と書こうが、_プリフィックスをつけようが
Pythonのようにネームマングリングで呼び出しにくくしようが
どれでもいいのだ

必要なものをpublicにする。
必要ないものはどうでもいい。

**デフォルトの名無しさん** · 2020/09/21(月) 17:11:53.07

>>45
プログラミングにおいては「触るな危険」でも「隠された真実」でもなくて
「内部実装」（だから仕様は固定されておらず予告なく変更することがあります。）という程度の意味だな

**デフォルトの名無しさん** · 2020/09/21(月) 17:13:56.04

>>47
privateは「隠された真実」だろ。

**デフォルトの名無しさん** · 2020/09/21(月) 17:16:21.58

>>48
真実ってなんですか？
publicだと隠されてない真実なんですか？
プログラミングに置いて真実ってどういう意味ですか？

**デフォルトの名無しさん** · 2020/09/21(月) 17:22:09.73

>>49
不都合な真実
publicにできたらノーベル賞級の偉業だぞ

**デフォルトの名無しさん** · 2020/09/21(月) 17:22:50.39

>>49
そりゃ鮫島事件だろ

**デフォルトの名無しさん** · 2020/09/21(月) 17:23:13.30

>>49
プチエンジェル事件

**デフォルトの名無しさん** · 2020/09/21(月) 17:23:47.73

>>50
たとえで言うんじゃなくて、プログラミング用語で言ってくださいという意味です。
プログラミングで「真実」なんて言葉は使いません。

**デフォルトの名無しさん** · 2020/09/21(月) 17:32:42.55

うーん、だめだ...見つからん。
記憶ソースですまん。
でも、黒本じゃない本（黒本と同じ会社が出版）の問題にもあったのは覚えている。

カプセル化の選択肢はこれでいいの？って感じたのは覚えているんだよ,,,。他の選択肢がありえないものだったから、消去法で一択だったけど。

まぁ、Oracle Javaにおけるカプセル化はフィールドをprivateにしてメソッドをpublicにすることなんだなって無理矢理納得したけど。

**デフォルトの名無しさん** · 2020/09/21(月) 17:33:56.90

カプセル化を考えるとき
隠す隠さないという発想に出るのは
あくまで実装ありきの考えだから

先にインタフェースを考え
再利用性や直交性のために先にデザインされ
あとからそれに実装を与えるのがカプセル化

publicにするものはそれがインタフェースだから
publicにしないものはそれが実装だから

**デフォルトの名無しさん** · 2020/09/21(月) 17:34:41.41

>>54
お前の記憶のものは見つからなくても、

「カプセル化とは」の質問と答えは書いてあるやろ？
それ書けばいいんやで？

Oracle Javaにおいてカプセル化は
なんて言ってるか書いてみ

**デフォルトの名無しさん** · 2020/09/21(月) 17:43:28.75

黒本から抜粋すると、
オブジェクト指向におけるカプセル化の特徴

・データがオブジェクト外に漏れることを防止できる
・オブジェクト内で保持する不変な値を保護できる
・クラスの実装を変更する際、呼び出し側への影響を軽減できる

というのはあるな。
まぁ、そりゃそうだわな。

**デフォルトの名無しさん** · 2020/09/21(月) 17:49:42.33

すまん、黒本じゃなかった。同じ会社の出している試験問題アプリの回答内容だったわ。

ていうか、いい加減に1のテンプレ変えようぜ。
定期的にこのスレくるけど、1の言うカプセル化の意味が本気でわからん。

**デフォルトの名無しさん** · 2020/09/21(月) 17:54:04.06

>>29
なるほどね
オブジェクト指向に対して執拗に文句いってる人は
だいだいJavaの人なので納得

>>34
めちゃくちゃな問題だね
こんなの勉強して”正解”を覚えちゃうから
自分で考えなくなるんだろうね

**デフォルトの名無しさん** · 2020/09/21(月) 18:16:13.76

> めちゃくちゃな問題だね
> こんなの勉強して”正解”を覚えちゃうから
> 自分で考えなくなるんだろうね

↑理由が一切書いてないことに注目（笑）
こういうの多いね。難癖だけ付ける人。

**デフォルトの名無しさん** · 2020/09/21(月) 18:26:45.54

>>59
Java Goldをとる人がオブジェクト指向に文句を言うことは無いと思う。
基本的に試験内容自体はJavaの実務経験(他言語の実務経験では無理)がないと解けない問題が多い。私が例（記憶）として挙げたのが珍例なだけで...。

何でもかんでもsetter,getterメソッドを用意して貧血ドメインなプログラムを平気で書くプログラマーは多いかもしれんが(根拠のない偏見)、少なくともJava Gold持つ奴がそんなクソコードを書くことはないと思う。思いたい。　

**デフォルトの名無しさん** · 2020/09/21(月) 19:16:33.69

書くプログラムによるけどな。
データマイニングツール実装するならほぼフルアクセス必要なレコードが絶対に必要になる。
なぜならそれがドメインが求める機能だから。

**デフォルトの名無しさん** · 2020/09/21(月) 19:16:56.12

>>61
どんなに優秀な人間でも未来予測はできない。

**デフォルトの名無しさん** · 2020/09/21(月) 19:42:08.62

HSPのモジュールだと全てprivateになる

http://www.onionsoft.net/hsp/v35/doclib/module.htm

**デフォルトの名無しさん** · 2020/09/21(月) 21:29:26.18

HSPってオワコンじゃね？

**デフォルトの名無しさん** · 2020/09/21(月) 21:40:09.54

>>61
その珍問はさておいて
じゃあJava Goldを取るような人は
カプセル化とな何か、どう定義しているの？

**デフォルトの名無しさん** · 2020/09/22(火) 02:25:08.88

はっきりした定義は無い

**デフォルトの名無しさん** · 2020/09/22(火) 03:13:46.62

> じゃあJava Goldを取るような人は
> カプセル化とな何か、どう定義しているの？

Java Goldを取る人が定義するのか？
Java Goldを取るような人はどういう定義をカプセル化と思ってるかだろ？

答えは>>34に書いてあるな。間違いを除いた以下がカプセル化の定義としてよく知られている。

1. カプセル化とは、属性と操作を一体化させることである。
2. カプセル化されたクラスでは、インスタンス変数に対してむやみにアクセスされることを防ぐためにアクセス修飾子を「private」にすることが多い
3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
6. カプセル化を行うことで個々のオブジェクトの独立性が高まり、オブジェクト内部の変更が外部に影響しにくくなる。
7. カプセル化を行うことでソフトウェアの保守性や開発効率が高まり、プログラムの部分的な再利用も安易になる。

**デフォルトの名無しさん** · 2020/09/22(火) 03:16:09.36

ところでPythonやってる人は、カプセル化はprivateではない
ネームマングリング（__プリフィックスつけたメソッド名を内部名へ変更すること）のことだ
って思ってるのか？

**デフォルトの名無しさん** · 2020/09/22(火) 03:17:30.33

>>68
1,5,6は蛇足。
2,3,4は多いってｗw
そしたら少ない場合は、何なのよ

**デフォルトの名無しさん** · 2020/09/22(火) 03:18:47.21

Java Goldってこの程度なのか…

**デフォルトの名無しさん** · 2020/09/22(火) 03:29:13.61

>>70
> 1,5,6は蛇足。

蛇足である理由は？
そして蛇足であっても書いてあることは正しいよね

> 2,3,4は多いってｗw
全てじゃないんだから多いという言い方をするしか無い
全てって言ってほしいんだろ？
そしてお前が「全てなわけがない！」って言いたいんだろ？ｗ
先手取られたから、何も言えないね

**デフォルトの名無しさん** · 2020/09/22(火) 03:30:09.90

>>71
この程度かどうかは論点じゃないよね

カプセル化の定義として正しいかどうかだよね
論点のすり替えは見逃さないよｗ

**デフォルトの名無しさん** · 2020/09/22(火) 03:41:57.34

なにがカプセル化か人によって言うことが違う
基準が無いのに合っているって

**デフォルトの名無しさん** · 2020/09/22(火) 03:43:22.12

Java Goldってこの程度なの？

**デフォルトの名無しさん** · 2020/09/22(火) 03:43:31.65

じゃあ変なことを言ってるやつが間違ってるだけだろｗ
Java Goldの定義が正しい
だからJavaやってる人はカプセル化の定義を知ってる

知らんやつがオレオレ定義で喚いているだけ

**デフォルトの名無しさん** · 2020/09/22(火) 03:44:24.25

Javaってその程度のものだったの？

**デフォルトの名無しさん** · 2020/09/22(火) 03:45:41.47

>>76
> だからJavaやってる人はカプセル化の定義を知ってる

だそうだ、皆さんどう思う？

**デフォルトの名無しさん** · 2020/09/22(火) 03:50:12.39

>2. カプセル化されたクラスでは、インスタンス変数に対してむやみにアクセスされることを防ぐためにアクセス修飾子を「private」にすることが多い
>3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
>4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い

なぜか5がないがそれは見なかったことにして…

カプセル化ってこういうことだったの？
オブジェクト指向って…

**デフォルトの名無しさん** · 2020/09/22(火) 07:40:52.29

>>34が正しいんだとすればカプセル化の定義はこれ一択じゃん

>1. カプセル化とは、属性と操作を一体化させることである。

**デフォルトの名無しさん** · 2020/09/22(火) 09:03:20.04

Java Gold SE8の黒本1ページに書いてあったぞ

1. Javaにおけるカプセル化の実装に関する説明として正しいものを選びなさい。

a すべてのフィールドをprivate宣言する
b すべてのメソッドをprivate宣言する
c クラスをfinal宣言する
d クラスをstatic宣言する

Java Goldのボーナス問題だな。Bronze受けたこと無いけど、Bronzeでもあった気がする。

そして、記憶で語っているから勘違いしているかもしれないけど、わざわざJavaにおけるって書かれている。

時々、オブジェクト指向におけるカプセル化とJava(またはその他特定言語の)実装におけるカプセル化のルールを混在させる馬鹿がいる。
それも、1のテンプレがクソだから。

**デフォルトの名無しさん** · 2020/09/22(火) 09:34:53.81

そりゃこのスレは「Javaでのカプセル化は何かがおかしい」ってのが趣旨でしょ

**デフォルトの名無しさん** · 2020/09/22(火) 09:37:22.31

>>1
どういった具体例があるか考えてみた。

A社が例えばユーザーの個人情報を格納するPersonクラス(を含むパッケージ)を作ってバイナリのライブラリをB社に売った。

ageフィールドをpriveteにして、セッターのsetAgeではあり得ない年齢が入力されたら0才が返る様に作られていた。

A社が潰れた。

数年後、医療技術の進歩で当時ではあり得ない年齢があり得る年齢になったのでB社は改修しようとした。

setAgeではあり得ない年齢が入力されたら0才が返る仕様だと、実際に0才なのか、あり得ない年齢が入力された結果なのか判別出来ず、
結果としてPersonクラス部分全体を作り直した。

みたいな事が起こってるのかな？
それでも入力時の年齢を一時保管してゲッターと比較するとか、やりようはありそうだからもっと絶望的な具体例があった方が良いだろうけど。
こう言う例だけでもコスパ的にはprivateよりpublicにして、コード規約で縛る程度が良いんだろうけど。

とりま、どっちの陣営もこう言う場合にこう言う問題が起こり得る。みたいな具体例からの議論したら建設的では。

**デフォルトの名無しさん** · 2020/09/22(火) 09:52:40.57

>>83
カプセル化しても、ソースコードは別に編集できるぞ。
private、publicは関係ないと思うけど。

**デフォルトの名無しさん** · 2020/09/22(火) 10:42:17.09

>>84
そのモジュールを配布しているところと使っているところの開発が一緒ならな。
結局インターフェイスをどうするかって話になる。
で、それはセンスとしか言いようがないわけで変な技術論にこだわるからクソみたいな議論に繋がっている。
もう何度も行われた議論だ。

**デフォルトの名無しさん** · 2020/09/22(火) 10:47:01.51

>>84
だからわざわざバイナリって書いたのに・・・。
ソースが無い状態。dllとかの形でしか持ってない状態だよ。

**デフォルトの名無しさん** · 2020/09/22(火) 10:58:27.31

>>80
それな
他は「～が多い」という表現で定義について述べてるわけじゃないからな

tech.pjinとかいうサイトが考えた例題だから正しいかどうかもわかりゃしない
少なくとも5の主張は間違ってるのに6と7は正しいというのは矛盾してて意味不明

**デフォルトの名無しさん** · 2020/09/22(火) 11:34:32.81

Oracleの資料や試験範囲の「Apply encapsulation principles to a class」って項目を見ると
privateにしてgetter/setter用意するのがOracleの言う「カプセル化の原則」で
Javaな人はそれを「カプセル化の定義」だと思っちゃってるってことで間違いなさそうだね

[Java SE 8 Programming Student Guide]
• The term encapsulation means to enclose in a capsule, or to wrap something around an object to cover it.
• Encapsulation covers, or wraps, the internal workings of a Java object.
　– Data variables, or fields, are hidden from the user of the object.
　– Methods, the functions in Java, provide an explicit service to the user of the object but hide the implementation.
　– As long as the services do not change, the implementation can be modified without impacting the user.

↓この辺にもカプセル化の説明あるがそれぞれ言ってることが違う
https://docs.oracle.com/javase/tutorial/java/concepts/object.html
https://www.oracle.com/topics/technologies/newtojava/javaterminology-glossary.html

**デフォルトの名無しさん** · 2020/09/22(火) 11:37:56.47

>>79
> なぜか5がないがそれは見なかったことにして…

ちゃん>>34読んでるか？
「以下の問の中で間違ってるのはどれか？」・・・5が間違ってる
のだから無いのは当たり前だろ

**デフォルトの名無しさん** · 2020/09/22(火) 11:40:38.91

あまり原理主義に走らない方が

自然の摂理でもあるまいし
都合よく美味しい所を取って要領よく使えば良いのでは

**デフォルトの名無しさん** · 2020/09/22(火) 13:03:03.01

>>81
a-dから選べっていう選択問題だ

**デフォルトの名無しさん** · 2020/09/22(火) 13:54:00.38

世の中には俺様ルール押し付けたほうが楽できると思ってる輩がいるのよ。
実際は逆に本人、周り含めてみんな苦労するだけなんだが。

**デフォルトの名無しさん** · 2020/09/22(火) 15:10:51.64

俺は思うんだが全部public finalフィールドでいいじゃん

**デフォルトの名無しさん** · 2020/09/22(火) 16:30:45.03

>>83
バイナリ部分が壮大な作りだと大事件になる。
壮大だからこそライブラリ単品でも売れる。

**デフォルトの名無しさん** · 2020/09/22(火) 16:32:56.07

>>83
struts1のメンテナンス終了事件がまさにそれ。
オープンソースであったにも関わらず壮大すぎて中小零細は誰も独自フォーク、独自メンテナンスができなかった。

**デフォルトの名無しさん** · 2020/09/22(火) 16:43:24.11

自分達でソースをメンテナンスしない場合、カプセル化で詰むことが極々稀にあるってだけだろ
最初から開発を他社まかせにするなら、詰んだ時に別の会社の製品に乗り換えればいいだけ
カプセル化のデメリットとしては、あまりにも弱いな

**デフォルトの名無しさん** · 2020/09/22(火) 16:45:09.79

>>95
それ、べつにprivateじゃなくてpublicだったとしても状況は変わらなかったんじゃね？

**デフォルトの名無しさん** · 2020/09/22(火) 17:21:01.61

>>83
現実では「あり得ない年齢」や「0才を返す」という部分を
拡張不可能な形でハードコーディングしたりしないよね？

仮にあったとしてもそういうバイナリに依存したツケなので
仕様変更が必要なら自分で尻拭いするのは当然に感じる

**デフォルトの名無しさん** · 2020/09/22(火) 17:37:40.71

どんな思想だろうとバカが運用すれば失敗する
そうでなければそれなりにうまく行く

**デフォルトの名無しさん** · 2020/09/22(火) 18:28:55.51

>>98
分かり易い例として上げただけで、実際にこんな馬鹿は居ないと信じたい。

尻拭いも当然なんだけど、そしたらカプセル化反対派は「そら見ろ」ってなるよね。
どう対処すべきかを具体的に議論して行くのが建設的では無いかと。

例えば医療技術の進歩を見越してsetAgeMaxメソッドを用意しておくとか。

**デフォルトの名無しさん** · 2020/09/22(火) 18:45:44.82

んー、じゃあ、カプセル化を1ミリも否定しない俺から例題を出すけど

class parameter{
private int value;
public getValue(){
return this.value;
}
public setValue(int value){
this.value = value;
}
}

Javaのカプセル化の原則に従うと、わざわざフィールドを用意する度にこんなSetter、Getterを書くんだよね？
面倒くさくね？

という事例を考えてみた。
カプセル化を初めて学んだ時の俺の心の声だな。

...まぁ、上記コードに限っては面倒くさいだけでメリットが感じられないというのも間違いではない。

**デフォルトの名無しさん** · 2020/09/22(火) 18:55:06.72

>>101
SetGetは要らない
代わりにフィールドをパブリックかつ不変にしてコンストラクタでバリデーションしよう

JavaやC#でアクセサ(プロパティ)が必要な本当の理由は実は「メタプログラミングのための規約」でしかない
メタプログラミングなんてものは純粋なオブジェクト指向から言わせて貰えば邪道もいいとこ

**デフォルトの名無しさん** · 2020/09/22(火) 19:41:22.16

アクセサはメタプログラミングとは全く関係ないぞ
メタの意味わかってるか？

**デフォルトの名無しさん** · 2020/09/22(火) 19:55:58.36

関係あるぞ
メタプログラミングを応用したライブラリ、フレームワークの多くはプロパティを前提として実装されている
バインディング、マッパー、シリアライザ、コード生成、、、
我々は、これらを利用したいがために、あまりにも多くの無意味なプロパティを書いてきた
それが、本来なら全く必要がないものにも関わらず、メタプログラミングで使うから、というだけでだ

**デフォルトの名無しさん** · 2020/09/22(火) 19:59:10.63

> メタプログラミングを応用したライブラリ、フレームワークの多くはプロパティを前提として実装されている

いえ、
メタプログラミングを応用したライブラリ、フレームワークの多くは
パブリックメソッドやクラスをを前提として実装されています。
プログラミングにおけるあらゆるものを前提として実装されてるので
アクセサに限りません。

**デフォルトの名無しさん** · 2020/09/22(火) 20:14:26.78

>>105
その大部分を占めるのはプロパティ

**デフォルトの名無しさん** · 2020/09/22(火) 20:17:39.19

>>106
だから、プログラミングでは必ずとプロパティを使うだけだろ
メタプログラミングとは関係ない証拠

**デフォルトの名無しさん** · 2020/09/22(火) 20:18:50.22

普通は全く使わないものなのにメタプログラミングのときだけ使う
そういうものであれば「メタプログラミングのための規約」と言えるが、
普段から使ってるんだから、メタプログラミングとは全く関係ない

**デフォルトの名無しさん** · 2020/09/22(火) 21:39:00.76

だから普段は使わないんだよ
メタプログラミングに毒されてるから要らないのにプロパティにしてしまっている

**デフォルトの名無しさん** · 2020/09/22(火) 21:48:21.67

>>100
ソースを提供しない汎用的なライブラリとして作るなら
許容可能な年齢みたいなバリデーションルールは外部から読み込むようにして
許容範囲外なら例外を返すようにする

継承してクラスを拡張させる方向とかもあるが
継承の手間をかけるメリットがあるような例ではない気がする

現実のユーザーの個人情報を格納するクラスなら
年齢は生年月日で管理、コンストラクタ渡しでSetterは無し
生年月日の変更を許容するなら”生年月日変更リクエスト”を別途モデル化する

**デフォルトの名無しさん** · 2020/09/22(火) 21:50:50.28

だから、ラストの手紙を日本語で書いてしまってるからな
あの世界線の公用語は文字も日本語

**デフォルトの名無しさん** · 2020/09/22(火) 22:44:34.61

>>109
プロパティを使わないでどうやって属性にアクセスするっていうの？

**デフォルトの名無しさん** · 2020/09/22(火) 23:43:52.35

>>112
直接アクセスすればいい
なんの問題があるんだ

**デフォルトの名無しさん** · 2020/09/23(水) 07:01:43.37

>>110
全くその通りで、そこを新人がいきなり出来る？とか、会社的(A社)には
そう言うシステム改修の度にお金発生するので敢えてそうしないと言うこともあり得る。

その場合、関数型言語でも関数内変数にしちゃう輩が多いだろうけど・・・。

**デフォルトの名無しさん** · 2020/09/23(水) 08:00:16.06

>>113
それ、カプセル化をしないことで生じる問題をガン無視してるだけじゃん。

**デフォルトの名無しさん** · 2020/09/23(水) 09:18:51.25

>>113
プロパティの意味がわかってないのかｗ

プロパティっていうのは直接アクセスするのと同じ書き方で
名前（インターフェース）を変えることなく読み書き時に
任意の処理（設定値を制限するなど）を加えることができる仕組み

プロパティは実質直接アクセスするのと同じもの

なぜメタプログラミングのときだけ
任意の処理を加えるのか言ってみ

**デフォルトの名無しさん** · 2020/09/23(水) 12:54:30.27

>>116

それ、カプセル化をしないことで生じる問題をガン無視してるだけじゃん。

**デフォルトの名無しさん** · 2020/09/23(水) 13:01:47.82

>>117
カプセル化の話なんかしてません

プロパティはメタプログラミングに使うものだという
アホ間抜けがいるから、バカにしてやってるだけです

**デフォルトの名無しさん** · 2020/09/23(水) 13:06:47.61

>>118
は？

**デフォルトの名無しさん** · 2020/09/23(水) 13:09:56.03

ああ、メタプログラミングに使うものの部分の否定か。読み間違えたすまん

**115** · 2020/09/23(水) 13:16:38.01

>>117
あと、勝手に俺になりすますな紛らわしい。

**デフォルトの名無しさん** · 2020/09/23(水) 23:10:59.12

継承を重ねるうちに消えたデータ

**デフォルトの名無しさん** · 2020/09/24(木) 00:29:16.38

秘技「無限継承の術」

**デフォルトの名無しさん** · 2020/09/24(木) 11:38:58.35

正攻法ではMACアドレスを取得できないネットワーク関連のライブラリも多い。
カプセル化の弊害だ。

これ、オブジェクト指向は関係なんだけど、オブジェクト指向ではやりがちなこと。

**デフォルトの名無しさん** · 2020/09/24(木) 12:06:19.37

>>124
> 正攻法ではMACアドレスを取得できないネットワーク関連のライブラリも多い。
> カプセル化の弊害だ。

カプセル化をしないことで、MACアドレスを取得できるという
ネットワーク関連のライブラリを１つでいいから言ってください

カプセル化でMACアドレスが取得できなくなるのが
嘘か本当かはそれを見ないと判断できません。

**デフォルトの名無しさん** · 2020/09/24(木) 15:01:38.50

>>124
カプセル化の意味理解してる？
それ、カプセル化されたネットワーク系ライブラリからカプセル化を排除したところで、MACアドレスは取得できないと思うのだが。

まず、議論する前にカプセル化の意味からググれ。
さっきからプロパティやらメタプログラミングやら関係のない話を持ち出して何がいいたいのかわからん。

**デフォルトの名無しさん** · 2020/09/24(木) 15:06:54.07

いや、プロパティは関係あるのか？
メタプログラミングとか言ってる時点で俺の知らない用語と化していそうだが。

**デフォルトの名無しさん** · 2020/09/27(日) 07:06:20.94

カプセル化にも困ることはある
だからJavaではリフレクションがあるわけだしな
最初見たときはこんなの許していいのかとビックリしたが

**デフォルトの名無しさん** · 2020/09/28(月) 08:59:39.48

>>125
旧.NETは取れるよ。
新.NETはサポートOSが増えた代償で取れなくなった。

**デフォルトの名無しさん** · 2020/09/28(月) 09:00:16.85

>>126
IPが取れるならMACアドレスも取れるだろ。

**デフォルトの名無しさん** · 2020/09/28(月) 09:01:17.04

IPアドレスは取れるけどMACアドレスもリンクスピードも取れないというのは結構ある。

**デフォルトの名無しさん** · 2020/09/28(月) 10:05:50.15

>>129
.NET Coreでも普通に取れる
嘘はよくない

**デフォルトの名無しさん** · 2020/09/28(月) 20:58:52.42

>>132
PCLは取れない

**デフォルトの名無しさん** · 2020/09/29(火) 18:49:33.31

カプセル化を推し進めると最小公倍数になる。
出来ることが減り、速度は遅くなる。
Adobe FlashやJavaアプレットが死滅した理由がまさにこれ。

**デフォルトの名無しさん** · 2020/09/29(火) 18:50:25.33

2ボタンマウスと1ボタンマウスがあったら性能の悪い方に合わせるようになる

**デフォルトの名無しさん** · 2020/09/29(火) 18:58:24.66

カプセル化はオープンソースに反している。

**デフォルトの名無しさん** · 2020/10/02(金) 00:58:15.70

ttps://video.twimg.com/ext_tw_video/1305443176069521408/pu/vid/464x848/ePCfrEi3FGrcLmb0.mp4

**デフォルトの名無しさん** · 2020/10/02(金) 09:38:31.29

>>136
たしかに。
オープンソースが広まる前の概念だよね。
ライブラリを売るのに都合が良かった。

**デフォルトの名無しさん** · 2020/10/02(金) 09:54:49.20

> ライブラリを売るのに都合が良かった。
どう都合が良かったの？

**デフォルトの名無しさん** · 2020/10/02(金) 10:09:10.35

>>139
コピープロテクト

**デフォルトの名無しさん** · 2020/10/02(金) 10:18:16.18

>>140
それがカプセル化と何の関係が？
そういうバイナリを埋め込めばいいだけでしょ？？？

**デフォルトの名無しさん** · 2020/10/02(金) 12:44:52.35

>>141
それやったらカプセル化問題が発生した時にアウトじゃん

**デフォルトの名無しさん** · 2020/10/02(金) 12:51:14.12

カプセル化問題w

「たしかに」とか言いつつ同一人物でしょこれ

**デフォルトの名無しさん** · 2020/10/02(金) 13:21:58.26

本当に必要だったものはカプセル化ではなく変更のカプセル化
ようするにモナドだね

**デフォルトの名無しさん** · 2020/10/02(金) 13:30:25.34

>>142
だから何の関係があるの？って聞いてるんだが
コピープロテクトはカプセル化で作られてるとか？？？

**デフォルトの名無しさん** · 2020/10/02(金) 15:51:31.16

オープンソースなら「カプセル化の解除」ができるよね。
コピープロテクトも簡単に無効化される。

**デフォルトの名無しさん** · 2020/10/02(金) 17:15:25.27

>>146
オープンソースの暗号化ライブラリ使ったデータなら簡単に復号化できるよねw

オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できるし簡単になりすましできるよねw

「カプセル化の解除」の教えは万能だよねw

**デフォルトの名無しさん** · 2020/10/02(金) 18:54:48.52

>>146
オープンソースとカプセル化に何の意味が？
オープンソースなら、カプセル化しなくても
簡単に無効化できると思いますが？？？

**デフォルトの名無しさん** · 2020/10/02(金) 19:06:13.17

カプセル化が必要なのはドメインレイヤー
これは不正な状態を排除するため
ただしイミュータブルなら無理にカプセル化しなくていい

インフラストラクチャはインターフェース切るだけでいい
実装は丸出しにしてOK

**デフォルトの名無しさん** · 2020/10/02(金) 19:57:20.99

>>147
「プログラムを改変できる」と
「プログラムが出力したデータを改変できる」はまったくの別物だろ。

**デフォルトの名無しさん** · 2020/10/02(金) 19:59:33.39

>>148
どちらも「カプセル化されている」というスタート地点が同じだとする。

後に「カプセル化を解除したい」となったときの行動パターンはオープンソースと非オープンソースで大きく違う。

**デフォルトの名無しさん** · 2020/10/02(金) 20:31:44.10

>>151
それはオープンソースと非オープンソースの話であって
カプセル化は関係ないと言っています。

**デフォルトの名無しさん** · 2020/10/02(金) 20:32:06.20

オープンソースでもカプセル化は沢山使われていますよね

◆QZaw55cn4c · 2020/10/02(金) 20:33:36.32

>>147
＞オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できる
オープンソースだから、という理由だけでは、そういう結論は導出できない
鍵交換アルゴリズムが正しく実装されておれば、第三者は傍受できないことが、アルゴリズムの上で保証されている

**デフォルトの名無しさん** · 2020/10/02(金) 20:33:48.39

カプセル化したいときもオープンソースの方が簡単です！

**デフォルトの名無しさん** · 2020/10/02(金) 21:29:35.21

>>152
「カプセル化されているものを非カプセル化できる」というのはオープンソースだからこそでしょ？

**147** · 2020/10/02(金) 22:09:09.46

>>150,154
>>146に言ってあげてねw

**デフォルトの名無しさん** · 2020/10/02(金) 22:40:42.45

>>156
クローズドでもソースコードにアクセスできればできますが？

**デフォルトの名無しさん** · 2020/10/03(土) 00:08:13.37

>>158
アセンブラで？

**デフォルトの名無しさん** · 2020/10/03(土) 00:11:36.28

>>156
オープンソースで改変できるにしてもapache系のフレームワークみたいに巨大すぎてフォークしても後々のメンテナンス考えたら個人や零細企業では手に負えるレベルじゃない、というのはよくあるけどね。

**デフォルトの名無しさん** · 2020/10/03(土) 00:13:45.56

まあカプセル化否定派のnodejsとpythonが覇権を奪った時点で結論は出てるよね。

**デフォルトの名無しさん** · 2020/10/03(土) 00:15:27.57

>>159
コードサイニング証明書付きだと機械語レベルで改竄したら動かなくなるでしょ

**デフォルトの名無しさん** · 2020/10/03(土) 00:24:20.04

そりゃ野良コーダーでも自由に改変できるのがOSSの強みだからな
OSS指向のnodeやpythonは安全を捨てて自由を選んだわけだ
逆に業務システムとかじゃ末端に好き勝手させないためのカプセル化が有効

**デフォルトの名無しさん** · 2020/10/03(土) 01:37:37.73

PythonでもJSでもprivateな変数作れるの知らないんだね

さすゴミ

**デフォルトの名無しさん** · 2020/10/03(土) 05:42:18.97

>>159
ソースコードって言ってるのにバカなのか？

他人が作ったものを利用するなんてはそうしかないんだろうけどな
ソースコードっていうのはライセンスとは無関係に
開発者はソースコードにアクセスできるの

で今はカプセル化の話なんだろ？
ソースコードにアクセスできる人は普通に
カプセル化してるし、都合が悪ければ変更するだろ
だから何いってんだアホって言ってるわけ

**デフォルトの名無しさん** · 2020/10/03(土) 05:42:51.94

>>162
> コードサイニング証明書付きだと機械語レベルで改竄したら動かなくなるでしょ
ソースコード修正してから署名つければいいだけ。アーホ

**デフォルトの名無しさん** · 2020/10/03(土) 09:08:25.83

>>165-166
ソースコード非公開のライブラリの場合は？

**デフォルトの名無しさん** · 2020/10/03(土) 09:11:04.42

カプセル化のためにめちゃくちゃ長い関数作るみたいな馬鹿なことやらなければ、
あとは勝手にやってりゃいいと思うよ。

**デフォルトの名無しさん** · 2020/10/03(土) 13:18:20.54

>>164
どうやって作るの？

**デフォルトの名無しさん** · 2020/10/03(土) 13:57:26.98

>>167
ソースコード非公開ライブラリがどうかしたの？
カプセル化と何も関係ないよね

**デフォルトの名無しさん** · 2020/10/05(月) 13:02:03.02

保守性高いプログラム書ける人しかいないチームならありだけど、初心者が入るチームはだめだな
レビューで指摘、とかいうルールにしても、結局締め切りギリギリで出してきて今回は仕方ないねで終わりそう

**デフォルトの名無しさん** · 2020/10/05(月) 17:37:41.22

締め切りを半分にすればいいだけ。おまえが無能。

**デフォルトの名無しさん** · 2020/10/07(水) 17:40:54.83

カプセル化って名前が悪い。
ガラパゴス化にしよう。

**デフォルトの名無しさん** · 2020/10/07(水) 17:43:19.71

更新保護でいいよ
読み取りは好きにすればいい

**デフォルトの名無しさん** · 2020/10/07(水) 19:10:04.34

「だいじなところ」ぐらいではどうか?
許可がないと中身が見えない

**デフォルトの名無しさん** · 2020/10/08(木) 22:01:26.29

シングルトンパターン並に間違った使われ方をされてる機能

**デフォルトの名無しさん** · 2020/10/08(木) 22:04:39.32

必要だったのはprivateではなくread only

**デフォルトの名無しさん** · 2020/10/08(木) 22:17:15.27

ほんとそれ
immutable最強

**デフォルトの名無しさん** · 2020/10/08(木) 23:39:19.28

read onlyとprivateは直交した別の概念
ただ未だにread onlyすら簡単に実現できない言語は苦労するよね

**デフォルトの名無しさん** · 2020/10/09(金) 15:05:28.51

機械語にread onlyに出来る命令ってあるの？

**デフォルトの名無しさん** · 2020/10/10(土) 11:49:11.41

オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。

この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
https://blog.mah-lab.com/2014/03/18/object-oriented/

チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650

＜俺＞
「　部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。」
＜チンポ＞
「　その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。」

まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！

【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp

**デフォルトの名無しさん** · 2020/10/11(日) 18:41:11.36

>>180
なんで急に機械語？
命令っていうか、セグメントとか使ってできるアーキテクチャはあるけど

**デフォルトの名無しさん** · 2020/10/12(月) 08:35:37.96

>>180
だから苦労するじゃん。

**デフォルトの名無しさん** · 2020/10/12(月) 11:58:51.16

機械語で難しい事はどんなに取り繕っても難しい
プログラミング言語なんてただのラッパーだからね
結局は全部押し潰されて機械語になる

**デフォルトの名無しさん** · 2020/10/12(月) 12:12:14.34

>>184
>機械語で難しい事はどんなに取り繕っても難しい

ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

**デフォルトの名無しさん** · 2020/10/12(月) 12:23:26.11

胸は自らが動くからドキドキでよい
チンポをシコシコするのは右手（もしくは左手、足の場合もあるが詳細は省略）
つまり主語は（省略された）右手であってチンポは受け身の存在

要するにメッセージを送信するのは右手であって、受信したチンポはシコシコ指令を受けて
副作用としてドピュッシーを発生させる

シコシコはオブジェクト間メッセージなんだよ

もしこれが自分の右手じゃなくて彼女の足だったとする
足でもシコシコメッセージを送信することが出来る
これがオブジェクト指向の利点だ

彼女にシコシコされたチンポは右手にシコシコされた場合と同様にドピュッシーを発生させるんだ

夢精でドビュッシーするのはシコシコではなくムラムラ
違うメッセージでも同じ副作用を発生させるのが容易なのもオブジェクト指向的なんだ

**デフォルトの名無しさん** · 2020/10/12(月) 13:25:59.57

『シコシコ』という擬音はどうでもよい。問題は、

自我　　　　チンポ
↑　　　　　　↑　　　チンポ＝自我
チンポ　　　自我

オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。

https://i.imgur.com/4XhBmP3.jpg
https://i.imgur.com/PPFJZqI.jpg

夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。

『笑ってごまかすな！！』

と言われても、夏目くんは何と言えば良かったのだろう？

　　　　チンポ≫自我

『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！

チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。

博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。

**デフォルトの名無しさん** · 2020/10/12(月) 15:46:50.40

突然キチガイが湧いてきたな

**デフォルトの名無しさん** · 2020/10/12(月) 16:07:52.34

ちんぽがしこしこする？、そんな言語表現あるのか？

クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21

不適切な関係、そんな言語表現あるのか？

クリントン大統領はそのちんぽがしこしこしてしまった、それを『不適切な関係』って言うのか？

**デフォルトの名無しさん** · 2020/10/12(月) 16:15:20.27

928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは

チンポ.オシッコを出す
チンポ.オシッコを止める

さっきトイレでやってきた。

929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。

×
俺.オシッコを止める　俺.オシッコを出す
○
俺.チンポに力を入れる　俺.チンポから力を抜く

**デフォルトの名無しさん** · 2020/10/13(火) 09:41:20.48

785 名無し三等兵 sage 2019/12/03(火) 08:03:27.78 ID:sujZBpWD
>>762
＞「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

チンポにチンポ自身を扱く機能が備わっていないので自動詞は不適切だから（34文字）

胸（心臓）には鼓動する機能があるため自動詞の適用対象だが
チンポには勃起する機能はあっても自身を扱く機能はないので「チンポ『が』勃起する」は成立しても「チンポ『が』シコシコする」は成立しない
夢精した状況を「チンポ『が』シコシコした」と称したければ「チンポがエロい夢を見させ夢精した」＝「脳ではなくチンポが思考を司りエロい夢を見させて夢精させた」という状況で可となる

脳でなくチンポで物を考える生物についてなら「チンポ『が』シコシコする」は成り立つ
如何にもだつお的じゃないか

**デフォルトの名無しさん** · 2020/10/13(火) 15:22:42.55

チンポがシコシコ君は根本的に分かってないようだが
オブジェクトは主語ではなく、目的語。

SOVCのOはObjectのOダゾ

**デフォルトの名無しさん** · 2020/10/13(火) 19:16:29.57

>>192
オシッコを出すときのチンポは目的語だね。

**デフォルトの名無しさん** · 2020/10/13(火) 23:19:53.58

privateは手術不可能
どんなに医療が発展しても手術不可能

恐ろしいね

**デフォルトの名無しさん** · 2020/10/13(火) 23:21:03.97

privateは病変があるか検査すら不可能
恐ろしいね

**デフォルトの名無しさん** · 2020/10/13(火) 23:21:39.73

privateになったら最期

**デフォルトの名無しさん** · 2020/10/13(火) 23:22:12.65

private不治の病

**デフォルトの名無しさん** · 2020/10/13(火) 23:22:40.45

private病は恐ろしい

**デフォルトの名無しさん** · 2020/10/13(火) 23:23:37.94

privateは大腸癌より発見しにくい

**デフォルトの名無しさん** · 2020/10/14(水) 01:16:50.52

privateは全部公開