信者は盲目で物事の本質よりも自分が信じた教条や面子が大事だからな
だまされたともしらず
なにげに１スレが良スレ
staticおじさんのほうが自分がわからないことを認めてル分だけマシ
なにがメリットなのか説明できないのに、
持論を押しつけてくるバカが湧いてくるのは変わらん
改めて1スレ読んでみた。
身分がヨパラテ書いた批判ﾚｽの誤記がやけに目立ったｗ
なんで「カプセル化ってクソかよ」ってスレタイにしなかったの？
>>1のマッチポンプという言葉に触発されてチンポをシコシコするようになったのかな 継承・カプセル化・多態のオブジェクト指向三本柱マンのうち最初に倒壊したのはカプセル化じゃなくて継承なんだがな。
やれ継承より委譲だの、継承よりコンポジションだの、オブジェクト指向界隈内外からボッコボコよ。
まじかよ2019年にもなってこんなこと言う奴いるのかよ。終わってるな日本。
>>15
それ3000年前に土器焼きながら埴輪が言ってた 最初に倒壊したのは多態じゃないの?
ぱっと見きれいに書けるんだけど、次第にグダグダになる
カプセル化が次かな。setter と getter を使わないと書けない
というところで破綻している
>>17
多態は普通に使われてるし、
カプセル化の話に、setter、getterは関係ない 完全に倒壊して以後作られた言語が腫れ物に触るように扱ってるのは継承だけ。
逆に言うと他二つは生きてる。
三本柱→二足歩行だから、
おじいちゃんから青年に若返ったとも言える。
>>19
いや、継承も普通に使われるから。
さっきから話が飛躍しすぎているのだが、何なの？
何かの記事の引用？ まあアレだよね。自分の設計の下手さを
言語のせいにしてるっていうよくある構図
>>18
多態がきれいに決まった例を教えてくれ。
グダグダになった例しか私は知らないが
カプセルかは引数経由でしか内部状態の参照、書き換えを
許さないという意味だから、setter, getter の話では? >>22
お前なんか考え方がおかしいぞ。
なんだよきれいに決まるって
既存の物理法則か何かを多態で表現できるかどうかとか
そういう話してるんじゃないぞ
「ソフトウェアを作る時」に多態を使うんだよ。
当てはめるんじゃない。ソフトウェアの設計の話だ
多態の例ならGUIシステムで多用されてるだろ。
各コンポーネントはrender()メソッドを持っていて
各コンポーネントそれぞれのやり方で見た目を描画するとかさ >>22
> カプセルかは引数経由でしか内部状態の参照、書き換えを
> 許さないという意味だから
ぜんぜん違う。
obj.value = obj.value + 1
↑これはカプセル化が行われてるかつ、引数経由ではない内部状態の参照・書き換え方法だ だからさー、頭いいやつがGUIのフレームワークとか作るのはおおいに結構だし、
凡人がそのサブクラスで画面を作るのもいいんだよ
ただ凡人がクラスデザインを語るなっつーの
凡人は画面にボタンとかポトペタすればいいし、
クリックのイベントに業務のロジックを構造化プログラミングすればいいんだよ
ボタンと画面の描画は、フレームワークが適切なイベントで描画してくれるよ
画面とボタンの描画イベントが呼ばれるし、ボタンも画面もウィンドウのサブクラスかもしれないけど
凡人は気にするな
>>22
自分は18ではないが...
strage = usb
または
strage = sdCard
string text = strage.read(ファイル名)
みたいな記述はよくやる。
※組み込み開発 >>24
カプセル化の唯一無二の定義があるわけじゃないからそこをすり合わせないと。
それにその例はカプセル化が行われると言えるかどうか外からでは分からないよね
↓こういうコードの一部だったら一般的にはカプセル化されてるとは言わないと思う
struct Object
{
int value;
};
struct Object object = {0, 0};
object.value = object.value + 1;
あとRubyみたく'value='メソッドに引数を渡してる糖衣構文と捉えることもできるから
引数経由(メソッド経由のことだよね？)と言えなくもない
object.value=(object.value + 1) >>28
> カプセル化の唯一無二の定義があるわけじゃないからそこをすり合わせないと。
オブジェクトの内部表現とインターフェースを分離させること
この分離により、複雑な内部構造をシンプルに見せたり
インターフェースを変更すること無く、内部のデータ構造を効率のいい形に改善したり
互換性を保ちつつリファクタリングしたりと言ったことが用意になる >>25
凡人とそうでないやつの違いがわからんし
お前も聞くたびに違うこと言うから誰も相手にしなくなったんだろう カプセル化されていれば、インターフェースを変えることなく
内部構造を変更可能になる。
ということは、Rubyなんかは、普通に書いてもそれが出来るので
必ずカプセル化が使われていると言える。
>>22
カプセル化はもっと、シンプルに考えた方がいい。
カプセル化の意義は責務分割を行うことに意義がある。
setterとgetterを用意することが本質ではない。
※結果的に、private変数にアクセスするためのメソッドを用意する形になるが、それが本質ではない。
カプセル化する際は、クラスを使う人側の気持ちを考えて実装すべし。
setX,getYというメソッドを並べまくっても使いにくいクラスが出来上がるだけだから注意だ。 何か滑った感のある、新興宗教で頭わいたようなレスだな
>>29
俺もほぼ同じ理解なんだけど
そうするとgetter/setterは呼び出し側が依存してるインターフェースを変えずに
内部の実装を変更できるようにする目的で用意するものなので
カプセル化を実現する手段の一つに該当するんじゃないの？
ん、あれ、カプセル化にgetter/setter関係ないって書いたのと同じ人だと勘違いしてた
ま、カプセル化 == getter/setterでしょって言われるとそりゃ違うよってなるよね 継承は間違った使い方が多すぎるから批判されてる
単なるコード共通化とかな
それなら無くしちまえってのが最近の流れでは
>>34
もう少し勉強したほうが良いよ。getter/setterを別の関数として
用意しなければいけないのはJavaぐらいだから >>36
関数用意しなければいいとかそういう便宜上の問題じゃないだろ
たわけ >>38
だから関数を使わない（つまり引数も使わない）で
obj.value = 1 とか v = obj.value が使える状態で
カプセル化できるって言ってんだよ。多くの言語では。
↓ これが間違いだってわかるだろ
> カプセルかは引数経由でしか内部状態の参照、書き換えを
> 許さないという意味だから 自分で書こうと思ったコードがまんま見つかったので拝借ｗ
JavaScriptの例な
https://qiita.com/hogefuga/items/eefbbf6f4d2ff682c7e0
console.log(object.value); // no value
object.value = 'test';
console.log(object.value); // value: test
↑これは明らかにカプセル化されてる。
（リンク先を見ればgetter/setter経由なのがわかる）
しかし、objectの実装を以下のように変えても全く同じように動く
const object = {value: 'no value'};
ここでなんかおかしな話だなと気づかなければいけない。
クラスのインターフェースは全く変わらないというのに
クラスの実装によってカプセル化されてる or されてない が決定するのはおかしな話。
もちろんそんな変なことはない。両方とも「カプセル化されてる」んだよ。
Javaにおいて、カプセル化するというのは「getX/setX関数のみを使いパブリックフィールドを直接触らないようにすること」
その理由はパブリックフィールドを直接使うと、内部実装を変更したときにインターフェースが変わってしまうことがあるから
だから、Javaでは全てを「getX/setX関数経由でアクセス」すること＝カプセル化であるが、
JavaScriptにおいては、パブリックプロパティを直接参照しても、内部実装を変更したときにインターフェースが
変わらないようになってるから、JavaSciprtではデフォルトで全てのオブジェクトがカプセル化されてると言える
このように言語仕様でデフォルトでカプセル化されてる（もしくはカプセル化のための専用の機能がある）言語には
C#、Ruby、Python、PHP等がある。
言語仕様にカプセル化サポートの機能がある言語では、「引数経由でしか内部状態の参照、書き換えない」は間違い。 ようするに、今話をしてるのは、オブジェクト指向のカプセル化とはどういうことなのか？
という話なのだから、特定の言語での実装の話をするのは間違い。
"オブジェクトがカプセル化されていれば" インターフェースを変えること無く
内部の実装を変更することが可能になる。
言い方を逆にすると、インターフェースを変えること無く内部の実装を変更することが可能であれば
"そのオブジェクトはカプセル化されている" ということ
継承は、10年くらい前はmixinだのtraitだの流行ったけど、今やどうでもいいわって感じだな
>>40
カプセル化の概念を狭く捉えすぎ
Javaのgetter/setterやRubyのアクセサ、C#のプロパティなんかは
カプセル化を実現するための手段の一つであってそれイコールカプセル化じゃない
それにJSでもRubyでもC#でも直接インスタンス変数にアクセスしてるコードを
getter/setterやアクセサやプロパティ経由に変更した場合に呼び出し側に変更が必要な場合もあるから
デフォルトでカプセル化されてるとか考えるのは間違ってるよ
人にもう少し勉強したほうが良いよとか言う前に自分が勉強しようね …カプセル化じゃない
…間違ってるよ
…勉強しようね
>>46
それな。自分の意見を何一つ言ってないｗｗｗ たまにクラスにprivateが無いからカプセル化できないと言ってるやつがいるが、
「_で始まる変数名はprivateとする」という規約を作れば実現可能
C言語でオブジェクト指向をするという話と同じなんだよ。
C言語はオブジェクト指向言語ではないのでクラスなどが無いが
だからといってC言語でオブジェクト指向ができないわけじゃない。
言語機能として、privateやプロパティはカプセル化専用の機能であるが
カプセル化専用の機能がないからと言って、カプセル化ができないわけじゃない。
カプセル化専用の機能がなくとも、「_で始まる変数名はprivateとする」
「publicフィールドを使わずに、関数経由で読み書きする」という"規約"でカプセル化出来る。
関数経由で読み書きするのは、カプセル化専用の機能（の一つ）が無いJavaで
カプセル化するための"規約"に過ぎず、多くの言語では関数経由にする必要がない。
いずれにしろ、カプセル化をどうやって実現するかは言語の機能によって変わるが
カプセル化の概念は、内部構造とインターフェースを分離するして
外から内部構造を直接いじらないようにすること
プログラムの基礎であるメンバのスコープまたは
シンボルの命名規則を使ったアクセス制限規約のこと言ってんのかよ
元々簡単な筈のことなのに説明が下手にくどくて、
煙に巻かれて読んで損したような気分
>>49
間違い。文章短いのに何もわかってない
いや、短いからわかってないのかｗ カプセル化はデータとデータに対する操作をセットにすること
privateでデータを隠すのはデータ隠蔽
インターフェースで実装を隠すのは情報隠蔽
× カプセル化はデータとデータに対する操作をセットにすること
○ オブジェクト指向はデータとデータに対する操作をセットにすること
データとデータに対する操作をセットにすることは、カプセル化とは関係ない
privateでデータを隠すのはデータ隠蔽
インターフェースで実装を隠すのは情報隠蔽
そしてカプセル化という概念は、
「データ隠蔽」と「情報隠蔽」を使って実現するもの
privateやインターフェースがなくても規約等で「データ隠蔽」と
「情報隠蔽」相当のことを行うことも可能だが面倒になりやすい。
そのために言語が用意してくれる機能がprivateやインターフェース
オレオレ定義の押しつけあいで言葉遊びしてて虚しくねぇの？
ちなみにワイはwikipedia
オブジェクト指向はオブジェクトを大事にします
ってことなので値と操作をセットにすることとは違うよ
ちなみに僕はJavaのブロンズの資格持ちです
Javaの試験では僕が示したとおりに解答しないと落ちます
僕の定義は一般的ですよ
全世界で行われてるプログラミングの最も人気のある試験での模範解答なので
>>41で書いたとおり
"オブジェクトがカプセル化されていれば" インターフェースを変えること無く
内部の実装を変更することが可能になる。
言い方を逆にすると、インターフェースを変えること無く内部の実装を変更することが可能であれば
"そのオブジェクトはカプセル化されている" ということ >>72
情報を隠蔽することは必ずとも必須ではない
すべてさらけ出していたとしても、
インターフェースを変えること無く内部の実装を変更することが
可能になっていればカプセル化されてると言える。 >>74
君の思いはわかったけど独りよがりの思い込みに価値などない、君はJavaブロンズに受からない Javaブロンズの前で君たちの浅はかな理解など取るに足らぬ
ところで、ここまでオブジェクト指向をクソだとする根拠があがらないのはなぜ？
オブジェクト指向プログラマーvs誰がとは言わんがオブジェクト指向プログラマー気取り が激突するスレかな？
>>81
そもそも、オブジェクト指向にメリットが無いからな
強いて言えば単に費やす時間が無駄なだけ
オブジェクト指向とはソースファイルのどこに処理を書くか？
ただそれだけの技術である
→実はどこに書いたって動く（核爆） オブジェクト指向がクソなのはインスタンス変数の存在のせい
できるだけメソッドの行数を減らすとかインスタンス変数を使わないメソッドはオブジェクト指向じゃないとか巷で言われてるせいでそれを真に受けた意識高い初心者がゴミのようなコードを量産してしまうところにオブジェクト指向の限界を僕は感じましたよ
オブジェクト指向で作られたhello worldを見ればわかるがオブジェクト指向は過度な抽象化を促進する抽象化圧力つまりアブストラクションプレッシャリングアクセラレイトがかかるからそれをいなせる胆力がないと使いこなすのは難しい
>>83
なるほど、staticおじさんがstaticおじさんになった時の主張に似ているね。
オブジェクト指向の定義はさておき、インスタンス化のメリットはクラスという型から必要な数だけオブジェクトを生成できること。
そのメリットが無いのならJavaやC#のMathみたいにstatic化すればいいじゃんって思うし、オブジェクト指向をクソ呼ばわりする根拠が弱い気がするが...。
実際、自分もMathみたいにインスタンス化が不要であればstaticにするし。
まぁ、staticおじさんみたいに全部static化はしないが。
>>82
まぁ、既存の方法で困っていないのならオブジェクト指向は採用しなくてもいいんじゃないかな？
クソ呼ばわりしたら、なんで？って聞くけど。
コーディングの行数は比較したことがないからなんとも言えないが、オブジェクト指向導入で工数削減なら実現した事例は、いくらでもあるよ。
書いたコードを再利用しやすいのがオブジェクト指向のメリットの一つだからね。 >>83
× オブジェクト指向の限界
○ お前の友の限界。類友 
