引用元: ・カプセル化は愚かな考え★3
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。
大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
>>1のカプセル化は机上では素晴らしいが実際には云々というのも元祖BSDの開発者たちだし。
だから、時々、ややこしい議論が生じる。
毎回意味不明なテンプレでスレが建つけど、>>1の言うカプセル化が何を意味しているのか誰も知らない。>>1も知らない。
つまりクソスレ
「カプセル化とはprivateではない」と書いてある教科書みたことないぞ。
ソース出せよ。
前スレみれば。俺に言うな。
> >>29
> 「カプセル化とはprivateではない」と書いてある教科書みたことないぞ。
もしかして、じゃなくて、「カプセル化とはprivateにすることである」のソースを求めてる？
だいぶ前に試験を受けたときの記憶だから…ちょっと教科書探すよ。
Java Gold SE7対策問題 ? 問7
https://tech.pjin.jp/blog/2015/10/31/java-gold-se7%e5%af%be%e7%ad%e5%8f%e9%a1-%e5%8f7/
Javaにおけるカプセル化について間違っているものを選んでください。
1. カプセル化とは、属性と操作を一体化させることである。
2. カプセル化されたクラスでは、インスタンス変数に対してむやみにアクセスされることを防ぐためにアクセス修飾子を「private」にすることが多い
3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
5. カプセル化を行うことで各オブジェクトの結びつきが弱くなり、プログラムの再利用性が高くなる
6. カプセル化を行うことで個々のオブジェクトの独立性が高まり、オブジェクト内部の変更が外部に影響しにくくなる。
7. カプセル化を行うことでソフトウェアの保守性や開発効率が高まり、プログラムの部分的な再利用も安易になる。
正解は「(5)」となります。
(5)以外の説明はカプセル化の説明としてどれも正しいものになります。特に抑えておいていただきたい選択肢は以下の2つでしょうか。
なるほどね
オブジェクト指向に対して執拗に文句いってる人は
だいだいJavaの人なので納得
>>34
めちゃくちゃな問題だね
こんなの勉強して”正解”を覚えちゃうから
自分で考えなくなるんだろうね
Java Goldをとる人がオブジェクト指向に文句を言うことは無いと思う。
基本的に試験内容自体はJavaの実務経験(他言語の実務経験では無理)がないと解けない問題が多い。私が例（記憶）として挙げたのが珍例なだけで…。
何でもかんでもsetter,getterメソッドを用意して貧血ドメインなプログラムを平気で書くプログラマーは多いかもしれんが(根拠のない偏見)、少なくともJava Gold持つ奴がそんなクソコードを書くことはないと思う。思いたい。
どんなに優秀な人間でも未来予測はできない。
その珍問はさておいて
じゃあJava Goldを取るような人は
カプセル化とな何か、どう定義しているの？
> カプセル化とな何か、どう定義しているの？
Java Goldを取る人が定義するのか？
Java Goldを取るような人はどういう定義をカプセル化と思ってるかだろ？
答えは>>34に書いてあるな。間違いを除いた以下がカプセル化の定義としてよく知られている。
1. カプセル化とは、属性と操作を一体化させることである。
2. カプセル化されたクラスでは、インスタンス変数に対してむやみにアクセスされることを防ぐためにアクセス修飾子を「private」にすることが多い
3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
6. カプセル化を行うことで個々のオブジェクトの独立性が高まり、オブジェクト内部の変更が外部に影響しにくくなる。
7. カプセル化を行うことでソフトウェアの保守性や開発効率が高まり、プログラムの部分的な再利用も安易になる。
1,5,6は蛇足。
2,3,4は多いってｗw
そしたら少ない場合は、何なのよ
> 1,5,6は蛇足。
蛇足である理由は？
そして蛇足であっても書いてあることは正しいよね
> 2,3,4は多いってｗw
全てじゃないんだから多いという言い方をするしか無い
全てって言ってほしいんだろ？
そしてお前が「全てなわけがない！」って言いたいんだろ？ｗ
先手取られたから、何も言えないね
>>1. カプセル化とは、属性と操作を一体化させることである。
それな
他は「～が多い」という表現で定義について述べてるわけじゃないからな
tech.pjinとかいうサイトが考えた例題だから正しいかどうかもわかりゃしない
少なくとも5の主張は間違ってるのに6と7は正しいというのは矛盾してて意味不明
> なぜか5がないがそれは見なかったことにして…
ちゃん>>34読んでるか？
「以下の問の中で間違ってるのはどれか？」・・・5が間違ってる
のだから無いのは当たり前だろ
どういった具体例があるか考えてみた。
A社が例えばユーザーの個人情報を格納するPersonクラス(を含むパッケージ)を作ってバイナリのライブラリをB社に売った。
ageフィールドをpriveteにして、セッターのsetAgeではあり得ない年齢が入力されたら0才が返る様に作られていた。
A社が潰れた。
数年後、医療技術の進歩で当時ではあり得ない年齢があり得る年齢になったのでB社は改修しようとした。
setAgeではあり得ない年齢が入力されたら0才が返る仕様だと、実際に0才なのか、あり得ない年齢が入力された結果なのか判別出来ず、
結果としてPersonクラス部分全体を作り直した。
みたいな事が起こってるのかな？
それでも入力時の年齢を一時保管してゲッターと比較するとか、やりようはありそうだからもっと絶望的な具体例があった方が良いだろうけど。
こう言う例だけでもコスパ的にはprivateよりpublicにして、コード規約で縛る程度が良いんだろうけど。
とりま、どっちの陣営もこう言う場合にこう言う問題が起こり得る。みたいな具体例からの議論したら建設的では。
カプセル化しても、ソースコードは別に編集できるぞ。
private、publicは関係ないと思うけど。
そのモジュールを配布しているところと使っているところの開発が一緒ならな。
結局インターフェイスをどうするかって話になる。
で、それはセンスとしか言いようがないわけで変な技術論にこだわるからクソみたいな議論に繋がっている。
もう何度も行われた議論だ。
だからわざわざバイナリって書いたのに・・・。
ソースが無い状態。dllとかの形でしか持ってない状態だよ。
バイナリ部分が壮大な作りだと大事件になる。
壮大だからこそライブラリ単品でも売れる。
struts1のメンテナンス終了事件がまさにそれ。
オープンソースであったにも関わらず壮大すぎて中小零細は誰も独自フォーク、独自メンテナンスができなかった。
それ、べつにprivateじゃなくてpublicだったとしても状況は変わらなかったんじゃね？
現実では「あり得ない年齢」や「0才を返す」という部分を
拡張不可能な形でハードコーディングしたりしないよね？
仮にあったとしてもそういうバイナリに依存したツケなので
仕様変更が必要なら自分で尻拭いするのは当然に感じる
分かり易い例として上げただけで、実際にこんな馬鹿は居ないと信じたい。
尻拭いも当然なんだけど、そしたらカプセル化反対派は「そら見ろ」ってなるよね。
どう対処すべきかを具体的に議論して行くのが建設的では無いかと。
例えば医療技術の進歩を見越してsetAgeMaxメソッドを用意しておくとか。
ソースを提供しない汎用的なライブラリとして作るなら
許容可能な年齢みたいなバリデーションルールは外部から読み込むようにして
許容範囲外なら例外を返すようにする
継承してクラスを拡張させる方向とかもあるが
継承の手間をかけるメリットがあるような例ではない気がする
現実のユーザーの個人情報を格納するクラスなら
年齢は生年月日で管理、コンストラクタ渡しでSetterは無し
生年月日の変更を許容するなら”生年月日変更リクエスト”を別途モデル化する
全くその通りで、そこを新人がいきなり出来る？とか、会社的(A社)には
そう言うシステム改修の度にお金発生するので敢えてそうしないと言うこともあり得る。
その場合、関数型言語でも関数内変数にしちゃう輩が多いだろうけど・・・。
>>3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
>>4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
なぜか5がないがそれは見なかったことにして…
カプセル化ってこういうことだったの？
オブジェクト指向って…
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。
オブジェクト指向云々ではない。
今のところ私の予言は的中しています。
その主力であるobjective-cもswiftもカプセル化なんてないからね
クソスレだがNGするのに役立ってる
関数型言語は並列・並行処理を簡単に書けるってので、オブジェクト指向プログラミングでの並列・並行処理に限界を感じてたゲーム業界とかが注目してたね。
コアの数が増え続ければ今C++なのが関数型言語に置き換わるかもとかnvのおっさんが話してたのも今は懐かしい・・・。
当時は理論先行で思ったより簡単じゃ無かったんだけど、ライブラリも整備されて理論に実態が追い付いてきたんだけど、もう注目されないかも？
見限られるのが早過ぎたんや・・・。
「ある種の問題」ではコードをシンプルに書けるからなだけだよｗ
だから関数型を使うと言っても全体を関数型言語で書くわけじゃなくて
「ある種の問題」に限って部分的に取り入れてる
常識的に考えて頭おかしいからな
「あの会社が作った」と手を出せない。
pythonの大流行で「カプセル化禁止のオブジェクト指向」が一般人にも広まった。
Python以外のどこで使われてるというの？
objective-cだろ
昔はiPhoneアプリ開発で利用強制されたから否応なしにその世界に足を突っ込んだやつは多い
と言うべきでは？
https://qiita.com/mounntainn/items/e3fb1a5757c9cf7ded63
> pythonにはprivate変数はありません。
> しかしprivate変数に近いことは実現できます。
> PEP8上のコーディング規約としては
> 「_」1つのprefixをclass内のみで利用する変数とされています。
> しかし、この変数はインスタンス化したオブジェクトからのアクセス時には
> 物理的な機構はなくカプセル化としての役目は果たせません。
_を付ける方法はカプセル化にはならない
> 「__」2つのprefixをつけた場合、
> ネームマングリング機構が働きます。
> 該当の変数名は「_class名」のprefixがついた変数名へと置換されます。
__をつけるとネームマングリングによって変数名が変わるので
よりよい擬似的なカプセル化の方法になる
そもそもメンバーの可視性制御ができなきゃカプセル化してないというわけでもないと思うが。
データとそれを扱うメソッドをオブジェクトという単位にまとめることがカプセル化
前者の意味で使ってるとしても可視性の制御は必須ではない
privateは何のためにあるの？
ネームマングリングがあるPythonでは不要
publicのまま名前を変更するから呼び出しにくくなる！
Objective-Cは可視性の制御可能
Cでもできるけどね
愚かなデファクトスタンダード
参考： 「徹底攻略 Java SE 11 Silver 問題集」から引用：
カプセル化は、ソフトウェアを分割する際に、関係するデータと
そのデータを必要する処理を1つにまとめ、無関係なものや関係性の低いものを
クラスから排除することで「何のためのクラスなのか？」というクラスの目的を
明確化するために行い、ほかのクラスに重複するデータや処理がない状態を目指すものです。
Pythonではprivateの代わりにネームマングリングを使います！
衝突も何も「教科書」にはカプセル化はprivateにすることなんて書いてない
オブジェクト指向理解した気になってるなんちゃってが言ってるだけ
capsuleでもprivateでもなくuntouchableじゃん？
そもそもpublicなら「遮蔽」にならんじゃん？
> そもそもpublicなら「遮蔽」にならんじゃん？
カプセル化はprivateにすることではない
カプセル化は（必要なものを）publicにすることだ
必要ないものをどうするかなんて決まっていない
同じ意味のように見えて同じではない。
なぜなら全て必要なら全てpublicにしても「publicにすること」という
条件を守っているからカプセル化の定義とは矛盾しない
http://e-words.jp/w/%E3%AB%E3%97%E3%BB%E3%AB%E5%8C%96.html
カプセル化とは、オブジェクト指向プログラミングにおいて、互いに関連するデータの集合と
それらに対する操作をオブジェクトとして一つの単位にまとめ、
外部に対して必要な情報や手続きのみを提供すること。
外から直に参照や操作をする必要のない内部の状態や構造は秘匿される。
前スレの人ってのは、これを カプセル化＝アクセス修飾子を「private」にすること と解釈したんだろうか？
プログラミングにおいては「触るな危険」でも「隠された真実」でもなくて
「内部実装」（だから仕様は固定されておらず予告なく変更することがあります。）という程度の意味だな
privateは「隠された真実」だろ。
真実ってなんですか？
publicだと隠されてない真実なんですか？
プログラミングに置いて真実ってどういう意味ですか？
不都合な真実
publicにできたらノーベル賞級の偉業だぞ
たとえで言うんじゃなくて、プログラミング用語で言ってくださいという意味です。
プログラミングで「真実」なんて言葉は使いません。
そりゃ鮫島事件だろ
プチエンジェル事件
publicにしてコメントで内部用と書こうが、_プリフィックスをつけようが
Pythonのようにネームマングリングで呼び出しにくくしようが
どれでもいいのだ
必要なものをpublicにする。
必要ないものはどうでもいい。
記憶ソースですまん。
でも、黒本じゃない本（黒本と同じ会社が出版）の問題にもあったのは覚えている。
カプセル化の選択肢はこれでいいの？って感じたのは覚えているんだよ,,,。他の選択肢がありえないものだったから、消去法で一択だったけど。
まぁ、Oracle Javaにおけるカプセル化はフィールドをprivateにしてメソッドをpublicにすることなんだなって無理矢理納得したけど。
お前の記憶のものは見つからなくても、
「カプセル化とは」の質問と答えは書いてあるやろ？
それ書けばいいんやで？
Oracle Javaにおいてカプセル化は
なんて言ってるか書いてみ
隠す隠さないという発想に出るのは
あくまで実装ありきの考えだから
先にインタフェースを考え
再利用性や直交性のために先にデザインされ
あとからそれに実装を与えるのがカプセル化
publicにするものはそれがインタフェースだから
publicにしないものはそれが実装だから
オブジェクト指向におけるカプセル化の特徴
・データがオブジェクト外に漏れることを防止できる
・オブジェクト内で保持する不変な値を保護できる
・クラスの実装を変更する際、呼び出し側への影響を軽減できる
というのはあるな。
まぁ、そりゃそうだわな。
ていうか、いい加減に1のテンプレ変えようぜ。
定期的にこのスレくるけど、1の言うカプセル化の意味が本気でわからん。
> こんなの勉強して”正解”を覚えちゃうから
> 自分で考えなくなるんだろうね
↑理由が一切書いてないことに注目（笑）
こういうの多いね。難癖だけ付ける人。
データマイニングツール実装するならほぼフルアクセス必要なレコードが絶対に必要になる。
なぜならそれがドメインが求める機能だから。
ネームマングリング（__プリフィックスつけたメソッド名を内部名へ変更すること）のことだ
って思ってるのか？
この程度かどうかは論点じゃないよね
カプセル化の定義として正しいかどうかだよね
論点のすり替えは見逃さないよｗ
基準が無いのに合っているって
Java Goldの定義が正しい
だからJavaやってる人はカプセル化の定義を知ってる
知らんやつがオレオレ定義で喚いているだけ
> だからJavaやってる人はカプセル化の定義を知ってる
だそうだ、皆さんどう思う？
1. Javaにおけるカプセル化の実装に関する説明として正しいものを選びなさい。
a すべてのフィールドをprivate宣言する
b すべてのメソッドをprivate宣言する
c クラスをfinal宣言する
d クラスをstatic宣言する
Java Goldのボーナス問題だな。Bronze受けたこと無いけど、Bronzeでもあった気がする。
そして、記憶で語っているから勘違いしているかもしれないけど、わざわざJavaにおけるって書かれている。
時々、オブジェクト指向におけるカプセル化とJava(またはその他特定言語の)実装におけるカプセル化のルールを混在させる馬鹿がいる。
それも、1のテンプレがクソだから。
a-dから選べっていう選択問題だ
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
自然の摂理でもあるまいし
都合よく美味しい所を取って要領よく使えば良いのでは
実際は逆に本人、周り含めてみんな苦労するだけなんだが。
最初から開発を他社まかせにするなら、詰んだ時に別の会社の製品に乗り換えればいいだけ
カプセル化のデメリットとしては、あまりにも弱いな
そうでなければそれなりにうまく行く
class parameter{
private int value;
public getValue(){
return this.value;
}
public setValue(int value){
this.value = value;
}
}
Javaのカプセル化の原則に従うと、わざわざフィールドを用意する度にこんなSetter、Getterを書くんだよね？
面倒くさくね？
という事例を考えてみた。
カプセル化を初めて学んだ時の俺の心の声だな。
…まぁ、上記コードに限っては面倒くさいだけでメリットが感じられないというのも間違いではない。
SetGetは要らない
代わりにフィールドをパブリックかつ不変にしてコンストラクタでバリデーションしよう
JavaやC#でアクセサ(プロパティ)が必要な本当の理由は実は「メタプログラミングのための規約」でしかない
メタプログラミングなんてものは純粋なオブジェクト指向から言わせて貰えば邪道もいいとこ
メタの意味わかってるか？
メタプログラミングを応用したライブラリ、フレームワークの多くはプロパティを前提として実装されている
バインディング、マッパー、シリアライザ、コード生成、、、
我々は、これらを利用したいがために、あまりにも多くの無意味なプロパティを書いてきた
それが、本来なら全く必要がないものにも関わらず、メタプログラミングで使うから、というだけでだ
いえ、
メタプログラミングを応用したライブラリ、フレームワークの多くは
パブリックメソッドやクラスをを前提として実装されています。
プログラミングにおけるあらゆるものを前提として実装されてるので
アクセサに限りません。
その大部分を占めるのはプロパティ
だから、プログラミングでは必ずとプロパティを使うだけだろ
メタプログラミングとは関係ない証拠
そういうものであれば「メタプログラミングのための規約」と言えるが、
普段から使ってるんだから、メタプログラミングとは全く関係ない
メタプログラミングに毒されてるから要らないのにプロパティにしてしまっている
プロパティを使わないでどうやって属性にアクセスするっていうの？
直接アクセスすればいい
なんの問題があるんだ
それ、カプセル化をしないことで生じる問題をガン無視してるだけじゃん。
プロパティの意味がわかってないのかｗ
プロパティっていうのは直接アクセスするのと同じ書き方で
名前（インターフェース）を変えることなく読み書き時に
任意の処理（設定値を制限するなど）を加えることができる仕組み
プロパティは実質直接アクセスするのと同じもの
なぜメタプログラミングのときだけ
任意の処理を加えるのか言ってみ
それ、カプセル化をしないことで生じる問題をガン無視してるだけじゃん。
カプセル化の話なんかしてません
プロパティはメタプログラミングに使うものだという
アホ間抜けがいるから、バカにしてやってるだけです
は？
あと、勝手に俺になりすますな紛らわしい。
あの世界線の公用語は文字も日本語
カプセル化の弊害だ。
これ、オブジェクト指向は関係なんだけど、オブジェクト指向ではやりがちなこと。
> 正攻法ではMACアドレスを取得できないネットワーク関連のライブラリも多い。
> カプセル化の弊害だ。
カプセル化をしないことで、MACアドレスを取得できるという
ネットワーク関連のライブラリを１つでいいから言ってください
カプセル化でMACアドレスが取得できなくなるのが
嘘か本当かはそれを見ないと判断できません。
旧.NETは取れるよ。
新.NETはサポートOSが増えた代償で取れなくなった。
.NET Coreでも普通に取れる
嘘はよくない
PCLは取れない
カプセル化の意味理解してる？
それ、カプセル化されたネットワーク系ライブラリからカプセル化を排除したところで、MACアドレスは取得できないと思うのだが。
まず、議論する前にカプセル化の意味からググれ。
さっきからプロパティやらメタプログラミングやら関係のない話を持ち出して何がいいたいのかわからん。
IPが取れるならMACアドレスも取れるだろ。
メタプログラミングとか言ってる時点で俺の知らない用語と化していそうだが。
だからJavaではリフレクションがあるわけだしな
最初見たときはこんなの許していいのかとビックリしたが
出来ることが減り、速度は遅くなる。
Adobe FlashやJavaアプレットが死滅した理由がまさにこれ。
たしかに。
オープンソースが広まる前の概念だよね。
ライブラリを売るのに都合が良かった。
どう都合が良かったの？
コピープロテクト
それがカプセル化と何の関係が？
そういうバイナリを埋め込めばいいだけでしょ？？？
それやったらカプセル化問題が発生した時にアウトじゃん
だから何の関係があるの？って聞いてるんだが
コピープロテクトはカプセル化で作られてるとか？？？
「たしかに」とか言いつつ同一人物でしょこれ
ようするにモナドだね
オープンソースなら「カプセル化の解除」ができるよね。
コピープロテクトも簡単に無効化される。
オープンソースの暗号化ライブラリ使ったデータなら簡単に復号化できるよねw
オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できるし簡単になりすましできるよねw
「カプセル化の解除」の教えは万能だよねw
「プログラムを改変できる」と
「プログラムが出力したデータを改変できる」はまったくの別物だろ。
>>146に言ってあげてねw
＞オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できる
オープンソースだから、という理由だけでは、そういう結論は導出できない
鍵交換アルゴリズムが正しく実装されておれば、第三者は傍受できないことが、アルゴリズムの上で保証されている
オープンソースとカプセル化に何の意味が？
オープンソースなら、カプセル化しなくても
簡単に無効化できると思いますが？？？
どちらも「カプセル化されている」というスタート地点が同じだとする。
後に「カプセル化を解除したい」となったときの行動パターンはオープンソースと非オープンソースで大きく違う。
それはオープンソースと非オープンソースの話であって
カプセル化は関係ないと言っています。
「カプセル化されているものを非カプセル化できる」というのはオープンソースだからこそでしょ？
クローズドでもソースコードにアクセスできればできますが？
アセンブラで？
コードサイニング証明書付きだと機械語レベルで改竄したら動かなくなるでしょ
> コードサイニング証明書付きだと機械語レベルで改竄したら動かなくなるでしょ
ソースコード修正してから署名つければいいだけ。アーホ
ソースコードって言ってるのにバカなのか？
他人が作ったものを利用するなんてはそうしかないんだろうけどな
ソースコードっていうのはライセンスとは無関係に
開発者はソースコードにアクセスできるの
で今はカプセル化の話なんだろ？
ソースコードにアクセスできる人は普通に
カプセル化してるし、都合が悪ければ変更するだろ
だから何いってんだアホって言ってるわけ
オープンソースで改変できるにしてもapache系のフレームワークみたいに巨大すぎてフォークしても後々のメンテナンス考えたら個人や零細企業では手に負えるレベルじゃない、というのはよくあるけどね。
これは不正な状態を排除するため
ただしイミュータブルなら無理にカプセル化しなくていい
インフラストラクチャはインターフェース切るだけでいい
実装は丸出しにしてOK
OSS指向のnodeやpythonは安全を捨てて自由を選んだわけだ
逆に業務システムとかじゃ末端に好き勝手させないためのカプセル化が有効
さすゴミ
どうやって作るの？
ソースコード非公開のライブラリの場合は？
ソースコード非公開ライブラリがどうかしたの？
カプセル化と何も関係ないよね
あとは勝手にやってりゃいいと思うよ。
レビューで指摘、とかいうルールにしても、結局締め切りギリギリで出してきて今回は仕方ないねで終わりそう
ガラパゴス化にしよう。
読み取りは好きにすればいい
許可がないと中身が見えない
immutable最強
ただ未だにread onlyすら簡単に実現できない言語は苦労するよね
なんで急に機械語？
命令っていうか、セグメントとか使ってできるアーキテクチャはあるけど
だから苦労するじゃん。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
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
プログラミング言語なんてただのラッパーだからね
結局は全部押し潰されて機械語になる
>機械語で難しい事はどんなに取り繕っても難しい
ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
チンポをシコシコするのは右手（もしくは左手、足の場合もあるが詳細は省略）
つまり主語は（省略された）右手であってチンポは受け身の存在
要するにメッセージを送信するのは右手であって、受信したチンポはシコシコ指令を受けて
副作用としてドピュッシーを発生させる
シコシコはオブジェクト間メッセージなんだよ
もしこれが自分の右手じゃなくて彼女の足だったとする
足でもシコシコメッセージを送信することが出来る
これがオブジェクト指向の利点だ
彼女にシコシコされたチンポは右手にシコシコされた場合と同様にドピュッシーを発生させるんだ
夢精でドビュッシーするのはシコシコではなくムラムラ
違うメッセージでも同じ副作用を発生させるのが容易なのもオブジェクト指向的なんだ
自我 チンポ
↑ ↑ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/4XhBmP3.jpg
https://i.imgur.com/PPFJZqI.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
チンポ≫自我
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
クリントン大統領はそのちんぽがしこしこしてしまった、それを『不適切な関係』って言うのか？
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く
>>762
＞「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
チンポにチンポ自身を扱く機能が備わっていないので自動詞は不適切だから（34文字）
胸（心臓）には鼓動する機能があるため自動詞の適用対象だが
チンポには勃起する機能はあっても自身を扱く機能はないので「チンポ『が』勃起する」は成立しても「チンポ『が』シコシコする」は成立しない
夢精した状況を「チンポ『が』シコシコした」と称したければ「チンポがエロい夢を見させ夢精した」＝「脳ではなくチンポが思考を司りエロい夢を見させて夢精させた」という状況で可となる
脳でなくチンポで物を考える生物についてなら「チンポ『が』シコシコする」は成り立つ
如何にもだつお的じゃないか
オブジェクトは主語ではなく、目的語。
SOVCのOはObjectのOダゾ
オシッコを出すときのチンポは目的語だね。
どんなに医療が発展しても手術不可能
恐ろしいね
「新生物」とは良く言ったものだね。チンポは制御されるが新生物はされないから。
恐ろしいね
めでたしめでたし。
