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