■危険性
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性(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)
探検
カプセル化は愚かな考え★3
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2020/09/17(木) 06:37:21.26ID:rdOa/6ar2020/09/22(火) 03:29:13.61ID:Ab752W48
>>70
> 1,5,6は蛇足。
蛇足である理由は?
そして蛇足であっても書いてあることは正しいよね
> 2,3,4は多いってww
全てじゃないんだから多いという言い方をするしか無い
全てって言ってほしいんだろ?
そしてお前が「全てなわけがない!」って言いたいんだろ?w
先手取られたから、何も言えないね
> 1,5,6は蛇足。
蛇足である理由は?
そして蛇足であっても書いてあることは正しいよね
> 2,3,4は多いってww
全てじゃないんだから多いという言い方をするしか無い
全てって言ってほしいんだろ?
そしてお前が「全てなわけがない!」って言いたいんだろ?w
先手取られたから、何も言えないね
2020/09/22(火) 03:30:09.90ID:Ab752W48
2020/09/22(火) 03:41:57.34ID:jDcMk3G3
なにがカプセル化か人によって言うことが違う
基準が無いのに合っているって
基準が無いのに合っているって
2020/09/22(火) 03:43:22.12ID:jDcMk3G3
Java Goldってこの程度なの?
2020/09/22(火) 03:43:31.65ID:Ab752W48
じゃあ変なことを言ってるやつが間違ってるだけだろw
Java Goldの定義が正しい
だからJavaやってる人はカプセル化の定義を知ってる
知らんやつがオレオレ定義で喚いているだけ
Java Goldの定義が正しい
だからJavaやってる人はカプセル化の定義を知ってる
知らんやつがオレオレ定義で喚いているだけ
2020/09/22(火) 03:44:24.25ID:jDcMk3G3
Javaってその程度のものだったの?
2020/09/22(火) 03:45:41.47ID:jDcMk3G3
2020/09/22(火) 03:50:12.39ID:jDcMk3G3
>2. カプセル化されたクラスでは、インスタンス変数に対してむやみにアクセスされることを防ぐためにアクセス修飾子を「private」にすることが多い
>3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
>4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
なぜか5がないがそれは見なかったことにして…
カプセル化ってこういうことだったの?
オブジェクト指向って…
>3. カプセル化されたクラスでは、インスタンス変数の値を変更する手段としてメソッドが別途作成される事が多い
>4. カプセル化されたクラスでは、インスタンス変数を操作するためのメソッドはアクセス修飾子を「public」にすることが多い
なぜか5がないがそれは見なかったことにして…
カプセル化ってこういうことだったの?
オブジェクト指向って…
2020/09/22(火) 07:40:52.29ID:EwzeVKsQ
2020/09/22(火) 09:03:20.04ID:zPrOjjs3
Java Gold SE8の黒本1ページに書いてあったぞ
1. Javaにおけるカプセル化の実装に関する説明として正しいものを選びなさい。
a すべてのフィールドをprivate宣言する
b すべてのメソッドをprivate宣言する
c クラスをfinal宣言する
d クラスをstatic宣言する
Java Goldのボーナス問題だな。Bronze受けたこと無いけど、Bronzeでもあった気がする。
そして、記憶で語っているから勘違いしているかもしれないけど、わざわざJavaにおけるって書かれている。
時々、オブジェクト指向におけるカプセル化とJava(またはその他特定言語の)実装におけるカプセル化のルールを混在させる馬鹿がいる。
それも、1のテンプレがクソだから。
1. Javaにおけるカプセル化の実装に関する説明として正しいものを選びなさい。
a すべてのフィールドをprivate宣言する
b すべてのメソッドをprivate宣言する
c クラスをfinal宣言する
d クラスをstatic宣言する
Java Goldのボーナス問題だな。Bronze受けたこと無いけど、Bronzeでもあった気がする。
そして、記憶で語っているから勘違いしているかもしれないけど、わざわざJavaにおけるって書かれている。
時々、オブジェクト指向におけるカプセル化とJava(またはその他特定言語の)実装におけるカプセル化のルールを混在させる馬鹿がいる。
それも、1のテンプレがクソだから。
82デフォルトの名無しさん
2020/09/22(火) 09:34:53.81ID:+e+FbMSY そりゃこのスレは「Javaでのカプセル化は何かがおかしい」ってのが趣旨でしょ
83デフォルトの名無しさん
2020/09/22(火) 09:37:22.31ID:u7FipdQU >>1
どういった具体例があるか考えてみた。
A社が例えばユーザーの個人情報を格納するPersonクラス(を含むパッケージ)を作ってバイナリのライブラリをB社に売った。
ageフィールドをpriveteにして、セッターのsetAgeではあり得ない年齢が入力されたら0才が返る様に作られていた。
A社が潰れた。
数年後、医療技術の進歩で当時ではあり得ない年齢があり得る年齢になったのでB社は改修しようとした。
setAgeではあり得ない年齢が入力されたら0才が返る仕様だと、実際に0才なのか、あり得ない年齢が入力された結果なのか判別出来ず、
結果としてPersonクラス部分全体を作り直した。
みたいな事が起こってるのかな?
それでも入力時の年齢を一時保管してゲッターと比較するとか、やりようはありそうだからもっと絶望的な具体例があった方が良いだろうけど。
こう言う例だけでもコスパ的にはprivateよりpublicにして、コード規約で縛る程度が良いんだろうけど。
とりま、どっちの陣営もこう言う場合にこう言う問題が起こり得る。みたいな具体例からの議論したら建設的では。
どういった具体例があるか考えてみた。
A社が例えばユーザーの個人情報を格納するPersonクラス(を含むパッケージ)を作ってバイナリのライブラリをB社に売った。
ageフィールドをpriveteにして、セッターのsetAgeではあり得ない年齢が入力されたら0才が返る様に作られていた。
A社が潰れた。
数年後、医療技術の進歩で当時ではあり得ない年齢があり得る年齢になったのでB社は改修しようとした。
setAgeではあり得ない年齢が入力されたら0才が返る仕様だと、実際に0才なのか、あり得ない年齢が入力された結果なのか判別出来ず、
結果としてPersonクラス部分全体を作り直した。
みたいな事が起こってるのかな?
それでも入力時の年齢を一時保管してゲッターと比較するとか、やりようはありそうだからもっと絶望的な具体例があった方が良いだろうけど。
こう言う例だけでもコスパ的にはprivateよりpublicにして、コード規約で縛る程度が良いんだろうけど。
とりま、どっちの陣営もこう言う場合にこう言う問題が起こり得る。みたいな具体例からの議論したら建設的では。
2020/09/22(火) 09:52:40.57ID:zPrOjjs3
2020/09/22(火) 10:42:17.09ID:C50Ev79m
>>84
そのモジュールを配布しているところと使っているところの開発が一緒ならな。
結局インターフェイスをどうするかって話になる。
で、それはセンスとしか言いようがないわけで変な技術論にこだわるからクソみたいな議論に繋がっている。
もう何度も行われた議論だ。
そのモジュールを配布しているところと使っているところの開発が一緒ならな。
結局インターフェイスをどうするかって話になる。
で、それはセンスとしか言いようがないわけで変な技術論にこだわるからクソみたいな議論に繋がっている。
もう何度も行われた議論だ。
86デフォルトの名無しさん
2020/09/22(火) 10:47:01.51ID:u7FipdQU2020/09/22(火) 10:58:27.31ID:J3IrN4Ey
>>80
それな
他は「〜が多い」という表現で定義について述べてるわけじゃないからな
tech.pjinとかいうサイトが考えた例題だから正しいかどうかもわかりゃしない
少なくとも5の主張は間違ってるのに6と7は正しいというのは矛盾してて意味不明
それな
他は「〜が多い」という表現で定義について述べてるわけじゃないからな
tech.pjinとかいうサイトが考えた例題だから正しいかどうかもわかりゃしない
少なくとも5の主張は間違ってるのに6と7は正しいというのは矛盾してて意味不明
2020/09/22(火) 11:34:32.81ID:J3IrN4Ey
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
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.47ID:UY6+hZuP
2020/09/22(火) 11:40:38.91ID:bNTArSP2
あまり原理主義に走らない方が
自然の摂理でもあるまいし
都合よく美味しい所を取って要領よく使えば良いのでは
自然の摂理でもあるまいし
都合よく美味しい所を取って要領よく使えば良いのでは
2020/09/22(火) 13:03:03.01ID:GKTq/sAf
>>81
a-dから選べっていう選択問題だ
a-dから選べっていう選択問題だ
2020/09/22(火) 13:54:00.38ID:C50Ev79m
世の中には俺様ルール押し付けたほうが楽できると思ってる輩がいるのよ。
実際は逆に本人、周り含めてみんな苦労するだけなんだが。
実際は逆に本人、周り含めてみんな苦労するだけなんだが。
2020/09/22(火) 15:10:51.64ID:1XqBBY/l
俺は思うんだが全部public finalフィールドでいいじゃん
2020/09/22(火) 16:30:45.03ID:GZMXPtYq
2020/09/22(火) 16:32:56.07ID:GZMXPtYq
2020/09/22(火) 16:43:24.11ID:rSmj9iHf
自分達でソースをメンテナンスしない場合、カプセル化で詰むことが極々稀にあるってだけだろ
最初から開発を他社まかせにするなら、詰んだ時に別の会社の製品に乗り換えればいいだけ
カプセル化のデメリットとしては、あまりにも弱いな
最初から開発を他社まかせにするなら、詰んだ時に別の会社の製品に乗り換えればいいだけ
カプセル化のデメリットとしては、あまりにも弱いな
2020/09/22(火) 16:45:09.79ID:EwzeVKsQ
>>95
それ、べつにprivateじゃなくてpublicだったとしても状況は変わらなかったんじゃね?
それ、べつにprivateじゃなくてpublicだったとしても状況は変わらなかったんじゃね?
2020/09/22(火) 17:21:01.61ID:J3IrN4Ey
>>83
現実では「あり得ない年齢」や「0才を返す」という部分を
拡張不可能な形でハードコーディングしたりしないよね?
仮にあったとしてもそういうバイナリに依存したツケなので
仕様変更が必要なら自分で尻拭いするのは当然に感じる
現実では「あり得ない年齢」や「0才を返す」という部分を
拡張不可能な形でハードコーディングしたりしないよね?
仮にあったとしてもそういうバイナリに依存したツケなので
仕様変更が必要なら自分で尻拭いするのは当然に感じる
2020/09/22(火) 17:37:40.71ID:EwEFShMQ
どんな思想だろうとバカが運用すれば失敗する
そうでなければそれなりにうまく行く
そうでなければそれなりにうまく行く
100デフォルトの名無しさん
2020/09/22(火) 18:28:55.51ID:upDpA/6g >>98
分かり易い例として上げただけで、実際にこんな馬鹿は居ないと信じたい。
尻拭いも当然なんだけど、そしたらカプセル化反対派は「そら見ろ」ってなるよね。
どう対処すべきかを具体的に議論して行くのが建設的では無いかと。
例えば医療技術の進歩を見越してsetAgeMaxメソッドを用意しておくとか。
分かり易い例として上げただけで、実際にこんな馬鹿は居ないと信じたい。
尻拭いも当然なんだけど、そしたらカプセル化反対派は「そら見ろ」ってなるよね。
どう対処すべきかを具体的に議論して行くのが建設的では無いかと。
例えば医療技術の進歩を見越してsetAgeMaxメソッドを用意しておくとか。
101デフォルトの名無しさん
2020/09/22(火) 18:45:44.82ID:zPrOjjs3 んー、じゃあ、カプセル化を1ミリも否定しない俺から例題を出すけど
class parameter{
private int value;
public getValue(){
return this.value;
}
public setValue(int value){
this.value = value;
}
}
Javaのカプセル化の原則に従うと、わざわざフィールドを用意する度にこんなSetter、Getterを書くんだよね?
面倒くさくね?
という事例を考えてみた。
カプセル化を初めて学んだ時の俺の心の声だな。
...まぁ、上記コードに限っては面倒くさいだけでメリットが感じられないというのも間違いではない。
class parameter{
private int value;
public getValue(){
return this.value;
}
public setValue(int value){
this.value = value;
}
}
Javaのカプセル化の原則に従うと、わざわざフィールドを用意する度にこんなSetter、Getterを書くんだよね?
面倒くさくね?
という事例を考えてみた。
カプセル化を初めて学んだ時の俺の心の声だな。
...まぁ、上記コードに限っては面倒くさいだけでメリットが感じられないというのも間違いではない。
102デフォルトの名無しさん
2020/09/22(火) 18:55:06.72ID:1XqBBY/l >>101
SetGetは要らない
代わりにフィールドをパブリックかつ不変にしてコンストラクタでバリデーションしよう
JavaやC#でアクセサ(プロパティ)が必要な本当の理由は実は「メタプログラミングのための規約」でしかない
メタプログラミングなんてものは純粋なオブジェクト指向から言わせて貰えば邪道もいいとこ
SetGetは要らない
代わりにフィールドをパブリックかつ不変にしてコンストラクタでバリデーションしよう
JavaやC#でアクセサ(プロパティ)が必要な本当の理由は実は「メタプログラミングのための規約」でしかない
メタプログラミングなんてものは純粋なオブジェクト指向から言わせて貰えば邪道もいいとこ
103デフォルトの名無しさん
2020/09/22(火) 19:41:22.16ID:aoFeMTcw アクセサはメタプログラミングとは全く関係ないぞ
メタの意味わかってるか?
メタの意味わかってるか?
104デフォルトの名無しさん
2020/09/22(火) 19:55:58.36ID:1XqBBY/l 関係あるぞ
メタプログラミングを応用したライブラリ、フレームワークの多くはプロパティを前提として実装されている
バインディング、マッパー、シリアライザ、コード生成、、、
我々は、これらを利用したいがために、あまりにも多くの無意味なプロパティを書いてきた
それが、本来なら全く必要がないものにも関わらず、メタプログラミングで使うから、というだけでだ
メタプログラミングを応用したライブラリ、フレームワークの多くはプロパティを前提として実装されている
バインディング、マッパー、シリアライザ、コード生成、、、
我々は、これらを利用したいがために、あまりにも多くの無意味なプロパティを書いてきた
それが、本来なら全く必要がないものにも関わらず、メタプログラミングで使うから、というだけでだ
105デフォルトの名無しさん
2020/09/22(火) 19:59:10.63ID:aoFeMTcw > メタプログラミングを応用したライブラリ、フレームワークの多くはプロパティを前提として実装されている
いえ、
メタプログラミングを応用したライブラリ、フレームワークの多くは
パブリックメソッドやクラスをを前提として実装されています。
プログラミングにおけるあらゆるものを前提として実装されてるので
アクセサに限りません。
いえ、
メタプログラミングを応用したライブラリ、フレームワークの多くは
パブリックメソッドやクラスをを前提として実装されています。
プログラミングにおけるあらゆるものを前提として実装されてるので
アクセサに限りません。
106デフォルトの名無しさん
2020/09/22(火) 20:14:26.78ID:1XqBBY/l >>105
その大部分を占めるのはプロパティ
その大部分を占めるのはプロパティ
107デフォルトの名無しさん
2020/09/22(火) 20:17:39.19ID:aoFeMTcw108デフォルトの名無しさん
2020/09/22(火) 20:18:50.22ID:aoFeMTcw 普通は全く使わないものなのにメタプログラミングのときだけ使う
そういうものであれば「メタプログラミングのための規約」と言えるが、
普段から使ってるんだから、メタプログラミングとは全く関係ない
そういうものであれば「メタプログラミングのための規約」と言えるが、
普段から使ってるんだから、メタプログラミングとは全く関係ない
109デフォルトの名無しさん
2020/09/22(火) 21:39:00.76ID:+zcbGttj だから普段は使わないんだよ
メタプログラミングに毒されてるから要らないのにプロパティにしてしまっている
メタプログラミングに毒されてるから要らないのにプロパティにしてしまっている
110デフォルトの名無しさん
2020/09/22(火) 21:48:21.67ID:J3IrN4Ey >>100
ソースを提供しない汎用的なライブラリとして作るなら
許容可能な年齢みたいなバリデーションルールは外部から読み込むようにして
許容範囲外なら例外を返すようにする
継承してクラスを拡張させる方向とかもあるが
継承の手間をかけるメリットがあるような例ではない気がする
現実のユーザーの個人情報を格納するクラスなら
年齢は生年月日で管理、コンストラクタ渡しでSetterは無し
生年月日の変更を許容するなら”生年月日変更リクエスト”を別途モデル化する
ソースを提供しない汎用的なライブラリとして作るなら
許容可能な年齢みたいなバリデーションルールは外部から読み込むようにして
許容範囲外なら例外を返すようにする
継承してクラスを拡張させる方向とかもあるが
継承の手間をかけるメリットがあるような例ではない気がする
現実のユーザーの個人情報を格納するクラスなら
年齢は生年月日で管理、コンストラクタ渡しでSetterは無し
生年月日の変更を許容するなら”生年月日変更リクエスト”を別途モデル化する
111デフォルトの名無しさん
2020/09/22(火) 21:50:50.28ID:0j+aLKWi だから、ラストの手紙を日本語で書いてしまってるからな
あの世界線の公用語は文字も日本語
あの世界線の公用語は文字も日本語
112デフォルトの名無しさん
2020/09/22(火) 22:44:34.61ID:TWSwG1ae >>109
プロパティを使わないでどうやって属性にアクセスするっていうの?
プロパティを使わないでどうやって属性にアクセスするっていうの?
113デフォルトの名無しさん
2020/09/22(火) 23:43:52.35ID:1XqBBY/l114デフォルトの名無しさん
2020/09/23(水) 07:01:43.37ID:vyT7LDfs >>110
全くその通りで、そこを新人がいきなり出来る?とか、会社的(A社)には
そう言うシステム改修の度にお金発生するので敢えてそうしないと言うこともあり得る。
その場合、関数型言語でも関数内変数にしちゃう輩が多いだろうけど・・・。
全くその通りで、そこを新人がいきなり出来る?とか、会社的(A社)には
そう言うシステム改修の度にお金発生するので敢えてそうしないと言うこともあり得る。
その場合、関数型言語でも関数内変数にしちゃう輩が多いだろうけど・・・。
115デフォルトの名無しさん
2020/09/23(水) 08:00:16.06ID:uYoc74AZ >>113
それ、カプセル化をしないことで生じる問題をガン無視してるだけじゃん。
それ、カプセル化をしないことで生じる問題をガン無視してるだけじゃん。
116デフォルトの名無しさん
2020/09/23(水) 09:18:51.25ID:irsqaiS+ >>113
プロパティの意味がわかってないのかw
プロパティっていうのは直接アクセスするのと同じ書き方で
名前(インターフェース)を変えることなく読み書き時に
任意の処理(設定値を制限するなど)を加えることができる仕組み
プロパティは実質直接アクセスするのと同じもの
なぜメタプログラミングのときだけ
任意の処理を加えるのか言ってみ
プロパティの意味がわかってないのかw
プロパティっていうのは直接アクセスするのと同じ書き方で
名前(インターフェース)を変えることなく読み書き時に
任意の処理(設定値を制限するなど)を加えることができる仕組み
プロパティは実質直接アクセスするのと同じもの
なぜメタプログラミングのときだけ
任意の処理を加えるのか言ってみ
117デフォルトの名無しさん
2020/09/23(水) 12:54:30.27ID:S8l0aSve118デフォルトの名無しさん
2020/09/23(水) 13:01:47.82ID:/5+6arBn119デフォルトの名無しさん
2020/09/23(水) 13:06:47.61ID:EcLAlZaL >>118
は?
は?
120デフォルトの名無しさん
2020/09/23(水) 13:09:56.03ID:EcLAlZaL ああ、メタプログラミングに使うものの部分の否定か。読み間違えたすまん
122デフォルトの名無しさん
2020/09/23(水) 23:10:59.12ID:USOBG2da 継承を重ねるうちに消えたデータ
123デフォルトの名無しさん
2020/09/24(木) 00:29:16.38ID:zy8bWf+v 秘技「無限継承の術」
124デフォルトの名無しさん
2020/09/24(木) 11:38:58.35ID:q5yIFuI6 正攻法ではMACアドレスを取得できないネットワーク関連のライブラリも多い。
カプセル化の弊害だ。
これ、オブジェクト指向は関係なんだけど、オブジェクト指向ではやりがちなこと。
カプセル化の弊害だ。
これ、オブジェクト指向は関係なんだけど、オブジェクト指向ではやりがちなこと。
125デフォルトの名無しさん
2020/09/24(木) 12:06:19.37ID:27/WCIy4 >>124
> 正攻法ではMACアドレスを取得できないネットワーク関連のライブラリも多い。
> カプセル化の弊害だ。
カプセル化をしないことで、MACアドレスを取得できるという
ネットワーク関連のライブラリを1つでいいから言ってください
カプセル化でMACアドレスが取得できなくなるのが
嘘か本当かはそれを見ないと判断できません。
> 正攻法ではMACアドレスを取得できないネットワーク関連のライブラリも多い。
> カプセル化の弊害だ。
カプセル化をしないことで、MACアドレスを取得できるという
ネットワーク関連のライブラリを1つでいいから言ってください
カプセル化でMACアドレスが取得できなくなるのが
嘘か本当かはそれを見ないと判断できません。
126デフォルトの名無しさん
2020/09/24(木) 15:01:38.50ID:eJ60na0U >>124
カプセル化の意味理解してる?
それ、カプセル化されたネットワーク系ライブラリからカプセル化を排除したところで、MACアドレスは取得できないと思うのだが。
まず、議論する前にカプセル化の意味からググれ。
さっきからプロパティやらメタプログラミングやら関係のない話を持ち出して何がいいたいのかわからん。
カプセル化の意味理解してる?
それ、カプセル化されたネットワーク系ライブラリからカプセル化を排除したところで、MACアドレスは取得できないと思うのだが。
まず、議論する前にカプセル化の意味からググれ。
さっきからプロパティやらメタプログラミングやら関係のない話を持ち出して何がいいたいのかわからん。
127デフォルトの名無しさん
2020/09/24(木) 15:06:54.07ID:eJ60na0U いや、プロパティは関係あるのか?
メタプログラミングとか言ってる時点で俺の知らない用語と化していそうだが。
メタプログラミングとか言ってる時点で俺の知らない用語と化していそうだが。
128デフォルトの名無しさん
2020/09/27(日) 07:06:20.94ID:0lir37kZ カプセル化にも困ることはある
だからJavaではリフレクションがあるわけだしな
最初見たときはこんなの許していいのかとビックリしたが
だからJavaではリフレクションがあるわけだしな
最初見たときはこんなの許していいのかとビックリしたが
129デフォルトの名無しさん
2020/09/28(月) 08:59:39.48ID:y1yHDvjF130デフォルトの名無しさん
2020/09/28(月) 09:00:16.85ID:y1yHDvjF >>126
IPが取れるならMACアドレスも取れるだろ。
IPが取れるならMACアドレスも取れるだろ。
131デフォルトの名無しさん
2020/09/28(月) 09:01:17.04ID:y1yHDvjF IPアドレスは取れるけどMACアドレスもリンクスピードも取れないというのは結構ある。
132デフォルトの名無しさん
2020/09/28(月) 10:05:50.15ID:wlw0NrPw133デフォルトの名無しさん
2020/09/28(月) 20:58:52.42ID:9AJB64gi >>132
PCLは取れない
PCLは取れない
134デフォルトの名無しさん
2020/09/29(火) 18:49:33.31ID:vIDJmIPs カプセル化を推し進めると最小公倍数になる。
出来ることが減り、速度は遅くなる。
Adobe FlashやJavaアプレットが死滅した理由がまさにこれ。
出来ることが減り、速度は遅くなる。
Adobe FlashやJavaアプレットが死滅した理由がまさにこれ。
135デフォルトの名無しさん
2020/09/29(火) 18:50:25.33ID:vIDJmIPs 2ボタンマウスと1ボタンマウスがあったら性能の悪い方に合わせるようになる
136デフォルトの名無しさん
2020/09/29(火) 18:58:24.66ID:Q+HTeu6k カプセル化はオープンソースに反している。
137デフォルトの名無しさん
2020/10/02(金) 00:58:15.70ID:gd78HEzu ttps://video.twimg.com/ext_tw_video/1305443176069521408/pu/vid/464x848/ePCfrEi3FGrcLmb0.mp4
138デフォルトの名無しさん
2020/10/02(金) 09:38:31.29ID:pBqepwKm139デフォルトの名無しさん
2020/10/02(金) 09:54:49.20ID:b+gARvx0 > ライブラリを売るのに都合が良かった。
どう都合が良かったの?
どう都合が良かったの?
140デフォルトの名無しさん
2020/10/02(金) 10:09:10.35ID:pBqepwKm >>139
コピープロテクト
コピープロテクト
141デフォルトの名無しさん
2020/10/02(金) 10:18:16.18ID:qiKhE9Co142デフォルトの名無しさん
2020/10/02(金) 12:44:52.35ID:pBqepwKm >>141
それやったらカプセル化問題が発生した時にアウトじゃん
それやったらカプセル化問題が発生した時にアウトじゃん
143デフォルトの名無しさん
2020/10/02(金) 12:51:14.12ID:9M4QbSP5 カプセル化問題w
「たしかに」とか言いつつ同一人物でしょこれ
「たしかに」とか言いつつ同一人物でしょこれ
144デフォルトの名無しさん
2020/10/02(金) 13:21:58.26ID:r0Llx4GW 本当に必要だったものはカプセル化ではなく変更のカプセル化
ようするにモナドだね
ようするにモナドだね
145デフォルトの名無しさん
2020/10/02(金) 13:30:25.34ID:YFyV1pKj
オープンソースなら「カプセル化の解除」ができるよね。
コピープロテクトも簡単に無効化される。
147デフォルトの名無しさん
2020/10/02(金) 17:15:25.27ID:JvTfpms1 >>146
オープンソースの暗号化ライブラリ使ったデータなら簡単に復号化できるよねw
オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できるし簡単になりすましできるよねw
「カプセル化の解除」の教えは万能だよねw
オープンソースの暗号化ライブラリ使ったデータなら簡単に復号化できるよねw
オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できるし簡単になりすましできるよねw
「カプセル化の解除」の教えは万能だよねw
148デフォルトの名無しさん
2020/10/02(金) 18:54:48.52ID:r3ReT+S4149デフォルトの名無しさん
2020/10/02(金) 19:06:13.17ID:1uQRz/LD カプセル化が必要なのはドメインレイヤー
これは不正な状態を排除するため
ただしイミュータブルなら無理にカプセル化しなくていい
インフラストラクチャはインターフェース切るだけでいい
実装は丸出しにしてOK
これは不正な状態を排除するため
ただしイミュータブルなら無理にカプセル化しなくていい
インフラストラクチャはインターフェース切るだけでいい
実装は丸出しにしてOK
150デフォルトの名無しさん
2020/10/02(金) 19:57:20.99ID:Pm9ZUalc151デフォルトの名無しさん
2020/10/02(金) 19:59:33.39ID:Pm9ZUalc152デフォルトの名無しさん
2020/10/02(金) 20:31:44.10ID:r3ReT+S4153デフォルトの名無しさん
2020/10/02(金) 20:32:06.20ID:r3ReT+S4 オープンソースでもカプセル化は沢山使われていますよね
>>147
>オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できる
オープンソースだから、という理由だけでは、そういう結論は導出できない
鍵交換アルゴリズムが正しく実装されておれば、第三者は傍受できないことが、アルゴリズムの上で保証されている
>オープンソースのキー交換アルゴリズム使った通信は誰でも簡単に傍受できる
オープンソースだから、という理由だけでは、そういう結論は導出できない
鍵交換アルゴリズムが正しく実装されておれば、第三者は傍受できないことが、アルゴリズムの上で保証されている
155デフォルトの名無しさん
2020/10/02(金) 20:33:48.39ID:r3ReT+S4 カプセル化したいときもオープンソースの方が簡単です!
156デフォルトの名無しさん
2020/10/02(金) 21:29:35.21ID:m07GQTUo >>152
「カプセル化されているものを非カプセル化できる」というのはオープンソースだからこそでしょ?
「カプセル化されているものを非カプセル化できる」というのはオープンソースだからこそでしょ?
158デフォルトの名無しさん
2020/10/02(金) 22:40:42.45ID:r3ReT+S4 >>156
クローズドでもソースコードにアクセスできればできますが?
クローズドでもソースコードにアクセスできればできますが?
159デフォルトの名無しさん
2020/10/03(土) 00:08:13.37ID:yVZHteUR >>158
アセンブラで?
アセンブラで?
160デフォルトの名無しさん
2020/10/03(土) 00:11:36.28ID:yVZHteUR >>156
オープンソースで改変できるにしてもapache系のフレームワークみたいに巨大すぎてフォークしても後々のメンテナンス考えたら個人や零細企業では手に負えるレベルじゃない、というのはよくあるけどね。
オープンソースで改変できるにしてもapache系のフレームワークみたいに巨大すぎてフォークしても後々のメンテナンス考えたら個人や零細企業では手に負えるレベルじゃない、というのはよくあるけどね。
161デフォルトの名無しさん
2020/10/03(土) 00:13:45.56ID:yVZHteUR まあカプセル化否定派のnodejsとpythonが覇権を奪った時点で結論は出てるよね。
162デフォルトの名無しさん
2020/10/03(土) 00:15:27.57ID:Kq+qBTMl >>159
コードサイニング証明書付きだと機械語レベルで改竄したら動かなくなるでしょ
コードサイニング証明書付きだと機械語レベルで改竄したら動かなくなるでしょ
163デフォルトの名無しさん
2020/10/03(土) 00:24:20.04ID:wMNyZfVn そりゃ野良コーダーでも自由に改変できるのがOSSの強みだからな
OSS指向のnodeやpythonは安全を捨てて自由を選んだわけだ
逆に業務システムとかじゃ末端に好き勝手させないためのカプセル化が有効
OSS指向のnodeやpythonは安全を捨てて自由を選んだわけだ
逆に業務システムとかじゃ末端に好き勝手させないためのカプセル化が有効
164デフォルトの名無しさん
2020/10/03(土) 01:37:37.73ID:Y5A2bLqu PythonでもJSでもprivateな変数作れるの知らないんだね
さすゴミ
さすゴミ
165デフォルトの名無しさん
2020/10/03(土) 05:42:18.97ID:6PiAID7n >>159
ソースコードって言ってるのにバカなのか?
他人が作ったものを利用するなんてはそうしかないんだろうけどな
ソースコードっていうのはライセンスとは無関係に
開発者はソースコードにアクセスできるの
で今はカプセル化の話なんだろ?
ソースコードにアクセスできる人は普通に
カプセル化してるし、都合が悪ければ変更するだろ
だから何いってんだアホって言ってるわけ
ソースコードって言ってるのにバカなのか?
他人が作ったものを利用するなんてはそうしかないんだろうけどな
ソースコードっていうのはライセンスとは無関係に
開発者はソースコードにアクセスできるの
で今はカプセル化の話なんだろ?
ソースコードにアクセスできる人は普通に
カプセル化してるし、都合が悪ければ変更するだろ
だから何いってんだアホって言ってるわけ
166デフォルトの名無しさん
2020/10/03(土) 05:42:51.94ID:6PiAID7n167デフォルトの名無しさん
2020/10/03(土) 09:08:25.83ID:tGxUSHNX >>165-166
ソースコード非公開のライブラリの場合は?
ソースコード非公開のライブラリの場合は?
168デフォルトの名無しさん
2020/10/03(土) 09:11:04.42ID:S8hWGx6H カプセル化のためにめちゃくちゃ長い関数作るみたいな馬鹿なことやらなければ、
あとは勝手にやってりゃいいと思うよ。
あとは勝手にやってりゃいいと思うよ。
169デフォルトの名無しさん
2020/10/03(土) 13:18:20.54ID:thR3EccD >>164
どうやって作るの?
どうやって作るの?
170デフォルトの名無しさん
2020/10/03(土) 13:57:26.98ID:ALPWY5SS171デフォルトの名無しさん
2020/10/05(月) 13:02:03.02ID:pmj9NwTG 保守性高いプログラム書ける人しかいないチームならありだけど、初心者が入るチームはだめだな
レビューで指摘、とかいうルールにしても、結局締め切りギリギリで出してきて今回は仕方ないねで終わりそう
レビューで指摘、とかいうルールにしても、結局締め切りギリギリで出してきて今回は仕方ないねで終わりそう
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 米大統領報道官「日本と強固な同盟維持、中国とも協力」 [少考さん★]
- ミス・ユニバース フィンランド代表の「つり目」写真が波紋… 本人釈明も批判やまず 協会謝罪「徹底的に検証」へ [冬月記者★]
- 【おこめ券】鈴木憲和農相 小泉前農相の備蓄米放出を“反省”「備蓄の円滑な運営を図ってまいります」 [Hitzeschleier★]
- 1人3千円の食品高騰対策、何に使える? あいまいなまま衆院通過 [蚤の市★]
- ゆたぼん 二重手術を報告「めちゃくちゃ気に入っています」 [muffin★]
- 【27歳会社員】「自慰行為に使うために」コインランドリーの乾燥機から24歳女性の下着など計11点(時価8万2080円相当)盗んだ疑い [nita★]
