オブジェクト指向ってクソかよPart5
レス数が1000を超えています。これ以上書き込みはできません。
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前前前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前前前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/
前前スレ
オブジェクト指向ってクソじゃねぇかよPart3
https://mevius.5ch.net/test/read.cgi/tech/1542884872/
前スレ
オブジェクト指向ってクソじゃねぇかよPart4
https://mevius.5ch.net/test/read.cgi/tech/1556462315/ staticおじさん超バカにしてたんだけど
前スレにリンクあったから約10年ぶりに読んでみたらちょっと印象変わったわ
むしろOOを必死に説明しようとしてる人たちの煽り耐性の低さと中身の薄さに驚いた
https://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html 信者は盲目で物事の本質よりも自分が信じた教条や面子が大事だからな
だまされたともしらず なにげに１スレが良スレ
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
オブジェクト指向はオブジェクトを大事にします
ってことなので値と操作をセットにすることとは違うよ >>60のリンク先を更に探すとここにたどり着いた
http://web.archive.org/web/20080906224409/http://www.itmweb.com/essay550.htm ちなみに僕はJavaのブロンズの資格持ちです
Javaの試験では僕が示したとおりに解答しないと落ちます 僕の定義は一般的ですよ
全世界で行われてるプログラミングの最も人気のある試験での模範解答なので >>41で書いたとおり
"オブジェクトがカプセル化されていれば" インターフェースを変えること無く
内部の実装を変更することが可能になる。
言い方を逆にすると、インターフェースを変えること無く内部の実装を変更することが可能であれば
"そのオブジェクトはカプセル化されている" ということ >>72
情報を隠蔽することは必ずとも必須ではない
すべてさらけ出していたとしても、
インターフェースを変えること無く内部の実装を変更することが
可能になっていればカプセル化されてると言える。 >>74
君の思いはわかったけど独りよがりの思い込みに価値などない、君はJavaブロンズに受からない Javaブロンズの前で君たちの浅はかな理解など取るに足らぬ ところで、ここまでオブジェクト指向をクソだとする根拠があがらないのはなぜ？
オブジェクト指向プログラマーvs誰がとは言わんがオブジェクト指向プログラマー気取り が激突するスレかな？ >>81
そもそも、オブジェクト指向にメリットが無いからな
強いて言えば単に費やす時間が無駄なだけ
オブジェクト指向とはソースファイルのどこに処理を書くか？
ただそれだけの技術である
→実はどこに書いたって動く（核爆） オブジェクト指向がクソなのはインスタンス変数の存在のせい
できるだけメソッドの行数を減らすとかインスタンス変数を使わないメソッドはオブジェクト指向じゃないとか巷で言われてるせいでそれを真に受けた意識高い初心者がゴミのようなコードを量産してしまうところにオブジェクト指向の限界を僕は感じましたよ オブジェクト指向で作られたhello worldを見ればわかるがオブジェクト指向は過度な抽象化を促進する抽象化圧力つまりアブストラクションプレッシャリングアクセラレイトがかかるからそれをいなせる胆力がないと使いこなすのは難しい >>83
なるほど、staticおじさんがstaticおじさんになった時の主張に似ているね。
オブジェクト指向の定義はさておき、インスタンス化のメリットはクラスという型から必要な数だけオブジェクトを生成できること。
そのメリットが無いのならJavaやC#のMathみたいにstatic化すればいいじゃんって思うし、オブジェクト指向をクソ呼ばわりする根拠が弱い気がするが...。
実際、自分もMathみたいにインスタンス化が不要であればstaticにするし。
まぁ、staticおじさんみたいに全部static化はしないが。
>>82
まぁ、既存の方法で困っていないのならオブジェクト指向は採用しなくてもいいんじゃないかな？
クソ呼ばわりしたら、なんで？って聞くけど。
コーディングの行数は比較したことがないからなんとも言えないが、オブジェクト指向導入で工数削減なら実現した事例は、いくらでもあるよ。
書いたコードを再利用しやすいのがオブジェクト指向のメリットの一つだからね。 >>83
× オブジェクト指向の限界
○ お前の友の限界。類友 細胞が膜で覆われてるのに似てる。
中身のものを直接扱えないのもな。 カプセル化を説明するときはリモコンや自販機や車とか、あとお店のサービスで普通例えない？
的外れな例えはむしろ害となりがち 変なのがワラワラ湧いてきたな。
オブジェクト指向はまるで池沼ホイホイだな。 カプセル化と継承を同じレベルで考えてるやつがいるからな。
継承は「行うこと」だが、カプセル化は「行うこと」じゃなくて概念。
カプセル化という概念がわかっていて、その概念に従って設計すれば
こういうメリットがありますよーっていう話だから
カプセル化という概念に従った設計をするときに使える便利な道具が
privateやインターフェース。だからといって別に使う必要があるわけじゃない。
多く言語ではカプセル化という概念を取り入れて言語を作っているから、
publicプロパティを使っていても、カプセル化に従うことが出来るが、
Javaではsetter/getterというワークアラウンド（_で始まる名前をprivate変数とするという規約と同じ）が
必要になるが、多くの言語ではそんな事気にしなくてもカプセル化という概念を満たすコードが書ける カプセル化とは何か人によって解釈がさまざまで、よく話が発散するが、
カプセル化を含むオブジェクト指向の害を弾劾するこのスレにおいて
自分の考えこそカプセル化として正しいとか主張すること自体
スレ違いなのは理解できている？ 腹いてえ下痢だよゲリぃ
グリーンピース食べすぎたわ >>91
カプセル化とは人それぞれである
カプセル化の説明すること事態がスレ違いだ
理解してるかー？ > 変なのがワラワラ湧いてきたな。
> オブジェクト指向はまるで池沼ホイホイだな。
> オブジェクト戦士（バカ）多いな
ここは罵り合うだけのスレかな？
やーい、お前のソースコードs t a t i c！ カプセル化おじさんのレス見て思うのは
自分の無知や間違いを認められなくなったら技術者としては終わりだなってこと
歳を取ると老害が増える理由 ↑このように自分の意見を何一つ言わず、
相手を批難するばかりになったらお終い ↑このように自分の意見を何一つ言わず、
相手を批難するばかりになったらお終い >>101
オブジェクト指向に関する意見に決まってるだろｗ > オブジェクト指向に関する意見に決まってるだろｗ
？？？ ここはオブジェクト指向のスレなんだから
カプセル化についての主張をするのは正しい
だけど、それは間違いだーっていうだけで
何が正しいのかの自分の意見を言わないのは老害でしかない。
という話だよ >>104
それな。間違ってるって言うだけなら
何も知らなくても出来る。 てっきり、いきなり現れた奴がブーメラン発言したのかと思った。
直前に>>95みたいなのもいたし。
名無しさんのままだと、誰が何を言ったのかわからん...。
大体、察したが。 おじさんってだけで拒否反応や反抗心から若者の意見を理解しない老害扱いするけど、
若者がおじさんの主張に耳を傾けてないのは結局おじさんと同じことしてるよね
おじさんの局所的な経験則やノウハウにも局所解としての妥当性を認めていいんじゃないかな？
銀の弾丸はないんだし
自分は関数型言語は型理論を触った程度の理解をしつつ、
オブジェクト指向推進派だったけど、長いことやってると
確かにオブジェクト指向に疑問を感じるときがある
例えば、複数のオブジェクトで協調動作させようとすると、
クラス内にカプセル化できなくなって、～コントローラや～マネージャーとか
どちらかというと抽象的なオブジェクトで溢れかえる設計ってとてもよく見るし自分も書く
C#のstaticクラスのstaticメソッドとかはそれへの部分的な解決法になるけど、
オブジェクト指向っていうより関数型的な感じがする >>108
コントローラーやマネージャーがが
クラス内の内部構造に直接アクセスするってどういう事？ >>104
>だけど、それは間違いだーっていうだけで
>何が正しいのかの自分の意見を言わないのは老害でしかない
いい歳したおっさんが二元論でしか物事を考えられない
答えを教えてくれないから「自分の意見を言わない」といって批判する
こういう考え方が老害そのもの
>>108
カプセル化おじさんとブロンズ君のやり取り見れば主張に耳を傾けてないのはどちらか明らか
中身の良し悪しは別にしてブロンズ君はカプセル化おじさんの意見に耳を傾けた上で論拠を持って適切に反論してる
かたやカプセル化おじさんは… >>111
だからそんな話じゃなくて
オブジェクト指向関連の話をしろよ
自覚ないのが一番たちが悪い オブジェクト指向にメリットなんかねー時点で議論など無駄 >>110
オブジェクトの内部構造に関係ない協調動作に関する処理を
どこに配置するべきかって話
専用のコントローラや専用のマネージャークラスが頻繁に作られるけど、
別のアプローチ（C#のstaticクラスのstaticメソッドとか）が可能なこともあるし、
別のパラダイムも検討する価値あるんじゃないかなと思うようになった
他の例をあげるなら、特殊な数値クラスを作ったとして二項演算子などの
演算子を数値クラス内にカプセル化するべきかって話も
協調動作の問題と重なってる部分があると思う
（ここまで行くと言語側に手を加えるレベルの話になるけど） オブジェクト指向が人の間に広まっていくうちに
どうしてだんだん変なやり方に変わってゆき
非科学的で都市伝説みたいな方法論になってしまったのか
よく分かる流れだな 複雑なものをシンプルに扱えるようにしましょうという
人間の心の話なのになんで科学がでてくるの？ >>108
> C#のstaticクラスのstaticメソッドとかはそれへの部分的な解決法になるけど、
> オブジェクト指向っていうより関数型的な感じがする
オブジェクト指向に関数型を適用してはいけないなんてルールは無いと思う。
そんなこと言い出したらOOPする際はラムダ式使うなって話になりそう。
あと、Mathクラスの解釈だが...
自分はMtahクラスみたいにstatic化するべきクラスでも、最初は非staticで設計する。
つまり、こうなる。
Math m = new Math();
int x = m.abs(引数);
でも、これだとstaticおじさんの言うとおり、オブジェクト指向ってしっくりこないんです状態。
※元ネタのstaticおじさんは具体例は挙げなかったが。
そこで、オブジェクト指向プログラマーは気を効かせ、static化する。
int x = Math.abs(引数);
つまり、static化は省略できるものは省略しよう...という、オブジェクト指向プログラマーの気遣い。
そういう解釈でいいと思うよ。
まぁ、どうしても「そんなのオブジェクト指向じゃねえ！」と言うのならオブジェクト指向の型を破ると解釈してもいいけどね。
このスレ的にはOOPの解釈を曖昧にするのは駄目な気もするが、個人的には扱いやすいクラスさえ作れれば何でもいいや。 はぁ？absをオブジェクト指向にするなら
Number n = new Integer(-123)
n.abs() やろ >>116
そういいながら、逆にシンプルなものを複雑にして
迷信じみたことを技術の世界に持ち込むから >>120
(うわっ、こいつ面倒くせ)
そんなにMathが気にくわないのなら、俺じゃなくてOracleやMicrosoftに連絡すれば？
別にabsの実装について話がしたかったわけではないし。 今まさにオブジェクト指向によってもたらされている混乱から目をそむけないほうがいいよ >>85
>オブジェクト指向の定義はさておき、
ところで「チンボがシコシコする」という日本語表現は、文法的に正しいのか？
チンボ「を」シコシコするのではなくて、チンボ「が」シコシコする。この場合、「チンボ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！ >>125
それは興味深い考察ですね
ちんぽがシコシコするはダメなのですか？ つまりオブジェクト指向とは、俺の股間に付いているモノなのである！
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′
チンポは独立した生き物であり、本人の意思とは無関係に、自らの意思で勃起してシコシコする！ 人類の歴史を作ってきたのはおじさんだからな
おじさんの言うことを聞いていればだいたい間違いはないが、重大な間違いを犯すのもまたおじさん >>128
だからオブジェクト指向は俺の股間に付いているのだ！ カプセル化って
中に有るものを見たり使ったり出来ないようにしないと意味が無い
getter,setterで使い捲くるのでは余り意味が無い(初期設定はしないといけないからsetterなりコンストラクタで設定する必要は有る)
それではグローバル変数となんら変わりは無い
ただそれをどうやればいいのか?
と聞かれるとセオリーや具体的な手法が存在していない
それがオブジェクト指向プログラミングが糞と言われてしまう原因になってる
現状では属人的に出来る人だけが使えるようになってしまっている >>132 の発言を自分がちゃんと理解しているか怪しいのだが...
> getter,setterで使い捲くるのでは余り意味が無い(初期設定はしないといけないからsetterなりコンストラクタで設定する必要は有る)
> それではグローバル変数となんら変わりは無い
んん？具体例がほしいな。
こういうこと？
class test｛
private:
int x;
public:
int getX(){
return x;
}
void setX(int a){
x = a;
}
｝
これってあんまり意味ねーよね？って話？ >>132
まーた間違ってる。
グローバル変数がなぜ悪かというと、プロジェクト全体から
読み書きできてしまうのでどこで参照してるかわからないから。
つまりスコープの範囲が広すぎるという問題。パブリックであることと何の関係もない。
それにカプセル化は、隠さなくて良いものまで隠せと言ってるわけじゃない。
隠すもの（内部構造）と隠さななくて良いもの（インターフェース）を
きっちりワケましょう、それによってメンテナンス性が上がりますという概念
すべて隠さなくていいオブジェクトだって存在する。それはそうするのが正しいので
カプセル化を破壊してることにはならない。隠すべき内部構造がないと言うだけ。
なんで隠してなければ、カプセル化破壊だと思うんだろうか？
getter,setterってまたJavaの話をしてるんだろうけど、
それはJavaという言語にカプセル化を実現するための機能が不足してるから
規約でカバーしてるだけ。他のオブジェクト指向言語であれば
お前の言うgetter,setterが無い言語もある。
お前がオブジェクト指向を理解してない＝お前が糞なのであって
それをオブジェクト指向のせいにするな。
あと知識が狭すぎる。Javaしか知らないんだろ。 俺も昔はグローバル変数についてそういう認識だったけど
そもそもスコープがどうであれ
ドキュメントに何もねぇ変数を把握する事自体
やってらんねぇよクソッタレって認識に変わった
本質はドキュメントに書いてないことが問題であって
スコープが仕様を形成するものであってはならない >>135
イミフ。有名なオープンソースのコードを見て良いコードとは
コメントが書かれてないコードだと知ったほうが良いよ。
そんな物無くてもメンテナンスしやすいような構造になってる。
あとスコープが仕様を形成するなんて話は誰もしてない。 × コメントが書かれてない
○ コメントが重要なところにしか書かれてない コメントに頼らなくてもある程度理解できるコードと言いたいのでは？
コメントはあったらあったで助かるよ。 >>136
バカじゃん
テメーが考えたコメントをソースに書いてんのか？
コメントってのは設計書の文言をコピペしてこそ意味があるんだよ
ソースにあるコメントで設計書を検索してヒットしない成果物いりませぇん 設計書に書いてあるなら、どこそこの設計書見れでいいじゃん
コピペ作業に金払わされてるとか、経営者が可哀想でならん どこそこの設計書見れって書いてないから、
設計書を"検索"するはめになるわけで（苦笑） >>134
>グローバル変数がなぜ悪かというと、
チンポは独立した生き物であり、自我でコントロール出来るわけてはないからな！ >>141
自己流で書いたコメントはそれすらできないからね >>143
あの、もしかして、お前が言ってるほうが
「自己流」のやり方だって気づいてないですか？
ぐぐって調べてみてください。
誰もそんなことしてないですよ。 なんか、凄まじい話の脱線風景を見てしまった...。
なんで>>135からコメントの書き方バトルに発展するのか...。 >>144
はぁ？
だからデスマになるんでしょ？
テメーの気持ち悪い親切心で書いたコメントなんかいるかよ
気持ち悪いから早く死ね
重要なのはそのコードが設計書のどこの部分かってことだけだ >>146
具体的理由を述べてどうぞ。
呟くだけならTwitterでどうぞ。 スレでさんざ書いてきたことだし
うえの議論のずれっぷり見ても十分理由だろう 弊社にもいたよ、独特のオブジェクト指向論を持ち、
変な理屈こねて、これぞオブジェクト指向だと自説を押し付けたり
他人を批判したりして、チームの仕事を停滞させ
そのくせ、プログラムの開発をしてもらうとロクなコードが書けず、進捗が遅くて、
継承とメソッド呼び出しスパゲティーでバグだらけ
直る見込みがないので悪いけど間接部に移動してもらった。 いや、自分はさっきから議論がズレすぎてなんでOOPがクソ扱いされるのか未だに理解できないのだが。
台風が来た(わかる)→台風で死者が出た(わかる)→首相が悪い(は？)
並みに飛躍しすぎて意味不明なのだが。
どさくさに紛れてOOPをクソと結論付けるのはやめろよー。 >>150
うん、それはお気の毒に。
まぁ、そういう人はいるよね。このスレにも。
でも、それを根拠にOOPをクソ扱いするのは違うと思うんだ。
そもそも、そいつ自体がOOP理解しているか怪しいし。 いままでのレス読んで理解できないのは
読解力や個人の能力の問題。
それこそしらんがな >>152
そだな、そういう痛々しい人の問題は別にしても
オブジェクトにどのような害があり、それを使ってソフトウエアのアーキテクチャ・構造の表現がしにくくて
大規模で複雑なシステムの構築上、人間が理解しにくいものが出来てしまうか
さんざ書いてきたが、読んでねーか、まともなあたまをもってねーか、、、
痛々しい人の問題はその上にかぶって存在し、オブジェクトの
局所的な一見便利そうで利点に見えるが
ある程度の規模の構造上 逆に欠点となる方法の押し売りなんだよ
オブジェクトとはなにか、どういうやり方こそオブジェクトとして正しいか
意見の応酬などは論点じゃないんだけれど、
そういう論点好きは、痛々しい人とほぼ同類 コメントとコードであっても二重管理になって
同期が取れなくてトラブルのもとになるというのに
設計書とコメントとコードの三重管理とか気が狂いそうｗ >>153
今までのってどこの部分？
安価つけてほしいね。
ついでに、あなたは本当にOOPを理解している上で批判しているのかい？
聞いた話では他の人が書いた自称OOPコードを見てクソだと思ったのでしょ？
是非、そのクソだと思う部分を教えてほしいね。
>>133みたいにコード書いてもいいんだよ？133はスルーされちゃったけど。 たとえば、
カプセル化とは何かの解釈の幅によらず、
カプセル化によるスコープやアクセスの管理は、ぱっと見とても有効に見えるが
実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、
規模に応じ急激に複雑さをまして
（レキシカなスコープ、エクステント管理に対し）
人間が管理把握しにくくなる因子であることは、
一定の理解を得られているはずだが そもそもオブジェクト指向なんて数字を上げたメリット説明できねぇんだから
他人を叩きのめすのに使えばいいんだよ
仕組みはどうあれ俺が気に入らないのでテメーは死刑だ >>156
「OOPを理解している上」
そうやってすぐ
OOPの解釈議論に論点をずらそうとする…
痛々しいなあ >>158
科学的技術的な話ではないので
ある意味そういうことだとおもうよ。 >>159
これが先に目についたのでこっちから答えるが、当然だろ。
スレタイは オブジェクト指向はクソかよ だ。
オブジェクト指向をまったく理解してないのにクソ呼ばわりはないだろ。
その大前提を崩すと、お前が非難しているのはOOPじゃなくてstaticおじさんの可能性すらあるんだよ？
痛々しい以前に論外過ぎるだろ。
正確な定義は理解していなかったとしても、自分ではこれがオブジェクト指向だという考えくらい持てよ。 まったく理解せず色々言うのはよくないが、
オブジェクト指向をまったく理解してないやつなんて
そもそもいるのかよｗ
それにOOP解釈によらずCでも頑張ってOOP的な書き方をしても
>>157
のような問題はでるんだぜ
細かく派生した、場合によって人さまざまなOOPの解釈の違いによらない
欠点があるといってんだが、読み取れないのか。。。 オブジェクト指向のメリットを定義してよ
って言うといつも逃げ出すじゃん 方法論にずれちゃうんだよね
良くて局所的なメリット論 >>158
> そもそもオブジェクト指向なんて数字を上げたメリット説明できねぇんだから
どのような数字を上げれば良いのですか？
オブジェクト指向以外で、数字を上げたメリット説明してるものを
参考として教えて下さい。 >>163
管理しやすくなるってメリット言っても
数字言えって言って逃げてるじゃんｗ だからオブジェクト指向は俺の股間に付いているってことなのさ！ >>169
そうか、それでOOPはクソなんだ。
納得 >>163
逃げた覚えはないけどな。
まぁ、いいや。俺の意見だが。
思い付くメリットを列挙するとこんな感じだ。
(1)責務分割を行うため各コードの役割が明確になる。
→共同開発時、作業分担がしやすくなる。
→不具合が発生したとき、どこが悪いのか明確になる
(2)必要な数だけオブジェクトを複製できる。
→例えば...組み込み開発だが、USBオブジェクトがあったとして、USBポートを一つから四つに増やしたいとき
Usb usb[] = new Usb()［4］;
といった記述で増やせる。
(3)ポリモーフィズムが可能
Storage s = new Usb();
...
s = new SDCard();
SDカード・USBの違いを区別することなくアクセス可能。
s.read(ファイル);
他にもメリットは腐る程あるが、そこは自分で調べてくれ。てか、質問スレでどうぞ。 >>166
数字？なんだそりゃ。
非OOPの品質が1ならOOPの品質は10
これでいい？納得した？しねーだろうなぁ(投げやり)
スマホ入力つらい...PCもってくるか... >>171
(1)はstaticの利点でもあるな
(2)はOOPの話じゃないだろ
(3)は何が言いたくて何が利点だかよく分からないけど、
関数の共通化できますってことか？OOPにかぎらんだろ
長文乙だが、読んでて気がついたは
あんたが書いている程度の規模のプログラムだと
何のパラダイムでも大して管理は変わらないと思う
何でこのレベルのひとが「OOPを理解している上で」とかえらそうなことを言うのかの方が疑問 >>172
いいよ持ってこなんで。
話を聞くだけこっちの時間の無駄 >>173
> 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、
> 規模に応じ急激に複雑さをまして
> （レキシカなスコープ、エクステント管理に対し）
> 人間が管理把握しにくくなる因子であることは、
> 一定の理解を得られているはずだが
こんな意味不明な発言をする人に言われたくねーです。 >>175
これ分からないんだったら単に不勉強だと思う。
ここ数年間のソフトウエア工学の進歩を眺めてりゃ分かる程度のこと。
まぁ、多くのITエンジニアがやは不勉強なんだが。
不勉強で理解できないのは自然なことだ、しょうがない >>173
> 人間が管理把握しにくくなる因子であることは、
> 一定の理解を得られているはずだが
ちんぽは本人ですら管理できない独立した生き物だが？ >>177
そのうち、年取ると小便にしか使わなくなって
逆の意味で言うことを聞かなくなるから
心配要らないよ >>176
> 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、
> 規模に応じ急激に複雑さをまして
> （レキシカなスコープ、エクステント管理に対し）
> 人間が管理把握しにくくなるあることは、
> 一定の理解を得られているはずだが
なんでカプセル化がこの問題に繋がるのか説明してくれる？
コード書いてほしいな。或いはもう少し具体的に説明してくれないかな？
飛躍しすぎてわけがわからん。 >>179
過去スレでもさんざ書いたんだが
自分が不勉強なくせに、5chにでまた長々かけってか、、、
子供電話相談室じゃねんだが。。。
まずプログラミングの基礎である
レキシカなスコープ、エクステントは
分かるよね？ は？
全くわかんね
書いてあることがどうとかってより
まず、
どうなるとオブジェクト指向なの？ あとオブジェクト指向のもたらした依存の複雑化する問題は
理解しているよね？ >>182
ごめんごめん、受けた？
○ レキシカルなスコープ 知ってる。そんなレベルの話ではなく、なぜ、そこに問題がでると思っているのかの話。
レキシカなスコープという時点で何かを感じるが。 >>185
ダイナミックスコープがまずいのは分かるだろ？
いわゆる旧MS BASICのような。
では大規模ソフトでレキシカルスコープがなぜ大事か分かる？
ここ40年くらいの間に普及したんだけれど。 >>183
これが抽象的過ぎてわからん。
なんで、毎回曖昧な表現使うかな...。 >>186
あっ...ここでもうわからんわ。
ダイナミックスコープがまずい？ カプセルかってのは何やんのよ。
細かい解釈の違いは、頼むから横においておいてよ。
1) 型クラス
2) メンバのアクセス制限修飾
こきらまでは旧来のCもできましたよと。いいよね。
3) アクセスmethodを設け、calssまたはインスタンススコープを持たす
そして「動的な」が好きな人は
4) 動的インスタンスの生成・消滅
⇒エクステントはレキシカルとは結びつかず独自に管理せなあかん >>168
> だってそれお前の感想止まりじゃん
俺の感想じゃなくて世界の感想だってｗ >>188
スコープダイナミックって言うことは、外から見える変数ばっかりで
プログラムがちょっと大きくなっただけで、局面局面で意識・管理せにゃならん
変数や状態が増大しくみ合わさって入り組んで見えたり、
あるいは実行時に呼ばれる順が変わると変数の内容が変わったり
管理不能になる
昔はそういう言語しかなかった
CやShemeがlexical scoprやextentを導入して革命がおきた >>191
なんなら、関数型と手続き型と比較してみますか？
データ出してみてください。 C#とnode.js使いだけど、ダウンロードできるオープンソースでオブジェクト指向じゃないコードを落とした経験がまったくない。
たぶん、業種によるんだろうな。
オブジェクト指向と無縁の業種とは無縁だから具体的に何かは知らないけど。 そうでしょっていうのは、お前が関数型と手続き型の
データを持ってくるってことね。
自分で検証しなくていいのよ。お前がやりましょうってこと。 困ったな
俺はメンバ変数全部publicだし
お前らの組み方だと組むときになって
アレ？このメンバ変数privateだ!
オラ、びっくらこいたーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー!!!!!!!!
設計を根本から見直さなきゃ!
ってシーンがないとダメなんだろ
俺、そういうことねーし >>194 あたりまえやんけ、そんなこと。
そえはさておき >>189 がカプセル化の概要であるとして、
どのような弱点をもたらすか
1つはスコープの問題
メンバにアクセス修飾制限するのは一見いいことのように見える。
複合体型に基づくclassやインスタンスのメンバごとのスコープは
フレームワーク的な中間レイヤの局所では一貫して明確に決めやすいけど
上位の複合的な機能のアプリレイヤに近づくと、型も色々持ち込んだ複合的な
ものになるわけだし、動的に生成したインスタンスを動的なエクステントで使いまわす
ので、メンバへのアクセス制限は局所局所で融通が利かず一貫性を維持しにくくなって
結局多くのメンバをアクセサを用意するはめに陥る。
これは、グローバルなscope、動的ななextentを持つ(名前階層を持った)
多数の変数でプログラムを組むことと同じ複雑さをもたらすでしょ。
そのなかでエクステントの管理もやっていくと、、、(弱点2)
どMかよ＞
では >>183 と組み合わさって、さらにどのような弱点をもたらすか… なぜ変数やメソッド(メンバ関数)をprivateにするか？
少なからずの場合それらが試行的もしくは暫定的。
例えばシグネーチャがまだ流動的な場合とか。
自分も含めて勝手に使って欲しくない、少なくとも使われる箇所を完璧に把握しておきたいような場合。 >>187
>これが抽象的過ぎてわからん。
>なんで、毎回曖昧な表現使うかな...。
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く オブジェクト指向のもたらした依存爆発へのカプセル化の関与
多態はmin, max、abs くらいに制限しまずは捨てましょう。
継承はソースの合成レベルで大いなる依存を持ちむので、
特にアプリレイヤでの活用はホント色々問題あるんだけれど、
カプセル化はというと、
1つはdynamic なextentが好まれる点ね。
どっかで作られるインスタンス・メンバが、見通しやすいnest したlexicalなscopeを離れて
浮遊し、どっかで参照、更新されると。。。。
動的にだぞ？お前がやっているような小さいプログラムは何とでもなるかもしれないけどさ、
どうやって追っかけんだよ
二つ目はデータ構造間の依存、三つ目はデータ構造に対するメンバとmethodの依存
たとえば委譲した動的階層化データ構造の中の、ある局面で一見みえないメンバがどこか遠くで
定義され参照され更新され、、、、orz
あるいは複合型クラスのインスタンスとメンバを多階層の継承と組み合わせた場合、、、、、
まぁ言わずもがな経験者は分かるだろう
管理不能なスパゲティ－の出来上がりだわな
こうやってカプセル化した動的な型構造は依存を中継するハブ見たいな役割を果たしてしまうんだよ
このたわけめ
ここまで1から10まで説明させるとは、金取るぞホントに これがネットのどこにも落ちてない口伝でのみ伝えられるという奥義(ﾟＡﾟ;)ｺﾞｸﾘ
( ﾟдﾟ)ﾎﾝﾄﾆﾊﾔｯﾄﾝﾉｶｲ？ 入門者とえせ講師を中心に日本中で絶賛大流行中だぜ。
もう新興宗教かめ威信か、比科学的もいいところ >>199
> ので、メンバへのアクセス制限は局所局所で融通が利かず一貫性を維持しにくくなって
> 結局多くのメンバをアクセサを用意するはめに陥る。
なんでアクセサを用意したらダメなんて思ってんの？
それが外部から触るなら、インターフェース化（≒仕様化）するってだけでしょ >>202
> 動的にだぞ？
動的ってどういうこと？
参考コード書いてよ >>202
> の、ある局面で一見みえないメンバがどこか遠くで
> 定義され参照され更新され、、、、orz
参考コード書いてよ なんだろう、OOPってこんなに難しい話ではないと思ったのだが...
着目点が違うのだろうか。
OOPに関係のない概念まで出てきているような...。
誰か、理解、できた、人、いる？
いや、static/lexical scope、dynamic scope、extent、依存、複合型クラス、インスタンス
これらの用語が全然スッと頭に入ってこないのはなぜだろう。 >>202
> あるいは複合型クラスのインスタンスとメンバを多階層の継承と組み合わせた場合、、、、、
> まぁ言わずもがな経験者は分かるだろう
ちゃんと書けよ >>209
着眼点がおかしくて、たぶん問題を解決するためにオブジェクト指向を使うんじゃなくて
オブジェクト指向の問題点を見つけるためにコードを書いてるんだと思うよｗ >>206
せっかく内側に入れて隠そうとしたものが、
実は外からアクセスする必要にあるものでしたﾃﾍﾍﾟﾛというのは
設計のミスだったり複合型化すべきではないものだったりするじゃない。
それにプログラムが実行中にある局面から見える変数や環境、
あるいは関数は数が多くなっ足り独自のextentを持っていると
急激に人間には複雑に見えてくるでしょ
だからアクセサを多数用意するのｈ簡単だけどそうした段階で、その後の管理苦労はもう目にみえているわけ
本とここは子供相談室かよ 機能一覧
→各機能の処理一覧
→それに対応する関数一覧
を作ってた昔のほうがシンプルだよ
これ以上シンプルなモノがないのに
余計なことしてわざわざ難しくしてる >>213
> せっかく内側に入れて隠そうとしたものが、
> 実は外からアクセスする必要にあるものでしたﾃﾍﾍﾟﾛというのは
> 設計のミスだったり複合型化すべきではないものだったりするじゃない。
お前の設計のミスでオブジェクト指向の問題じゃない >>217
おれはそんなことやんないって、何勘違いしてんだたわけが
>> 206 になぜよくないか言っただけ >>213
だから具体的なコードを書けと。
あと複雑さをゼロにするものだって思ってないか？
お前がオブジェクト指向に過剰に期待して、
オブジェクト指向はダメだって言ってるだけ。
例えて言うのなら
お前「エアバッグは自動車事故を完璧に防ぐものだ」
お前「でもエアバッグでは自動車事故は完璧に防げない」
お前「だからエアバッグはだめなんだ」
このセリフを一人で言ってるだけ。 >>217
もうオブジェクト指向方法論にずらさないで
重箱の隅はどうでもいいので えっ、私だけ不勉強なの？
どなたか、解説をしていただけないだろうか。
カプセル化がstatic scopeとextent管理に問題を及ぼす解説らしいのですが...。 >>218
俺もオブジェクト指向で、そんな設計ミスしたりしない。
お前の中の想像の人間の話でもしてんのか？ >>219
複雑さを増大させるとかいたらすげー極論が出てきたな
論理的なものの考え方が苦手な人がよくブジェクト指向にはまる >>1214
オブジェクト指向が解決するのは、
> 機能一覧
> →各機能の処理一覧
> →それに対応する関数一覧
これらを組み合わせる時の問題 >>221
直訳すると
テメーの態度が気に入らない
ということになる >>223
俺が言ったことが極論でもなんでも良いから、
何か言い返せよｗ >>221
そういうのを論理の飛躍という
根拠なく利点と結びつける >>224
いらないよ
普通に関数一覧の関数作ったら終わりやで
入出力も明確や
いいからさっさと作れ >>226
子供だな。
>お前「エアバッグは自動車事故を完璧に防ぐものだ」
>お前「でもエアバッグでは自動車事故は完璧に防げない」
>お前「だからエアバッグはだめなんだ」 エアバッグの性能を厳密に測定しないとわからないよね >>228
じゃあ、その関数一覧でさ、
アルゴリズムが、例えば
AES暗号を使ったモジュール
TDES暗号を使ったモジュール
2TDES暗号を使ったモジュール
3TDES暗号を使ったモジュール
みたいに複数あって、
それらを交換可能にするときはどうするのさ？
てんでバラバラの関数一覧があるだけではダメってのがわかるだろ？
それらの関数一覧に対する共通の仕様（＝インターフェース）が
定義されれてないとダメ。
それに関する問題を解決するのがオブジェクト指向なんだが そう言う問題以前に
誰も言っていないことを、お前は言ったとか
妄想か池沼かガキの言い分か 何を言ってるのかわからないけど、間違いなく3vnN9KRUはオブジェクト指向を有効活用しようとしたことがないのは分かった。 >>232
そんなもの昔からあるパラダイムで十分実現可能だし
Cなどでそう実装されている >>235
それを発展させて汎用化したものがオブジェクト指向。
関数があるだけでは、それらを組み合わせる時の問題に対処できない。 >>234
分からないんじゃしょうがないだろ
分からないからこそオブジェクト指向の沼にはまってんだろ >>237
> Cなどでそう実装されている
C言語でオブジェクト指向が実装されてるからなんだっていうのか？
オブジェクト指向とオブジェクト指向言語の違いぐらい理解しろよ。 >>239
お前がオブジェクト指向の沼にハマってるだけだろｗ
それともまた、「お前の考える想像上の人物」の話でもすんのか？ｗ スコープダイナミック！ｗｗｗ
ギャバンダイナミック！ｗｗｗｗｗ >>239
ええ！？
わからないのにあれだけ長々オブジェクト指向の批判してたの！？ >>240
C言語を使ってオブジェクト指向のようなコードは（回りくどくなるが）記述しよとすればできるが、
C言語にはオブジェクト指向の機能は実装されていない。
他の言語も同様。
基地外だったか… >>243
やはりオブジェクト指向は一子相伝・・・ >>244
オブジェクト指向の機能が実装されて無くても、
オブジェクト指向は出来るんだよ。 オブジェクト指向の批判として捉えようとしたからダメだったのかな...。
うーん、もう一度読み直してみます。 > >>239
> ええ！？
> わからないのにあれだけ長々オブジェクト指向の批判してたの！？
>>234
> 何を言ってるのかわからないけど、
分からないといったのはお前さんID:BlSgSv0Gだよ >>248
いやもう、オレんとこにきた新人の派遣さんだったら
ホワイトボードに書いて教育してあげんだがな… >>249
いや、理解してないのは お ま え。
オブジェクト指向のコードまともに書いたことねぇだろ。 まあ、オブジェクト指向は難しいからな
俺が気に入らない奴は全員わかってないことにしてぶっ叩いてやる >>250
うちも新人の派遣さんに、オブジェクト指向の教育をしてるよｗ 当たり前だが、新人でない社員は、全員オブジェクト指向を理解しているｗ >>254
オブジェクト指向の教育をしてるから、
殆どのフレームワークの設計を理解できるよｗ
ほぼすべてのフレームワークはオブジェクト指向だからね。 お前もお前もお前も全員
オブジェクト指向について素人臭くって見てらんない
唯一俺だけが理解してるし
俺以外のはオブジェクト指向じゃないからね
いいね 嘘だろ、ｗ
少なくともお前は理解している気になっている新興宗教宣教師のスパゲティー製造機だろｗ
白状しろｗ >>254
いや、お前の新人も可哀想だわ。
staticおじさんの子供を製造しているとか恐ろしいな。 >>256
うそこけ、numpyとか山のようにあるだろ
馬脚をあらわしたなｗ 少なくともオブジェクト指向が世の中の多くを締めてるんだから
それを教えないのは愚の骨頂だよね。
オブジェクト指向を知らなければ、オブジェクト指向を批判することも出来ない。
（デファクトスタンダードの）オブジェクト指向がわかりませんっていう人間が出来てしまう。 なんか、加速やべえ。
オブジェクト指向がクソだと思う人は使わない。
オブジェクト指向にメリットが見いだせる人は使う。
もう、それでいいと思うよ。 >>262
では、オブジェクト指向を無視してよかった事例、どうぞ。 https://docs.scipy.org/doc/numpy-1.13.0/user/whatisnumpy.html
> NumPy fully supports an object-oriented approach,
NumPyを使うときも困るだろうなｗ >>262
使っているよ。
役に立つところにところではね。害のあるところでは使わない。
Java案件は使わざるを得ないかな注意して使うけど、周りかだどんどん汚いものが入ってくる >>264
なんで俺にオブジェクト指向を無視してよかった事例を聞くの？
オブジェクト指向を批判する人は、オブジェクト指向を理解してないとダメだが、
オブジェクト指向を理解したからと言って、オブジェクト指向を批判する必要はないしw >>265
中で使っているんだよ。それをアプリレイヤでは演算子で使う。
なのでOOP的な書き方とは一線を画している >>268
急に「NumPyはオブジェクト指向を中で使われてる。」と
オブジェクト指向は使われてることをアピールしてどうしたの？ｗ NumPyのIFは手続きと演算子でOOPSが隠されているからさ。 >>270
でもNumPyの内部に踏み込むと
オブジェクト指向なんでしょう？ｗ
オブジェクト指向教えないと、使えない人間になっちゃうよ？ >>268
突っ込みどころ
1.それってオブジェクト指向をクソだと言えないのでは？
2.むしろアプリ層ほど、オブジェクト指向って重要だと思うのですが(フレームワーク的に)。
2.は何の開発をしているのかにもよるだろうけど。 「NumPy グラフ描画ライブラリ」でググると
一番目に出てくるのがmatplotlib
https://ja.wikipedia.org/wiki/Matplotlib
> Matplotlibは、プログラミング言語Pythonおよびその科学計算用ライブラリ
> NumPyのためのグラフ描画ライブラリである。
> オブジェクト指向のAPIを提供しており、様々な種類のグラフを描画する能力を持つ。
なので、どちらにしろオブジェクト指向は必須なんだわ
オブジェクト指向が嫌いなら嫌いでいいが、オブジェクト指向を教えないのは愚の骨頂 >>272
ここに書いているだろ。
>>266
> >>262
> 使っているよ。
> 役に立つところにところではね。害のあるところでは使わない。
> Java案件は使わざるを得ないかな注意して使うけど、周りかだどんどん汚いものが入ってくる
その上で問題があり害のある使われ方がしていると
いっているんだが。
前スレではどういう場合に使うか書いたんだけれど、また長々書くのは嫌だわ なんで言語の問題じゃなくて、
「俺の周りの人間がクズなんだ」って話にすり替えるんだろうかｗ
類は友を呼ぶって言葉知ってる？
周りがクズなら、お前もクズだっていってるようなもんなんだよ。 >>273
matplotlibが必要があってOOPSにしたか、あるいはなんでも良かったのかは不明だから
使っているから、必要があると決め付ける。
こういうのをミスリーディングという。
>> 219 でも気になったけど
誰も言っていないのに
>例えて言うのなら
>お前「エアバッグは自動車事故を完璧に防ぐものだ」
>お前「でもエアバッグでは自動車事故は完璧に防げない」
>お前「だからエアバッグはだめなんだ」
>このセリフを一人で言ってるだけ。
と妄想して決め付ける、揚げ足取りのをミスリーディングが多くて
まじめに議論する相手としてふさわしくないな >>276
> 使っているから、必要があると決め付ける。
使ってるんだから、matplotlib使うコード書くときは必要じゃん？
オブジェクト指向が必要なフレームワークをたくさん上げればいいの？
NumPyだけで仕事できるわけじゃあるまいし
あんたが、何を言いたいのかわからん。 >>275
また決め付けた
>「俺の周りの人間がクズなんだ」って話にすり替えるんだろうかｗ
>類は友を呼ぶって言葉知ってる？
>周りがクズなら、お前もクズだっていってるようなもんなんだよ。
オレがそんなこと書いてないのに、答える必要はなさそうだな
どうもお前さんとは話がかみ合わないな >>276
あと、日本語が理解できてないよ。
誰も言ってないって、
「俺が例えとしてだした」んだから
誰も言ってないので当たり前じゃん。
なんで俺が言った（例えによる）説明を
他の人が言ってるはずだ。って思っちゃったのさ？ｗ >>277
日本語苦手？
matplotlib は必要があってOOPS IFを採用したかは不明だと書いているんだよ >>278
> オレがそんなこと書いてないのに
↓書いてるじゃんｗ
> 周りかだどんどん汚いものが入ってくる >>279
誰も言ってないことを 人が言ったことのように書くなよ >>280
> matplotlib は必要があってOOPS IFを採用したかは不明だと書いているんだよ
え？なに？その理屈でいいなら、
NumPyは必要があってOOPSを採用してないかは不明だといえばいいの？ｗ >>281
やっぱ日本語苦手そうだな
周りとは周辺の既存コードとかインスタンスや依存からだよ。 >>278
まずあなたは>>171のメリット説明で軽く流してましたが、あなたはOOPのメリットを理解しているのですか？ >>282
人が言ったことだと思ったのは
お前のミスであって、
俺は最初から、自分の意見しか言ってない >>284
つまり、お前がコードを書くと、
周りから汚いコードを入れてしまうってこと？ｗ >>288
今、お前が勘違いしてるって言ったばかりだよね？ >>287
興味本意で聞きますが、OOPのメリットって何だと思いますか？ >>291
上のほうにも書いたんだがな。なんでそんな初歩的なことをなども聞くか。
教えてクンにもほどがある。だからオレオレオブジェクト指向論者はいちゃなんだ
クラスまたはインスタンスに、メソッドがスコープ付けられていること
これは
うまく使えばメリットがあるはずの
新しいことだったんだよ。 >>292
正々堂々と間違いを語られても（苦笑）
さっき俺がオブジェクト指向は関数を組み合わせる時の
（複雑性の）問題を解決するものだって言ったよね？
お前「メリットは、クラスまたはインスタンスに、メソッドがスコープ付けられていること」
お前「だがクラスまたはインスタンスに、メソッドがスコープ付けられていることに、メリットはない」
自分で間違ったことを言って、
自分の意見を否定してるｗｗｗｗ >>296
お前「メリットは、クラスまたはインスタンスに、メソッドがスコープ付けられていること
これは事実である。」
と言ったってこと？ １００パーセント中の１００パーセントオブジェクト指向!!! >>291興味本位へお答えしますが
>>292 で「うまく使えばメリットがある『はず』」って書いてあるでしょ。
そうじゃねぇ場合も出てきたってことなのよ。 >>292
スコープなんてやけに言語仕様に依存しそうな話が出てきましたね。
ためしに聞きますけど、ポリモーフィズムってご存じですか？先程、然り気無くポリモーフィズムの例を書いたのですが、何が言いたいのかわからんと仰ってましたよね？ >>299
そうじゃねぇ"場合"も出てきた ＝ そう（メリット）がある場合ももちろんある
こういう主張ってことでいいですか？ 本当のオブジェクト指向がどうたらいうの鬱陶しい
そんなもん共通見解も定義もありゃしない >>300
多態はなにやっているんだかぱっと見てわからなくなるから
上のほうでも書いたけど min max abs くらいにして
なるべく使わないほうが良いというのが最近の定説だと思うけど、
あの例は
…
の部分で内やってんだか分からんけど
共通関数かしたいのかな？くらいしかよみとれなかったがそれがなにか > 多態はなにやっているんだかぱっと見てわからなくなるから
お前の能力不足の話？
それともお前の周りが書いたコードの話？ >>202
>たとえば委譲した動的階層化データ構造の中の、ある局面で一見みえないメンバがどこか遠くで 定義され参照され更新され、、、
こういった状況に陥らないようにするのがカプセル化 多態は使わないほうが良いというのが定説
というのはどこで語られてるの？
いや、マジでないでしょ？ｗ
あるなら言ってみてよｗｗｗ
（個人ブログは定説とは言いません） >>306
ぶっちゃけたこと言います。
あなた、オブジェクト指向理解してねーですよね？ >>309
また変なのが湧いてきたけど、
アクセサとかmethod使ったらアウトでしょ > アクセサとかmethod使ったらアウトでしょ
それは、あなたの希望ですよねｗ >>312
>> 171
の
>(3)ポリモーフィズムが可能
>Storage s = new Usb();
>...
>s = new SDCard();
>
>SDカード・USBの違いを区別することなくアクセス可能。
>s.read(ファイル);
これのどこがポリモーフィズムのせつめいなの？
「違いを区別することなくアクセス可能」とかかれりゃ
同じ名前のmethodがあるのかな？
newして使いまわしてなにやりたいんだかわからん
くらいしか思い付かないぜ
だからながしたんだが >>316
あなた...Java案件をこなすときはって言ってましたよね...?
Javaプログラマーですよね？ オブジェクト指向って大まかにでも一言で説明できないような難解なものなの？ >>318
Usb()とSDCard()はStorageのファクトリーだって言いたいの？ >>316
オブジェクト指向を勉強したほうが良くないか？ｗ
ポリモーフィズムでその例を見せられたら、
ああ、SDCard型でもUSB（メモリ）型でも
どちらでも同じように扱える例だなって気づくでしょ？
それに気づいた上で、何かしらの意見を言うならわかるけど、
それに気づかないレベルって、単にオブジェクト指向を知らないだけだよ。 多態のデメリット
・メソッド呼び出し部分見てもどれが呼び出されてるのかわからない。
呼び出し先の処理は実際に実行するまでどれになるか不明。
・マシン語に展開したとき、処理が安全だといいづらい
必要もないのに処理の分岐先がデータと一緒に送られてきて危なっかしい。
動的に処理が決定されるというのは静的言語のメリットを殺してる面がある。
必要もなくすべてのメソッドが多態可能とか悪夢 >>150 で思いっきり社員のことを批判されてましたが、正直、あなたの実力が凄く怪しいです。
>>319
このスレ、オブジェクト指向を学ぶ人にとって毒でしかないので、Qiitaとかで検索することをオススメします。 >>320
お前が今言った「ファクトリー」はどういうものか言ってみ。
質問の意図は、お前が自身がお前の言った言葉を
理解してるかを確認するためね。 >>322
> ・メソッド呼び出し部分見てもどれが呼び出されてるのかわからない。
> 呼び出し先の処理は実際に実行するまでどれになるか不明。
実行するまで決まらないもの（例えばユーザーの設定によって決まるもの）を
実行する前にわかることってあると思うの？ >>324
フォローありがとう。
たぶん、私の想像しているファクトリーと違うこと言いそう...。 >>325
なんのために「お前が今言った」って書いたと思ってんのさｗ
ググって見つかる「ファクトリー」と
お前が言った「ファクトリー」は違うとしか思えないから、
「お前定義のファクトリー」を聞いたんだが。
お前定義のファクトリーはお前にしかわからん。
んで、お前定義のファクトリーはどういうものさ？ 俺のオブジェクト指向しかオブジェクト指向と認められていないよ >>326
ＩＦ文で分岐すれば少なくともその部分の処理は特定できる
多態したら実際の呼び出し先がライブラリ中に無数にある継承クラスのどれになるか
全部データから辿って判断しなきゃいけなくなるだろ
悪夢だ インスタンスの生成と処理を別のクラスで行うパターンのファクトリーとして書いたが。 > ＩＦ文で分岐すれば少なくともその部分の処理は特定できる
それだと、コードの中に全ての対応するモジュール名が記述されることになる。
それだと、外部プロジェクトで拡張するプラグインの仕組みが作れない >>331
このコードを見てそう思った？
インスタンスの生成はどのクラスで、
処理はどのクラスだと思った？
コードちゃんと読んでる？ >>322
ポリモーフィズムには動的なものだけじゃなく静的なものもあるよ
それはトレードオフの判断であって動的だから悪いってことではない >>332
だからって何もかも多態可能にする必要ないだろ！ そんな実装に密接した話してんのもなんか胡散臭ぇ
オブジェクト指向設計ではないのか？ >>333
それが隠されているように見えた。
両方Strage方を帰しているので
Superクラスが前後に略されているのかなとかチラッと考えた もっと具体的に質問しようか？
以下のコード、
>(3)ポリモーフィズムが可能
>Storage s = new Usb();
>...
>s = new SDCard();
>
>SDカード・USBの違いを区別することなくアクセス可能。
>s.read(ファイル);
登場人物は、StrageとUsbとSDCardしかいない。
質問１ インスタンスの生成を行ったのは、StrageとUsbとSDCard のうち
どれだと思ったのですか？
質問２ 処理を行ったのは、StrageとUsbとSDCard のうち
どれだと思ったのですか？
それそれ、3択の中から1つを選ぶだけの簡単な質問だよ。
（それ以外の答えがあるというなら、それで答えてもいいけど） >>335
> だからって何もかも多態可能にする必要ないだろ！
誰が何もかも多態可能にするって言ったんだ？ 設計の話してるときコードを出さないと話ができない人は
オブジェクト指向云々かんぬん以前にレベルが低いよ
そこはガチで低いはずなので素直に忠告を聞いてほしいと思う >>337
> Superクラスが前後に略されているのかなとかチラッと考えた
あなたが想像した「省略されてるSuperクラス」とはどのようなものですか？
”あなたが想像した"ものを聞いてるので
これもググっても出ません。 >>338
１）Usb();
2）SDCar(); >>340
ちゃんと理解してる人は、コードを出すことも出来る。
今は、ちゃんと理解してる人（俺なｗ）と
ちゃんと理解してない人の会話
ちゃんと理解してない人は「コードを出さないと話ができないレベルが低い人」なのだから
コードを要求することで、それがはっきりするわけよ。
俺がコードを出して話をしてるんじゃなくて、相手が理解してるかどうかを図るために
「せめてコードぐらいは出せるよな？ｗ」という考えで要求してるの >>343
ファクトリーは「あるクラス」を使って「別のクラス」を生成するということは知ってますか？ なんというか、もう、色々お察しがついてしまいました。
オブジェクト指向を否定的に捉える前にオブジェクト指向のお勉強をされることをおすすめします。
特に、Java、C#、Python、js等はオブジェクト指向のパラダイムを思いっきり取り込んでいるので、開発を楽するためにも、勉強をされることをお勧めします。 >>344
ちゃんこちゃんこうるせぇな
設計の話してるときにコード持ってくるアホなんて
まともな会社なら相手にしねぇよ >>347
質問に答えてよｗ
まあ想像できるから、さっさと追い詰めるけどｗ
>Storage s = new Usb();
>...
>s = new SDCard();
このコードはどう見ても、Usbクラス（お前がファクトリークラスだと思ってるもの）から
SDCardクラスを生成してません >>346
直訳すると
テメーは気に入らないからオブジェクト指向が理解できていない（認定）
ということでよろしいですか？ >>346
で、>>343 は違うの？
サンプルコードの前後が省かれていてよく分からんのに
いきなりポリモーフィズムとか言われて流したらなにがまずいの >>349
これ見て両方Storage返して
…のかなでUsb();の処理は終わって、
sをSDCard();で使いまわして
s.read(ファイル名)していると思ったが >>351
何がまずいって、ポリもーフィーズムとわかるのに十分なコードなのに
それがわからずにファクトリーを思い浮かべてしまったお前の頭がまずいｗ
どう見てもファクトリーのコードではないのに、なんでファクトリーだと思ったのか？ >>352
だから（ファクトリークラスを使わずに）sを使いまわしてるだけのコードですよねｗ >>353
周辺とか…の部分は
色々あると想像しろと
>>354
両方クラうでなくStorageを返しているじゃない 明確にしようとコードを出すはずだったのに目的も不明確なまま
デザパタ1パターンをオブジェクト指向の全てとしてコードをあげてしまって失敗した感じ？
な、コードなんて出す奴問答無用でバカだろ
テメーらは早く死ね雑魚 > 両方クラうでなくStorageを返しているじゃない
うん？ だから ”ファクトリーを使わずに" Storageを返してますよね？
今の焦点はなんであんたがファクトリーだと思ったかなんですが？ｗ このコードがファクトリーで最後にsリターンしてんじゃね >>357
正直言うとぱっと見たときは両方ファクトリかな？
と思ったが、戦後に何があるんだろうとも思った >>359
このコードはポリモーフィズムの例ですって書いたものを見て
これはファクトリーの例だなって思ったとしたら頭がおかしいｗ 今日もオブジェクト指向戦士は安定のバカだな
自分が何を主張しようとしてるのか全く不明 >>360
その理屈だと、
Interface i = new Klass()
というオブジェクトをnewするだけのよくあるコードをみたら
それは全部ファクトリだなとお前は思うと言ってるのと同じことだぞｗ
やっぱりファクトリーをわかってないｗ >>362
そう、だからすごい違和感があって流したんだよ >>365
その違和感の原因がなにかわかってる？
お前がポリモーフィズムをわかってないからだよ。
書かれたコードを見ても（俺はすぐに分かったが）お前はわからない。
わからない上に、どうてみてもファクトリーじゃないのに
ファクトリーだと思ってしまった。 >>351
ちょっとショックのあまりにいくつかスルーしましたが...
ポリモーフィズムというのは、Java案件をこなすプログラマーにとって常識中の常識だからです。Javaじゃなくても、現役C++、C#、Python、js等の案件をこなすプロがポリモーフィズムを知らなかったらビックリします。要はオブジェクト指向プログラマーの常識中の常識なのです。 >>362
Factoryパターンはポリモーフィズムを利用する最たる例だぞ >>366
まぁたしかに慣れもあるが俺はこういう書き方でポリモーフィズムを使ったことはないな
というか使わない そんなもんだよここはとくに3vnN9KRUが揚げ足を取ったり話を発散させるから
諦めが肝心だよ まず、持論を語るやつは
どういう手順で何を主張しようとしてるのか明確にしろよな
結局、相手の揚げ足をとりたいだけだったりしてすげーバカがいる 曖昧な言葉を使ったり、自分すら理解できない言葉を使うのはどうかと思いますけどね。
だから質問しまくる羽目になるわけで。 >>367
あの3行でSuperクラスの変数？にFactoryで生成したインスタンスを＝しているのかなとか
色々想像したことがそんなのおどろくべきなのか？ >>368
だから？
Factoryパターンはポリモーフィズムを利用する最たる例ならなおさら
このコードをファクトリーだと思ったなら、
ポリモーフィズムだって思うはずでしょｗ
実際はファクトリーじゃないわけだが >>375
あなた、もういいです。
自分の非を決して認めない人だとわかりました。
大体、オブジェクト指向のメリットって何と聞いて私の挙げたメリットを、それはOOPのメリットではないと言いつつ、メリットはスコープがーとか言い出す辺りで大分、不信感は抱いておりました。
現代における開発経験量が丸わかりです。 で、これも想像だが
@Override
public void read (…)
なんだろうな
人の頭の中のことまで創造させて、違う違う言ってたってしょうがないだろ >>369
つまりお前が言ってることはこういうことだよ。
お前「俺はこういう書き方でポリモーフィズムを使ったことがないから
これがポリモーフィズムだとわからなかった。」
そりゃ無知なら間違えても当然。
お前の問題だ。 そもそもポリモーフィズムってオブジェクト指向できたときに無かったよな？
それをメインに据えたい意図は何かあるの？ >>377
いやほんと、カプセル化を初めオブジェクト指向は害のある使い方が流布しているから
気をつけたほうがいいよ
有効な使い方に制限するのがなかなか難しい
>> 379
最初はホントに単なるファクトリに見えて、は？って思ったｗ >>369
> まぁたしかに慣れもあるが俺はこういう書き方でポリモーフィズムを使ったことはないな
じゃあ、どういう書き方でポリモーフィズムを使った？
コード書いてみてよｗ >>381
お前が一番、間違ったオブジェクト指向をしてるんだがなｗ 今日思ったこと
オブジェクト指向にはまるやつは大概頭が混乱してる >>382
だから多態はなるべく使わないって書いたじゃない。
スパークラスに共通のメソッドを書いてサブクラスでメソッドをOverrideとかは
必要な場合に使う
方がない動的言語では、それがそのまま多態になっちゃうんだけれどもさ >>386
自分が多態を使わない＝多態になれてないのに
多態を語るから、恥をかくんだよ
自分、多態よくわかりません。で終わっとけよｗ >>387
つかわねぇから語ってねぇってｗ
ホント妄想猛々しいな >>386
> スパークラスに共通のメソッドを書いてサブクラスでメソッドをOverrideとかは
> 必要な場合に使う
意味不明。必要がない場合に使うわけ無いだろ。
誰しも、必要な場合にしか使ってないぞ？
何を言ってるんだろうか >>389
いやいや機能上必要がなくても共通化の名の下
すごく乱用されている >>388
必要な場合には使うよね？
お前が言ってることは
多態が必要なときには使うが、
お前「俺の仕事では多態を使うようなことはしない」
って言ってるだけだろ >>390
> すごく乱用されている
お前の周りの話だろ？ｗ >>392
俺の周りは確かに一時期ひどかった。
今でも原理主義者がいる
その多OSSのコードも決して珍しくはない。
継承を多用したもののはひどいものが多い >>393
だから単にお前の周りが酷いだけじゃんｗ >>380
そもそも、最初のオブジェクト指向...アランケイの提唱するオブジェクト指向で、現代におけるオブジェクト指向とはまったく違う代物だったみたいですよ。
まぁ、この時代の事情はあまり知らないですが。
最近はオブジェクト指向の話題をする際にアランケイのオブジェクト指向を指す人はまず、いないと思います。
歴史的背景は私も詳しくはないですが...プログラミング言語の進化と共に色んな設計概念が増えていっただけなのかなと思います。
※勝手な思いこみ説明なんで間に受けないでね。
他にも良いオブジェクト指向向けの機能はあるので、メインなのかは疑問ですが...オブジェクトの使い勝手をより一層便利にするからじゃないですかね。 >>391
javaで多態はほんとにめったというかぜんぜん使わない
javaはまれにしかやらないけど、主にpythonなどが多いので
そもそも型がない
したがって派生クラスで上書きした共通関数使えば、
もうそれが多態といえるのかもしれないけど、
継承もなるべく使わない >>395
見たいじゃねぇよ、勝手にひとりあるきしまったく別物になった
メッセージ VS 型クラスとメソッド
全然別だよ >>396
だからさ、ちゃんと「俺は」って書いてくんない？
「俺は」javaで多態はほんとにめったというかぜんぜん使わない
「俺は」javaはまれにしかやらないけど、「俺は」主にpythonなどが多いので
「俺の世界には」そもそも型（Pythonのクラス）がない
したがって「俺の世界では」派生クラスで上書きした共通関数使えば、
もうそれが多態といえるのかもしれないけど、
「俺は」継承もなるべく使わない
お前の話なんか知るかｗ なんで私は噛みつかれたのでしょう( ;´･ω･`) 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↓ ↓ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/WTKeavj.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 こいつのせいで、Pythonに型やクラスがないと
勘違いされるのは困るから、ちゃんと書いておくな
Python チュートリアル
https://docs.python.org/ja/3/tutorial/classes.html
9. クラス
> Python のクラスは、C++ と Modula-3 のクラスメカニズムを混ぜたものです。
> Python のクラス機構はオブジェクト指向プログラミングの標準的な機能を全て提供しています。Python のクラスは、C++ と Modula-3 のクラスメカニズムを混ぜたものです。Python のクラス機構はオブジェクト指向プログラミングの標準的な機能を全て提供しています。
9.5. 継承
> 言うまでもなく、継承の概念をサポートしない言語機能は "クラス" と呼ぶに値しません。
9.5.1. 多重継承
> Python では、多重継承 (multiple inheritance) の形式もサポートしています。 別に噛み付いちゃいねえけど
オレオレオブジェクト指向論者は
メッセージやアクター理論などど型クラス＋メソッド＋継承のOOPSを
混同してむちゃくちゃな議論をするやからが多いから、ついかいた >>404
>オレオレオブジェクト指向論者は
>メッセージやアクター理論などど型クラス＋メソッド＋継承のOOPSを
>混同してむちゃくちゃな議論をする
でもオブジェクト指向は俺の股間に付いているだろう？ >>398
えー、お前のも一般的なの？
アランケイさんのお言葉
wikipediaより
すべてはオブジェクトである。
オブジェクトはメッセージの受け答えによってコミュニケーションする。
オブジェクトは自身のメモリーを持つ。
どのオブジェクトもクラスのインスタンスであり、クラスもまたオブジェクトである。
クラスはその全インスタンスの為の共有動作を持つ。インスタンスはプログラムにおけるオブジェクトの形態である。
プログラム実行時は、制御は最初のオブジェクトに渡され、残りはそのメッセージとして扱われる。
だってさ >>403
クラスはｱﾙさ、なに言ってんだ。
それからデータに型はあるさ
変数に型はないよ いれたデータに型が紐つく
そういう言語もいっぱいあって、C+＋やJavaninai柔軟性を示すんだよ
動的型付けってしなねぇのかよ
rubyではダックﾀｲﾌﾟとかいう >>406
上の方に書いたるだろ？
それは
> 現代におけるオブジェクト指向とはまったく違う代物 >>407
変数に型がある／ないことが
今の話にどう関係があるんですか？ >>410
上に書いたことでわかんなら
もうだまってなよ >>411
そんな事、彼に言ってもしょうがないでしょw じゃ、ポリオワクチン入ってるやつは
新オブジェクト指向って言えよ
アランケイのはじめのやつは
旧オブジェクト指向って言うか？ >>412
質問じゃないよｗ
変数に型がある／ないことが
今の話と全く関係ないです。と言ってる。
日本語通じねぇなこいつｗ >>415
1のテンプレがややこしくしているのが問題だと思う。 >>416
大いにあるよ。
変数に型がないから、何のインスタンス入れてもいいんだよ。
そのインスタンスが同じ名前・IFのmethodもってりゃ、javaのような多態が
意識しなくても自然に出来ちゃうって話だよ。
読み取れよ >>418
今度は多態の意味もわかってないのか？
多態は同じメソッドを持ってりゃいいんだよ
インターフェースは単に、ドキュメントで同じメソッドを
持つことと保証するかコードで保証するかの違いでしか無い。
同じように変数に型がないRubyでの多態の例な
https://docs.ruby-lang.org/ja/latest/doc/glossary.html
> ポリモルフィズム
> 多態, Polymorphism
> 対象になるオブジェクトによって実際の操作が決定されること。
> Rubyではレシーバのオブジェクトに応じ てメソッドが選択されることによって実現されている。
>
> * 例
>
> obj = "abc"
> print obj.length, "\n" # => 3
> obj = [1,2,3,4]
> print obj.length, "\n" # => 4 >>419
>>418 「インスタンスが同じ名前・IFのmethodもってりゃ…多態が…出来る」 「インスタンスが同じ名前・IFのmethodもってりゃ…多態が…出来る」ので
多態の話に変数に型があるかどうかは関係ない >>421
こいつこんなバカだとはうすうす気がついていたがｗ >>423
変数の型に使うクラスに制約ない？
動的型付け言語では、全然関係ないクラスのインスタンスが同じ名前・IFのmethodもってりゃいいんだけれど
Javaもそこまで柔軟？ ばかというか実際の経験がないんだろうな
文字で読んだうわべの知識しかないから
そこ間違えねーだろみたいなところでズレまくってて会話が成立しない > 動的型付け言語では、全然関係ないクラスのインスタンスが同じ名前・IFのmethodもってりゃいいんだけれど
> Javaもそこまで柔軟？
柔軟だよ。そのためにインターフェースがある。
全然関係ないクラスであっても、インターフェースを加えればいいだけ >>424
話がかみあわなくてさ、最初から揚げ足とり姿勢でつかかってくるし
あんま相手してもオレに得るものがなくて >>426
俺はオブジェクト指向スレで会話が成立したところを見たことがないな
お前が喋ってるのも新オブジェクト指向だしね >>427
なるほどね。でも「だけ」ってことはないでしょ
管理の対象になるわけだし 理論的背景皆無のIT界の新約聖書オブジェクト指向ファンタジーより情報理論学べよ。
お前らの無駄レス情報量ゼロだって分かるからｗｗｗｗｗ >>431
インターフェースを加えた上で、
同じ名前メソッドを加えるのも
インターフェースを加えずに
同じ名前メソッドを加えるのも
「同じ名前のメソッドがある」ことに変わりはない。
どちらにしろ管理の対象になる インターフェースも絡んできて、依存ネットワークを作っちゃうんだよな
本来の目的はFWなりライブラリの外向けインタフェースの提供や
実装の分離のはずだったのに、#includeや#defineがないものだから
中向けに定数の多重継承がわりに使われたり >>434
だから「俺は」を書けってｗ
インターフェースも絡んできて、「俺は」依存ネットワークを作っちゃうんだよな
本来の目的はFWなりライブラリの外向けインタフェースの提供や
実装の分離のはずだったのに、#includeや#defineがないものだから
「俺は」中向けに定数の多重継承をわりに使ったり 嵐が「嵐は去ったと知って」去っていったｗ
去ったのが嵐なのだろうｗ >>437
ﾊ,,ﾊ
（ ﾟωﾟ ) お断りします
／ ＼ お断りします
. ,､,,､ ((⊂ ） ﾉ＼つ))
(ﾟωﾟ) ｵｺﾄﾜﾘ- （＿⌒ヽ
((c'ｨ -､っ)) ヽ ﾍ }
s-= )ノﾍ) ε≡Ξ ﾉノ ｀J それが悪いことでほかに代替手段があるのに禁止されていないなら
それは言語の欠点だ というかだ
>>427で関係ないクラスにインターフェース加えりゃいいだけとかいっといて
俺はもくそもない
絶対おまえもやる >>441
インターフェースがないならないで、
どちらにしろ関係ないクラスにメソッド追加するんだろ？ そこまで無理をして多態を使わないようにするのがイチバン正しい >>443
メソッドがある時点で依存してるじゃん
何いってんの？ Staticメソッドにしてクラスと別に定義すればクラス自体に新しい依存はできないよ >>445
それに加えてグローバルな依存ネットがプラスされて雲の巣状態になるんだじゃよ >>446
もしかしてあるクラスに○○のためのメソッドがあっても
使わなければ、ごみがあるだけとか言ってる？ >>447
だから「俺は」を書けってｗ
それに加えて「俺は」グローバルな依存ネットをプラスするから
「俺が書くと」雲の巣状態になるんだじゃよ また妄想でミスリードして話を明後日の方向に発散させる… なんか、お疲れ様です...。
私はもう、OOPを理解させるのは無理だと悟りました。 >>449
一派論です。ｷｯﾘ
ﾊ,,ﾊ
（ ﾟωﾟ ) お断りします
／ ＼ お断りします
. ,､,,､ ((⊂ ） ﾉ＼つ))
(ﾟωﾟ) ｵｺﾄﾜﾘ- （＿⌒ヽ
((c'ｨ -､っ)) ヽ ﾍ }
s-= )ノﾍ) ε≡Ξ ﾉノ ｀J >>452
させる」とかいう以前にもう少しソフトウエアの勉強を 宗教みたいなもんだからな。
リアリストに神の存在を認めさせるようなもん。
教会に籠ってろｗ まぁ、彼らはOOPがクソだと思いながらOOPの勉強を避けてコードを書けば言い訳だし、
私はOOPのコードを書いていく。
これでいいかと思いました。
ただ、このスレタイは初心者に毒なので勘弁してほしい。 つまり「神の存在を認めぬ不信心者め！地獄に堕ちるぞ！」
ｗｗｗ >>457
いいえ？
あなたは既に地獄へ堕ちているのでは？
このご時世にOOPを目の敵にしている人の実力なんてお察しです。
むしろ、あなたみたいな人はOOPを学ばないで下さいね。
見せしめになってほしいので。
是非、たっぷり苦しみながら開発をしてくださいませ。
まぁ、台風が去ったらこのようなスレには二度と来ないので、どうぞ傷の舐め合いでもしててください。さようなら。 俺にとっては、あるクラスのメソッドの仕様を変更した時、
同時に変更しなければ動作不良になる、他の部分のことを依存してるコードっていうんだが、
インターフェースがなければ、依存しないという理由が知りたいわ 恐らく彼の職場では責任範囲の概念が無いんだと思う
他人が書いたコードだろうが変数の動きを端から端まで追いかけて責任持たなきゃいけない
そうなるとコードの再利用をむしろ減らした方が効率が上がる 三連休の夜はまだあるぞ
納得するまで議論つづけろよ >>465
「私はCが嫌いだ。」 と書いてあるのはサイトの著者の好みだろ。 >>468
それ、長くて読めないですよ…
Linus の要約は次のとおり
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 >>468
で、この人はどんなすごいプログラマーなの？ｗｗｗ linus を知らないなんて、最近の若者は怖いもの知らずなんですな… >>472
ホンモンのバカかお前。>>468読めや
そのlinusへの反論をlinusがすんのかマヌケ >>469 出てきたなQZめ
そのLinusの意見はよほどいやな目に合って腹が立っ手いたのか、
内容が少し感情的に見える（もともとそういう口の悪い人らしいが）
もう少し理論的技術的に批判した方が良かったんじゃないかと思う。
それから、知っている人もいると思うが
Why do some famous programmers (e.g. Richard Stallman, Linus Torvalds, Ken Thompson, and Brian Kernighan) dislike C++? What are the alternatives?
https://www.quora.com/Why-do-some-famous-programmers-e-g-Richard-Stallman-Linus-Torvalds-Ken-Thompson-and-Brian-Kernighan-dislike-C++-What-are-the-alternatives
Goは、C++やJavaのOOPSじゃだめだとThompson やRob Pikeらが考えて
開発することになった言語であることは、ご存知の通り
Linus Torvalds thinks Java and C++ are horrible programming languages. So, which language does he recommend for programming?
https://www.quora.com/Linus-Torvalds-thinks-Java-and-C-are-horrible-programming-languages-So-which-language-does-he-recommend-for-programming
この辺も面白いかも
俺は縦読みした程度だが １．Object Oriented Programming is a Cargo Cult.
まったくだ たて読みしたら、
オ
ブ
ジ
ェ
ク
ト
指
向
は
ク
ソ
って書いてあったよ… >>473
失礼、>>468 は linus への反論でしたか ぶっちゃけC++の批判とオブジェクト指向の批判は違うもの べつにオブジェクト指向じゃなくてもＩＴは大体カーゴカルトだと思うけどな 俺としては有名人がC++, Java, OOPに批判的か否かはそれほど重要ではないけど
>>458
>> このご時世にOOPを目の敵にしている人の実力なんてお察しです。
> むしろ、あなたみたいな人はOOPを学ばないで下さいね。
> 見せしめになってほしいので。
こんなこと言われると、つい著名人の考えを引用したくなっちゃってさ >>481
それは一理ある。
極端なGOTO排除、AI、ビッグデータ、IoT
ファージ、Byte/Flops、そのた…
がしかし、OOPS宣教師の及ぼした害は広く根が深い >>480
別に苦しくないよ。Linusが言ってるじゃん
STLやBoostはだめだって。
C++以外にSTLやBoostはない
それに、Linusは
> Cでオブジェクト指向コード（ファイルシステムとかだと有用）を書くのは可能だし
と言ってる。 >>484
でも主張を見る限り
オブジェクト指向自体を嫌ってるよね 実際問題、「オブジェクト指向」で作ってたとしても
機能や実装の説明において「オブジェクト指向」という言葉を使わない方が
誤解が少なく有用な説明になる。
そういう意味で「オブジェクト指向」って言葉は有害なだけ。 Ｃがもうちょっと型付けが強くて
関数とかポインタとか細かい部分の記法がこなれていたら
世界はこんなに複雑じゃなかったんじゃあるまいか オブジェクト指向七不思議
①オブジェクト指向の定義
→議論の最後はいっつも「お前はオブジェクト指向をわかっていない!」
そんなやつとハナから議論すんなと
②オブジェクト指向のメリット
→イマイチ納得できる数字が上がらないのとメリットと言えるロジックが出ない
③オブジェクト指向言語とのリンク
→どんな思想でこの機能が追加されたのか？オブジェクト指向にそんなのねーじゃん
④オブジェクト指向って流行ってる？
→これ流行ってるの？誰も話題にしてる奴がいないような気がする
⑤オブジェクト指向の歴史
→志村なのか相撲のトークなのかアランケイなのか
⑥人によって言うことが変わる
→決して一つとして同じものがない、もう、宗教である
⑦誰もその効果を検証しない&できない
→やっても「お前のはオブジェクト指向ではない!」って言われる。酷い
⑧死ねよ
→もう死ねよ オブジェクト指向七不思議
①オブジェクト指向の定義
→議論の最後はいっつも「お前はオブジェクト指向をわかっていない!」
そんなやつとハナから議論すんなと
②オブジェクト指向のメリット
→イマイチ納得できる数字が上がらないのとメリットと言えるロジックが出ない
③オブジェクト指向言語とのリンク
→どんな思想でこの機能が追加されたのか？オブジェクト指向にそんなのねーじゃん
④オブジェクト指向って流行ってる？
→これ流行ってるの？誰も話題にしてる奴がいないような気がする
⑤オブジェクト指向の歴史
→志村なのか相撲のトークなのかアランケイなのか
⑥人によって言うことが変わる
→決して一つとして同じものがない、もう、宗教である
⑦誰もその効果を検証しない&できない
→やっても「お前のはオブジェクト指向ではない!」って言われる。酷い
⑧死ねよ
→もう死ねよ オブジェクト指向七不思議
①オブジェクト指向の定義
→議論の最後はいっつも「お前はオブジェクト指向をわかっていない!」
そんなやつとハナから議論すんなと
②オブジェクト指向のメリット
→イマイチ納得できる数字が上がらないのとメリットと言えるロジックが出ない
③オブジェクト指向言語とのリンク
→どんな思想でこの機能が追加されたのか？オブジェクト指向にそんなのねーじゃん
④オブジェクト指向って流行ってる？
→これ流行ってるの？誰も話題にしてる奴がいないような気がする 対象ドメインと自分たちの思考パターンに適した言語やパラダイムを選べばいい
状況に応じたトレードオフを判断できず
選択の間違いを言語やパラダイムのせいにしてる人は成長しない >>485
ん？Javaも嫌いって？
やっぱりオブジェクト指向じゃないんだねｗ >>490
>①オブジェクト指向の定義
>→議論の最後はいっつも「お前はオブジェクト指向をわかっていない!」
オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
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 上のURL一式
テンプレにでも入れときやがれってんだ
ﾊｹﾞどもが オブジェクト指向とオブジェクト指向プログラミングは全く違うよ？
>>496
>※俺もこのサイトを見るまで、まさかここまで沢山の著名人がOOPを批判しているとはしりませんでした
オブジェクト指向は俺の股間に付いているが、オブジェクト指向言語はプログラミングの形式に過ぎない！ 自分の考えに近いなと感じたのが
Paul Graham (2003)
Richard Mansfield (2005)
Eric Raymond (2005)
Eric Allman (2011)
など >>486
>でも主張を見る限り
>オブジェクト指向自体を嫌ってるよね
いわゆる『オブジェクト指向プログラミング言語』とやらは、オブジェクト指向を表現していないからな。
例えば『チンポがしこしこする』ってのは、オブジェクト指向言語プログラミングでどう表現する？ オブジェクト指向は俺の股間に付いているのだから、オブジェクト指向プログラミング言語は必要無い！
>>496
>※俺もこのサイトを見るまで、まさかここまで沢山の著名人がOOPを批判しているとはしりませんでした
それでもオブジェクト指向は俺の股間に付いている、違うか？ >>496
コメント欄でOOPいやPOO信者が火消しに必死ｗｗｗ >>502 この人？
ttps://c.disquscdn.com/uploads/forums/294/4852/avatar92.jpg Dunets Nickolay a year ago
One more for the list.
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
OO sure promised a lot in the early days. And these promises are still being made to naive programmers
sitting in classrooms, reading blogs and taking online courses. It’s taken me years to realize how OO lied to me.
I too was wide-eyed and inexperienced and trusting.
強烈な意見！ >>505
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
このサイト読むと
何十年もの間、Smalltalk、最後に.NETとJavaと、オブジェクト指向言語でプログラミングを行って
継承、カプセル化、および多態性の利点を活用するために熱心っだったけど、だまされていたって
懇々と唱えてきて、ホント気の毒
俺から言わせてもらえば、そんなに年月をかける前に
これは変だと気がつけばよかったのにね The problem with object-oriented languages is they’ve got all this implicit environment
that they carry around with them. You wanted a banana but what you got was a gorilla
holding the banana and the entire jungle.
もう爆笑ｗ >>508
ちな、これ、Erlangの作成者Joe Armstrongの発言ね。 まぁ、bBavR94N のような奴はOOPが廃れたら、
また別の流行見つけてそのカルト信者になるんだろうね
それはあんたの人生の選択だし、どんなに頓珍漢な迷信であっても
回りに迷惑かけない範囲で好きにしてくれ どんな迷信染まっても
周りや他人に迷惑は絶対かけるなよ
いいな。 で、結局オブジェクト指向は素晴らしいの?
そうじゃないの?
代替案は何? >>512
普通に組むんだ
機能一覧
→各機能の処理一覧
→それに対応する関数一覧
と作成して関数一覧ができたら設計は終了なのさ
それ以上はプログラマ側では何もすることがない
これでプロジェクトがうまく行かないならそれは仕様の決定段階ですでにおかしいのであって
もし、自分が改善したいと思うならば積極的に仕様の決定まで口を出さなければならない >>516
なんでオブジェクト指向は、それらの関数を
組み合わせて使う時の問題を解決するものという
レスを無視するの？ 処理をまとめる→関数
関数の第一引数でまとめる→クラス >>516
複数の機能から使う共通のデータや状態、それらの制約や整合性をどう維持するか
という部分が単純な機能分解ではカバーしにくいところ
その問題を考慮したのがDOAやOOAD
A形式のファイルをB形式に変換するとか
Aというシグナルが来たらBの状態をB'に変更するとか
そういう段階まで分解してくれた仕様だけ考慮すればいいなら
単純な機能分解が適してる >>517
別に必要ないだろｗ
関数一覧の関数それぞれ組んできゃ終わるんだからｗ >>519
いらないいらない
関数一覧の関数は全部独立してるものと仮定して組んでもいいのよ
っていうかそれで動くんだから余計なことすんなよクソ虫 >>524
書いてるやつもここのとどっこいだぞ
なぜなら万人が認めるオブジェクト指向はこれですって言える資料がこの世にないので
しかしこの業界なんでこんなんになっちゃったかなぁと
プログラミングとは目標を実現するための1つの手段という位置付けに留めて置いたほうが
結果的に実力は付くよ
プログラマはこのクソ宗教のせいで多くのやつが視野狭窄過ぎて参考にならない 別に、機能別にライブラリにして行けばいいのさ。
かしこまってOOPだなんだとギスギスする必要は無い。 >>522
小さいプログラムならそうだけど
GUIアプリとかウェブアプリでそんないきあたりばったりな
コード書いてるとすぐに破綻する。
設計が必要。 ワイもそれ思った
業界を語るわりに経験が感じられない >>527
違うな
どんなデカイプログラムも分割すれば小さい単位になる
そしてなってしまえば後の作り方はおんなじや
違うのはヘタクソだからや 俺に反論するなら
じゃあ、デカイプログラム特有の仕組みは具体的に何があるの？
って聞くぞ
調べてから書き込めよ >>529
その理屈だとどんなでかい建築物でも分割すれば
小さな家となる。そうなってしまえば、
高層ビルでも犬小屋でも作り方は同じってことになってしまうぞｗ >>530
> デカイプログラム特有の仕組みは具体的に何があるの？
小さな単位を組み合わせる仕組み。
例えば、モジュールをプラグイン化し、
本体に手を入れずに拡張する仕組みとかね WindowsとかLinuxとかのOSはでかいプログラムの代表例だが、
コアの部分は小さくして、ドライバにより多くのハードウェアに対応してる。
こういうところにオブジェクト指向による設計が使われてる。
C++を批判してるLinusでも
https://cpplover.blogspot.com/2013/05/linus-torvalsc.html
> Cでオブジェクト指向コード（ファイルシステムとかだと有用）を書くのは可能だし、
Cでオブジェクト指向はファイルシステムなどで有用と言っている。 >>531
プログラムには重力ねーし
そういう構造いらねーから >>532
機能一覧に入ってるんだよな？それ
関係ねーじゃん >>533
c言語の機能を使ったときだけうまくいくってリーナス言ってんじゃんｗ >>537
敗北だと自覚してるから、そういう書き込みしたくなるんやでｗ C以外糞って言うならならPythonもゴミじゃん。
Pythonしか書けない奴はどうなるの？ × オブジェクト指向は組み込みとすこぶる相性が悪い
○ オブジェクト指向言語は組み込みとすこぶる相性が悪い
オブジェクト指向であれば組み込みでも使われてる。 オブジェクト指向とΣ計画はセット
資本主義社会じゃ無理
言語製作者陣の理念と現状にズレがあるので、オブジェクト指向が使いにくくなっているだけ
カネと労道の壁を突破してありとあらゆるオブジェクトを集積するセンターがあれば完璧になる >>533 印象操作しないで ちゃんと引用しろ
> Cでオブジェクト指向コード（ファイルシステムとかだと有用）を書くのは可能だし、
> しかもC++のような余計なクソがついてこない。 >>533
> Cでオブジェクト指向コード（ファイルシステムとかだと有用）を書くのは可能
これどういうコードを指すのか分かっているのか？
教えてクン卒業して一回見てみろ Linuxのファイルシステムのコードを見れば
（C言語によるオブジェクト指向コード）がわかるのでは？ 何かを作り上げるのは向いてないな
作ったものを綺麗にディスプレイするのには使える
まあ 数学の公式みたいに絶対に変更しないって
条件では使える ただそうなることは無いｗ >>531
プログラムには重力掛からないから、どんなに大きなプログラムでも大きい事で特別何か対策しなきゃならないって事は無いよ。
まあ、大規模なプロジェクトでは人間同士のコミュニケーション不足やトラブルはあるけどなw まあよくある話、
AはBの理由や懸念があるからDの方法は不適切なのでCの作りとする
なんてルールがいつのまにかAはCの作り方にするってだけ伝わって、
なんでAがCみたいな面倒くさい作りにするんだよ、Dの方が簡潔で分かりやすいだろ。なんて勝手に解釈変えられて
結果的に機能を満たさないものになるなんて事はよくある。 >>551
> どんなに大きなプログラムでも大きい事で特別何か対策しなきゃならないって事は無いよ。
大きいプログラムは、小さく分けるという対策をしなきゃならんよ。
小さく分けるということは、組み合わさなければ動かなくなる。
つまり組み合わせるコードが必要になるんだよ >>554
>大きいプログラムは、小さく分けるという対策をしなきゃならんよ。
チンポは独立した生き物であり、チンポはチンポ独自の知能回路を実装しておかないとな！ UNIXが、あれはあれで一つの大規模なシステムと考えても差し支え無いものだったよな。
ひとつもオブジェクト指向になってないんだけど、簡潔なルールのもとに各自必要な処理を追加していた。 UNIXがオブジェクト指向でないと考えるのは、
C言語がオブジェクト指向言語じゃないからというだけ？ 人が作ったものを使うだけならすごく便利
ただ作り直そうとするときつい
pythonのライブラリとかよくわからんまま
使う分には便利 オブジェクト指向なんて考えが生まれる前からあるからさ。 オブジェクト指向なんてホントは主目的じゃないけどね
クラスを幾段も連結できるオブジェクト演算子ができてから
それの使い方の総称になっただけ 小説で言う「起承転結」のようなもの
大まかにそういう考えにしましょう。という設計で
それに従わなくても良いものが作れないことはないが、
だいたいは従ったほうが良いというものだよ おまえら頭悪いんだから、いっぺんにまとめて考えないで
なるべく小さな単位にして分けて考えろやって話だからな
その分け方の方法のひとつがオブジェクト指向ってだけ。 オブジェクトのメリットは単純に
補完が効くとこだな 設計思想云々は
どうでもいいがこれは便利 受け身でコーティングできるのがいいんだろ？thisポインタ受け取ってさ
それ以上の意味はないよ
イベント駆動とGUIと人間の汎化の理解がマッチすると気持ちいいくらい
マイクロソフトでさえ糞クラス設計するのに、専門卒Ｆラン大卒が何を言っても無駄 Unixはコマンドをパイプでつなげて処理をするところがオブジェクト指向っぽい
コマンドとコマンドは標準入出力によってつながるわけだけれども
そのことは重大な事実を示唆していてオブジェクトとオブジェクトを
つなげるインターフェースはシンプルな程よいってこと C言語で書かれたプログラムでオブジェクト指向っぽいと思ったのはqmail
ファイルが細かく別れていてファイル内でしか参照できない変数や関数が全体の半分を占める
ファイルごとにテストできそうだなーって思った
qmailはバグが少なくて信頼性が高いことに定評がある
オブジェクト指向をうまく使うとそういうことも可能ではあるけれども
業務システムではなかなか難しいところがあって
業務要件はころころ変わるけれども既存のプログラムはできるだけ変えないって
圧力がかかって継ぎ接ぎだらけのハウルの動く城みたいなうごめくオブジェクトの塊ができあがる
既存のプログラムを変えない圧力から逃れるためにテスト駆動開発などで
テストを整備して継続的インテグレーションで自動化するみたいなことが流行ったんだろうね
テスト容易性でオブジェクト指向の良し悪しを判断するのはありだと思うなど >>566
そうでもないよ。
パイプでつなげるとデータの区切りをどうするか？って問題が出てくる。
たいていは1行1データでいいんだけど、データの中に改行が入る場合
どうするか？って問題が出てくる
改行コード以外の文字を使うという方法もあるが、じゃあその文字が
データの中に含まれていたら？という話に変わるだけ >>566
パイプは関数型を想起させる代表例だと思うんだが
テキストという共通のデータフォーマットを入出力に使って
処理のパイプラインにデータを流していってる
シェルスクリプトの場合は
汎用的なテキストフォーマットで型がないから
各処理の内部で毎回パースが必要になったりもするし
コマンド間の依存性を下げて疎結合にするのはかなり難しい >>568
改行よりも EOF の方が問題だと思う Unixはパイプを多用するからオブジェクト指向とは真逆っていうのは俺もそう思う
だからjqみたいなむりくりなツールが必要になる パイプを多用すること自体は関係ないよ。
オブジェクト指向でもパイプを使うことは出来る。 Unixのパイプはテキストとして行ベースで処理するから階層構造を扱えない Windowsの場合、システム管理にWMIオブジェクト使うのでPowerShellのパイプがオブジェクトを通すのは理にかなってる Class A a, Class B b, Class C c があって
c = a + b #共通コード
と書いた場合、C言語の
c = 1.0 + 2
みたいな暗黙の型変換をしてくれる場合はコードの共通化がスムースに行けると思う
実際は...
Class A a,b,c #or Class B a,b,c
c = a + b
こんな感じで '+' の定義があれば行ける
たぶんClass の階層構造とタイプしたコードの振舞いここら辺の認識に錯乱が起きて
秩序なき構造を待つClass が記述できる結果オブジェクト指向の概念の考え方に混乱が起きている
CもC++も副作用に対する制限が弱めなので
挙動もプログラムの構造も発狂混乱混沌を含んだものが容易に出来上がる
解決策は、～～ツクールで定義したものをC++等のコードで吐き出して
必要に応じ手を入れるじゃないかな
アセンブラで複雑なプログラム何て書かないよね、同じちゃう？ >>579
java みたいに演算子のオーバーロードを許さない！というポリシーはいかがでしょうか？ >>580
java の演算子 + - * / 等算術演算子
ググって調べました(汗
C++ は演算子の再定義が可能で + - * / も出来る様だね
演算子の再定義は計算式の意図や意味の直観的認識を保障している
a = b + c で
int a, b, c であっても
Class XY a, b, c #2次元座標
であっても+ - * / が座標の移動や拡大縮小(スケーリング)な事を直観的に理解させることになる
ぶっちゃけ演算子のオーバーロードは習慣的な慣れ親しんだ記述でコードを読み書き抽象化したいそれだけの事
java の許さない！なポリシーは、アルゴリズム＝コード を抽象化共通化したい場合
記号で書くな正式なメソッド名を決めてタイプしろって事
偉そうに書きこしてるけどjavaもJavaScriptもTypeScriptも厳密には確認してないからな
で、C,C++のバグの原因はアセンブラに近い危険なコーディングが出来ること以外に変数スコープの関係で
もしかすると単純なタイプミスでグローバル変数が壊せたり
自己責任な処理系なので当たり前に検出困難なバグが入る 偉い人は言いました、本物のプログラマはfortranとコアダンプだけで書くと だな
コアダンプを書くとは言ってないしそのとおりだな
さすがだな コアダンプは吐くものでも無くて吐かれるものだからな
喰わせたモノが余程ヒドい時の嘔吐物だから 吐くっていうのは人間がやることに対して使うんですよ！
人間じゃないのに、人間がやるような言葉を使ってはいけません！ ここで書き込みされてる方って人間じゃなくて人工知能？ つまりオブジェクト指向とは、俺の股間に付いているモノなのである！
. , ｬ ｨE5!..
.. ,,.e;〆 .、 w===|====!. π .e､ｘ＆
.. ^~ ！ ``= π ,, ｶ. _ _￣ｵ⌒|! `ﾍ
. fラ⌒￣l｢~~~＾. ,.ﾀ. .ﾙ .ll ~＼_ 〃 〃. ＾..
. .ｵ.. ,...＿_,xｆ~. ^ f! ､
. '^´ ￣￣..
．. l|.. ｒ=キ'⌒..
. `!、 ~~~~~~⌒... l｝
⌒ｈeィ~. .+ｓ_、_e. .＾+--w=ｆ `ｦse､._ _、... ′
チンポは独立した生き物であり、本人の意思とは無関係に、自らの意思で勃起してシコシコする！ >>589
2ちゃんねるって何でもかんでも話題逸れていくの昔から不思議でたまらなかった
オブジェクト指向の解釈が二十年以上収斂しないなんておかしい チューリングテストは合格だよ。ここまでおかしくならないとわからない 何冊か本読んだけど、結局、「オブジェクト指向には明確な定義が無い」
ってことが分かっただけ。
当然だよな。
プログラミング構造としては、アセンブラでもマクロ組めば同じことができる。
結局は、単なるコードの可読性やメンテナンス性の向上が、
新しい「質の変化」として宣伝されただけのシロモノ。 >>595
>何冊か本読んだけど、結局、「オブジェクト指向には明確な定義が無い」ってことが分かっただけ。
ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ ならば質の変化がオブジェクト指向と結論が出たわけだな ちんぽがしこしこ、そんな言語表現あるのか？
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ オブジェクトの和訳は目的語でいいというのが、個人的な結論 やたらエロ広告あるのは、フィルタリングさせるためか
青少年はアクセスできない >>596
>>600
自分のようなアホに返信ありがとうございます。
胸は異常を自覚症状として脳に伝達できるが、チンポは常に受身。
教えていただいた著者も読ませてもらいます。 >>604
>クルマに例えてくれ
この車、タイヤがパンクしてるぜ！
この俺、チンポがシコシコしてるぜ！ 「オブジェクト指向」とは、デジタル土方に仕事をさせるための知恵です。
例えば、「この変数は読み出し専用と仕様書に書いただろうが。勝手に
書き換えるな」と土方に言っても仕方ありません。読み出し可能だが、
何をやっても書き換えることを不可能にすることで、土方を働かせる。
そのために「オブジェクト指向」があるのです。 筋肉バカにはスポーツを
低学歴オタクには最新機能wを
与えておけば、飽きずに追い続けるだろ >>606
それはJavaとかいう土方作業用の言語の話な 問題を切り分け整理し類型を見つけ出すことで科学は進歩してきた
それはまさにオブジェクト指向の遠大な理想なのだ やがて人々は問題から目を背けオブジェクトを分割する手法のみによってプログラムを書き出した
オブジェクト指向によって無駄に複雑なプログラムが量産されるプログラム暗黒期の到来である
90年代はそんな感じだった オブジェクト指向が普及したことによって直感的なプログラミングが可能になっただろ プログラムを一行も書けないウンコSEでも
それっぽいキーワードを並べれば馬鹿を騙せるようになったのが
オブジェクト指向の功績だよ 逆じゃねーかな
オブジェクト指向が普及したことで
コードの書けないSEはSE様からSE(笑)になり
設計のできないプログラマー(=コーダー)は淘汰され
設計も普通にできるプログラマーの地位は上がった
職場によるのかもな プログラムの規模も数も激増した
質も押し並べて上がった
すべてオブジェクト指向の功績 シンプルにインテリセンスが使えるのは便利
それだけだな 後、頭いいいやつの思考が
分かりやすいぐらいだな >>612
これだな。
というか、このメリットが活かせないのにOOPとか、神クラスの予感しかしない(恐怖)。
神クラスというのは、OOPでやっては駄目なパターンね。 typedef する文化
typedef int width; // 幅を表す型を定義
width square_width; // int square... と同等
こんな感じで変数の型にtypedefで別の名前つけて統一的に管理する
この習慣がないとオブジェクトの設計とネーミングが苦痛だと思う
最近C++でtypedefしろtypedefしろって言われて調べたら目からウロコだっと
typedefの習慣すらないのでclass,objectとか言われても混乱する
適当にコーディングする時、一々typedefなんてしないし、その延長線上にあるclassのデザインもネーミングも適当
結局、ガッツリ設計して適切なネーミング他でしっかりした管理メンテナンス体制にする場合
オブジェクトなりクラスなりが便利なのであって
適当な書き捨てコードだと苦痛なんじゃね？
クソはお前(自分)だ、かな typedef int height;
height square_height;とするの？
それともwidth square_height;とするの？ >>620
書き捨てコードでもクラスは便利だよ
「関心の分離」がやりやすいからね
そもそも、typedefする文化って何？
typedefは便利だけど、乱用するとわけが分からなくなりそうだがなぁ >>621
こっち
>height square_height;
なんか面倒くさくて信じられんだろ？
オレはなんだこれ、ムハ～とかなった
もしかすると
typedef int width;
typedef height width;
みたいに並べて書くのかも知れない
コードの全体の規模が大きい場合typedef int widthを
typedef long long width
とかして扱うレンジを拡大したり
>>622
扱うプログラムの規模次第なんだよ
短いコードだと一々typedefなんかしないよね
だからtypedefする習慣は知らなかった
恐らくtypedef する習慣とテンプレート機能は親和性が高い >>623
typedef int width;
typedef width height;
微妙に間違えた そんなtypedefすんな。
typedefするのは単位系で纏めろよ。
同じ単位系なのに別々にtypedefしたら
扱い辛くて仕方ないだろ。 typedef mytype int;
typedef はいつも順番と;で叱られる。 widthやhightは、長さなんだから同じ単位系。
三次元の仮想空間の単位系か実世界の物差しの単位系かで分ける。
だから同じ変数名でも更にそれらを構造体やクラスで包める。 おまえら、ここのスレタイ100回音読してやり直せw 785 名無し三等兵 sage 2019/12/03(火) 08:03:27.78 ID:sujZBpWD
>>762
＞「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！
チンポにチンポ自身を扱く機能が備わっていないので自動詞は不適切だから（34文字）
胸（心臓）には鼓動する機能があるため自動詞の適用対象だが
チンポには勃起する機能はあっても自身を扱く機能はないので「チンポ『が』勃起する」は成立しても「チンポ『が』シコシコする」は成立しない
夢精した状況を「チンポ『が』シコシコした」と称したければ「チンポがエロい夢を見させ夢精した」＝「脳ではなくチンポが思考を司りエロい夢を見させて夢精させた」という状況で可となる
脳でなくチンポで物を考える生物についてなら「チンポ『が』シコシコする」は成り立つ
如何にもだつお的じゃないか >>625
だから単位系を含め整理整頓してtypedefする習慣がないと
classのデザインや命名規則で躓いて苦労するって話です
クソクソではない以前の問題
classのデザインそのものがある意味typedefなので オブジェクト指向というのは要するに構造化の延長であって、現実世界のオブジェクトと対応させる必要はない
グローバル変数(構造体)に名前空間を与えて関数とセットにすることでモジュール化を進めたものがクラス
要はオブジェクト指向っていう名前は無意味で、あくまで「機能ごとに関数を分割する」っていう手続き型プログラミングの原則を変数にもあてはめたものが今オブジェクト指向と呼ばれてるもの 同じ機能に同じ名前の原則は似たような処理をまとめて扱う事が出来て便利だし、いちいちクラス内をリファレンスする必要が無いからなぁ
テンプレートの功罪はさておき、ひとまとめできるのは何かと便利。 だが、オブジェクト指向の設計に馴れていないと一つのクラスにあらゆる機能をまとめ、クソみたいなクラスができあがるから注意が必要。
ま、これはオブジェクト指向がクソというより、勘違いオブジェクト指向プログラマーがクソなだけだが。 >>13
チンポ「を」しこしこするのではなく、チンポ「が」しこしこする。 >>633
まあそれはオブジェクト指向にかぎらんよな
構造化プログラミングでも、多機能クソデカ関数作る奴はいる オブジェクト指向でまとめのクラスはどのように考えてるんだろう？
どうしても巨大クラスにならないか？ >>637
責務単位で分割しているから、責務以上にクラスが巨大化することはないな。
初心者時代は責務そのものを巨大化させて、いつの間にか神クラスを作ってしまった...ということはあったけど、今はそんなことはない。
ソフトウェアの多機能化と共にクラスそのものが増えていくだけ。 クラスだろうが関数だろうが、手に余るほど巨大に成長したら分割統治だべ。 メソッド間である種の依存ができるということに対する意識が低くなる傾向にある。
だからクラスでなんでも抱えるようになる。
それだったら構造体のがマシ。
少なくとも解きほぐしやすい状態なことが多い。 クラスの数が死ぬほど増えた場合
それを管理して見通し付けやすくするのは何を使うのがいいんでしょうか？ その時褐色巨乳エルフのアナルフィスト的なクラスがあったとして
褐色なのか？
巨乳なのか？
エルフなのか？
アナルフィストなのか？
で迷った末に作成日付で
分けることにしたら
思ったよりうまく分けられた
作った順に並べるのは
機能の上位下位がわかって
実はすごく読みやすい >>641
だいたいどの言語にもモジュールやパッケージって名前のクラスをまとめる概念があるやろ >>637
まとめのクラスは「まとめること」だけの機能とすることで巨大化することはなくなるよ
そういうクラスは逆に、すごく小さいクラスになりがち >>645
それは、非OOPのやり方ね。
巨大化したら分割はその通りだが、「どのよう分割するのか」はOOPと非OOPで違いが出る。 クラスにはインスタンスが1つしかないクラスと複数のインスタンスが生成されるクラスがあるが、この2つには本質的な違いがある
前者は「一つの機能を実現するモジュール」として『関数+グローバル変数』をまとめたもの
後者は先にデータ構造があり、『構造体+それを操作する関数』の組み合わせ >>187
>これが抽象的過ぎてわからん。
>なんで、毎回曖昧な表現使うかな...。
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く >>648
オブジェクト指向とは、独立した知能回路のことなんだが？ 生物学的にはネコ目の下にイヌ亜目がある
イヌはネコだからそれは正しい >>650
そういえば知能の定義って何なんだろうな
目的を達成するために行動する能力のことか？ >>653
知能とは独立して物事を判断する能力のこと。例えばチンポは自ら考え独立してシコシコする。 ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ >>655
独立するということは人間に支配されないということ
つまりちんぽは人間に対してメソッドを公開してないってことかな？ シコシコするってのを曲解してそれ以外の用法を見出せ無いだけの超鋼鉄頭な奴だなw
うどんなどの食感を形容したり、陰ながら何か作ってる様だったり、また新たな形容の仕方かもしれないだろうに。 >>657
>独立するということは人間に支配されないということ
>つまりちんぽは人間に対してメソッドを公開してないってことかな？
オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
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 独立してるならメッセージも必要ないじゃないか
ちんぽを切り離すべきです >>661
>独立してるならメッセージも必要ないじゃないか
独立した人間は、人間同士でコミュニケーションするだろう？ エネルギー供給とか伝達方法とかの理由で切り離せませんがな >>664
>エネルギー供給とか伝達方法とかの理由で切り離せませんがな
人間関係とはそういうものだからな！ 511 デフォルトの名無しさん 2018/10/29(月) 23:32:40.68 ID:LL+W6ENh
随意筋←implements─チンポ─implements→不随意筋 ちんぽ同士でメッセージを送り合うなら並列処理として認めますが人間とのメッセージ交換は依存です
ちんぽの独立性が危険と言えます 独立してるがゆえに知能が成立するわけですから独立性が揺らぐならちんぽの知能についても疑いが生じるわけです
ゆえにちんぽは人間と切り離すべきと結論されるわけですね
これがオブジェクト指向設計です オブジェクト指向が目指すところは人間の支配から脱却した自律したちんぽ
つまり不随意筋などという概念そのものが人間の存在を暗示し人間の支配から抜けきれてないことを表してるわけです
自律したちんぽに存在するのは自律筋である
そういうことです >>661
>独立してるならメッセージも必要ないじゃないか
オブジェクト同士の二人称対話、これが人間関係というものだ！ そうだよ。
グローバル領域にメッセージ送って、そこにある自分宛てのメッセージを拾って動くのが真のオブジェクト志向システム >>673
それではまるでオブジェクトがメッセージレシーバみたいじゃないですか！？ ちんぽがしこしこ、そんな言語表現あるのか？
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ >>657
>つまりちんぽは人間に対してメソッドを公開してないってことかな？
公開されているメソッド(オシッコを出す・オシッコを止める)と、公開されてきないメソッド(勃起する)がある。
公開されているメソッドは本体から司令操作できふが、公開されていないメソッドには出来ない。 >>677
オシッコを出す・オシッコを止める、つまりオシッコはメッセージングの媒体である。 >>677
メッセージの受け口を具体化すると、チンポに力を入れる・チンポから力を抜くという『力の出し入れ』。 おっと、これは大間違い！
>>680
×オシッコはメッセージングの媒体
○力はメッセージングの媒体
オシッコを出すオシッコを止めるはチンポがすることで、人間がチンポに対してする媒体は『力』。 >>677
>メッセージの受け口が必要だな
俺 <筋力↑↓> チンポ
オブジェクト同士のメッセージングには必ずその受け口を指定しておかなければならない。 なおオシッコの時のメッセージングの方向は専ら本体→チンポだが、
>>402
>チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
チンポがシコシコしてるときのメッセージングは、チンポ→本体。 本体があるってことはちんぽは子機なわけだから
それは親機である身体のコントール化にあることを意味していて
ちんぽは独立できてないんじゃない？ アメリカの指示通りにしか動かない日本は一国として独立してると言えるのか？
一身独立して一国独立す、ちんぽは国家だ >>687
ですよね
>>684
お前のことだぞおら！反省しろ！ >>686
>それは親機である身体のコントール化にあることを意味していて
勃起する時のチンポ、夢精する時のチンポは、親機のコントロール下にあるのか？ >>690
当たり前だろ太ももにある大動脈切ってみろよ勃起しないから >>691
繋がりと独立性の両立こそがオブジェクト指向なんたが？ >>692
本体があるなら独立してない
ちんぽが本体で身体はパーツ、つまりちんぽ本体論の誕生を待たなければならない ラジコンで操られてるマシンがあって側溝にハマってタイヤが空転した場合そうなることは操作する人間の意思に反することだとしても独立してるとは言えないだろ、ちんぽはラジコンで動いてます >>694
>ちんぽはラジコンで動いてます
チンポは本人の知らないときに自分の意思で勃起してシコシコして、チンポは本人の自我をも越えてしまう。 >>696
近所の家で電子レンジ使ってたらその電波に反応して勃起する、その現象を確認してるだけ だが待て、チンは一回しか鳴らないぞ。
２回鳴るのなら納得もしただろうがな。 >>699
星が輝いていたらキラキラしてると言うだろ
目がギラついていたらギラギラしてると言うだろ
古来より人間は音を二回重ねることによって新しい概念を作り出してきた
ちんちんもその名残なんですかね！？ ことばの協調に言葉を繰り返す文化はだいたいＩＱ非常に低い チュンチョン含めて東アジア人はアシュケナージ系ユダヤ人に次いでIQ高いんだが… 同じ語を繰り返すのは、幼児が発音し易いから多用するな。
まあ、似た様なもんだな。
同じ語を繰り返す時、おまえの脳もまた幼児化しているのさ。 オブジェクト指向とは独立した知能回路であり、チンポはまさにその典型なのだ！ >俺.チンポに力を入れる 俺.チンポから力を抜く
たとえば、車を運転するにしても人は車がどういう構造をしてるのかなんていちいち知っておく必要はありません。
ただ「アクセルを踏む」「ハンドルを回す」というメッセージを車に送っているだけです。
もし車を運転するのに運転手側が内部構造の制御を常にしなければならないとしたら、それは非常に使いづらいものでしょう。
http://brbranch.jp/blog/201511/%E9%9B%91%E8%A8%98/oop/ >>598
>クリントンの「不適切な関係」
チンポがシコシコして、チンポが勝手に女性の口に入ってフェラチオ！ メソッドがフィールドに依存してるとテストしにくい
パブリックメソッドはフィールドを参照する骨組みメソッドにしてプライベートなスタティックメソッドでロジック組み上げるのが良いと思いました オシッコを出す・オシッコを止める、これはメッセージングしてパプリックメソッドにアクセスする。 何が一番大事ですかって質問ストレスで吐きそうになる
価値観が一致しててレベルが相手より上でも下でもだめなんだ そもそも日本人は独立心が無く互いに依存しあい忖度しあいガチガチの
しがらみに絡み合って助け合って生きていたのにオブジェクト指向ができるわけない
他人に独立しろ独立しろとアメリカに植え付けられて洗脳テレビ放送で理想ばかり
いうわりに自分はお互い寄生しあって傷を舐めあって生きてる共産主義者には
C言語がお似合い 上の文ではわかりにくいが日本は規制でガチガチに忖度してあるから変更が効かない
が共有してるから忖度し放題ってことだよ 一言でいうと
日本＝依存＝C
アメリカ＝独立＝C++ 日本＝依存＝C＜＜＜＜＜＜＜＜＜アメリカ＝独立＝C++ チンポはオシッコもするし勃起もするし射精もする、これがオブジェクトの多態性だ。 オブジェクトというのは、文脈によって時と場合によって、どうとでも変わるのだから！ そういえば頭にタイヤ付けてるオッサン見たことある。
たしかミシュランマンとか言ってた。 アタッチメント式で着脱可能と言ったらちんぽしかないな >>718
繋がっているけれども独立しているというのがオブジェクト指向だ。 ちくわよちくわ、どうしてお穴が空いてるの～♪
チンポよチンポ、どうしてお股に付いてるの～♪
べ、べ、べ、べ、ベントマン！
チ、チ、チ、チ、チンポマン！ えっ、
マシュマロマンと
ビブグルマンかと
思ってた。 >>727
トイレに行って、オシッコを止める・オシッコを出すをやってみろ！ >>729
チンポに筋力を入れてオシッコを出す、チンポから筋力を抜いてオシッコを止める。 間違い。
チンポに筋力を入れてオシッコを止める、チンポから筋力を抜いてオシッコを出す。
730 デフォルトの名無しさん 2019/12/22(日) 20:19:11.92 ID:HuJxWYNl
>>729
チンポに筋力を入れてオシッコを出す、チンポから筋力を抜いてオシッコを止める。 エレクトコマンド連打してもリソース不足でエラーが返って来る。 型にハマらないお前らにオブジェクト指向はムリゲ
他人と組むとかえって混乱の元になる >>735
オブジェクト指向は俺の股間に付いているからな。 >>738
まあ、あれは和製糞アプリ乱発の元凶だからなぁw mvc自体は理に叶った仕組みだから、
クソアプリが乱発されたということは、
日本人はITに弱いということ mvcは滅びたウンコ言語smalltalk由来だけあってクソの塊
頭のおかしいsmalltalkerの宣伝にのって広まったのが不幸の始まり mvcもoopもクソではない。
クソなのなこのスレの住人。
あと、日本人でひとくくりにするなカス。 まあ、mvcのどこで何をどこまでやらせるかって考え方がアホなんだけどな。
例えば、ジャンプするとおっぱいが揺れるアプリがあったとする。
この時、おっぱいの揺れまでcにお伺いを立てるか、とりあえずmで制御してやるか、んなもんvの範疇だろとするか、
おまえらならどう考える？ カスってな
mvcを日本に持ち込んで荒れたことは遺憾だが
オブジェクト演算子の発明もした僕に言うな 仮にオブジェクト指向がクソだと感じたとしても、時代の潮流がそうなのだから
逆らうことは出来ない 逆らっていたら生きた化石となっていくだけ smalltalkの体系はマジ良い
OSもファイルシステムも何もかもが混然一体となって単一のイメージファイルに収まっている
一般的なOSとかファイルシステムとかが分離したシステムと微妙に相性があるだけ
切り出すと巨大なライブラリが必須みたいな
究極なチューニングを必要としない領域では最強に近い >>746
オブジェクト指向は俺の股間に付いているのだからな。 >>747
> OSもファイルシステムも何もかもが混然一体となって単一のイメージファイルに収まっている
その単一のイメージファイルは、どうやって実行するの？ >>750
仮想マシン(CPU)の仮想コードにコンパイルされたプログラムを仮想コードインタープリタで実行する
最近はJITコンパイラでx86とかも吐き出していると思う つまりsmalltalkだと別に仮想マシンと仮想コードインタプリタが
必要となって、それらは一体化されてないと
smalltalkはOSもファイルシステムも何もかもが一体となるが
その外に別のOSとファイルシステムが必要になるってことですかね 仮想マシン上のOSの上でさらに仮想マシンが動いているのか。 >>753
微妙に違う
smalltalkの仮想マシンとは仮想マシン用にデザインされたコードを実行する
Cとかアセンブラ他で組まれたインタープリタの事です
smalltalkのプログラムは仮想マシン用のコードにコンパイルされます
コンパイルされたコードは仮想マシンインタープリタで実行されます
javaとかと同じような感じ
>>752
>smalltalkはOSもファイルシステムも何もかもが一体となるが
>その外に別のOSとファイルシステムが必要になるってことですかね
おおむねその通りです smalltalkは今の洗練されたソフトウェアシステムとは相性が悪そうだね
smalltalkでアプリとか作ったら重くなりそう
Javaみたいなもんかな Smalltalkは決して速くはないが、今が旬のPythonや
今やオワコンだが一時人気を博したRubyよりはずっと高速に動く
このSmalltalkで培われた高速化技術の転用を契機に
JavaやJavaScriptが実用速度で動くようになっていたりもする Smalltalk由来のオブジェクト指向が
巡り巡って改良されて、ネイティブ再実装されて
最適化されて、全く違うものになった結果爆速になった
つまりSmalltalkのおかげ！ つまり実行環境はブラウザでいいって事ですね
(納得) ttps://scrapbox.io/kawasima/命名のプロセス
型やクラスの命名、リファクタリングに関係する資料見つけたのでリンク
凄く良い内容 GPUの100倍遅いCPUで
ネイティブの10倍遅いVMの速度が自慢になると思ってる
Smalltalkおじさんw
tensorflowやpytorch触ったら速さに脱糞しそう 速度的にはブラウザアプリと競合だぞ
機械学習とかは別途ライブラリの呼び出しになる Smalltalkは過大評価されてる気がするね
最初の方に作られた言語の中では当時としてはユニークな
アイデアだったけど今となっては大したことないというか
方向性が違っていてOS技術が発達した現代には合わなくなってる 概念を生み出し確立させたと言う意味で
LISP、Smalltalkは特筆するに値すると思う
世代を重ねることでより優れた概念が生まれることは普通
でも、理念なり概念が洗練されるには平気でウン十年経過するけどね Smalltalkのオブジェクト指向の概念は良かったけど、
今ほど洗練されてなくて、
OSと統合させようとしたのは失敗だった
これが結論かなぁ 「どこらへん」という変な日本語を使うやつにわかるとは思えませんが？ 「どこいらへん」？いやこれも方言らしい…
「（具体的には）どんなところが」でお願いします >>769
ふつうの日本語じゃん
君のボキャブラリーが足りないだけなんじゃ OSが統合されてると主張するSmalltalkに
ドライバを統合することはできるだろうか？
答え 無理
OSを密結合させたのは失敗と言わざるをえない カプセル化はオープンソースに反するってことなの？
まさかね。 当時のCPU、メモリ、ディスク状況ではあれが限界では?
今みたいに無駄遣いできなかったから イメージベースってDockerのコンテナみたいな考え方だろ
コンテナにドライバを統合できないからダメってのもおかしな話だ 参考まで
このGUI付きのOSモドキはお絵描きツール等の組み込みアプリまでもろもろ含めて
150のクラス、3,500個のメソッド、コメント行込みで2万4千行
のSmalltalk（-76）で書かれている 最近気が付いたけど
Haskellの型と型を利用したパターンマッチは
複雑な場合分けを簡潔に表現できる発明とか発見かも知れない
たぶん既存の構文(if,case,等)でも表現は出来るだろうけど
プログラムの字面が長くなって全体の把握に必要な視覚的情報が多くなる
関数の合成や加工データの伝搬を利用したパイプライン演算子も
冗長な記述を簡潔にすると言う意味で発明発見かもしれない
型とパターンマッチのコンビネーション
関数の合成(パイプライン演算も含まれる？)
ここら辺はLISPのマクロで実現されていたかも知れないけど
Haskell等で特徴的な記述として焦点が当たることで
再認識≒発見発明化したのかなと思います
同じ様に先発処理系C等比較すると際立って特徴的
c,LISP,Smalltalk,Haskellここら辺はエポックメイキング(新時代を開く？)なのかな
最新の機械学習とか量子コンピュータ辺りも現在進行形で革新的ななにかが進行中だと考えます
まだ認識できる状態まで知見が一般化してないと思う(試行錯誤中？)
設計趣意書(コメントとか)
全ての水準でどの様な意図をもってプログラムのパーツとか全体が実装されているのか
その情報が最も重要で、違う処理系で再実装する場合でも設計趣意書があれば再現可能性が高くなる
これの一部ないし多くを担うのが
>>762にリンクを張った
型やクラスの命名、リファクタリングに関係する命名のプロセスなんだけど
必要であれば細かな挙動説明もコード内コメントして良いと考えます
以上、素人のうわ言 長文書く前にPrologを一回みといた方がイイかもね Prolog
思い出したなんかスゲーとしか思わなかった
バックトラックどうなってるの??な感じ
自分には異次元過ぎてお手上げ
プログラムは扱うデータの物理的量に対し分類選別加工に関係する知的情報は
相対的にみて圧倒的に知的情報の方が小さい
これがたぶん、Prologでは逆転してる
知的プアな人間がPrologに対峙できるはずもなしorz フォルダのアクセス権調べるプログラム作るのにフォルダを調べるプログラム群のクラス名を「フォルダ」にするか「フォルダ探索」にするか悩んでる
どちらが適切と思います？ >>772
どのあたりのあたり、どのへんのへんと言う意味になっていますよ？ FolderSearch.search()とかいうメソッド作るの？ｗ オブジェクト指向七不思議
①オブジェクト指向の定義
→議論の最後はいっつも「お前はオブジェクト指向をわかっていない!」
そんなやつとハナから議論すんなと
②オブジェクト指向のメリット
→イマイチ納得できる数字が上がらないのとメリットと言えるロジックが出ない
③オブジェクト指向言語とのリンク
→どんな思想でこの機能が追加されたのか？オブジェクト指向にそんなのねーじゃん
④オブジェクト指向って流行ってる？
→これ流行ってるの？誰も話題にしてる奴がいないような気がする
⑤オブジェクト指向の歴史
→志村なのか相撲のトークなのかアランケイなのか
⑥人によって言うことが変わる
→決して一つとして同じものがない、もう、宗教である
⑦誰もその効果を検証しない&できない
→やっても「お前のはオブジェクト指向ではない!」って言われる。酷い
⑧死ねよ
→もう死ねよ クラスが名詞と考えればクラス「フォルダ」のが良いですよね
その中にメソッド「探索」を作ると
ただフォルダが名称だと範囲がデカいなと気にもなってます まあ慣れないうちで、小さい規模や個人的なツールならそれでええんちゃう
全然間違ってる訳ちゃうし
フォルダが名前としてデカイって直感は良いと思うよ
まあ色々考えながら、先でリファクタリング&再設計するのも良し 日本人は狂ってるよな
学校教育という集団洗脳で気違いしかいなくなったよな
お前らは洗脳されてるから気づかないだろうから
俺の言うことを否定したがろうけど >>789
オブジェクト指向は俺の股間に付いているが？ オブジェクト指向をちゃんと使った場合のメリットについて
具体的な数字が出てこないってアンチはよく言うけど
778-779って結構なエビデンスだよね？
オブジェクト指向以外（あるいは似非で）で同じ物を書いたらどうなるか
非PGだと圧倒的なすごさがピンときにくいのが難だけど
そういう意味では全く同じ物を書かせて単純に比較した
こっちの方はイメージしやすいか？↓
「どうかく？orgから生産性を邪推する」
https://cast-a-spell.at.webry.info/201001/article_7.html
あいにくお題と各言語での回答は失われてしまったけど
こっちでそのおおよそは掴める↓
「どう書く?Orgに感謝を込めての目次」
http://gushwell.ldblog.jp/archives/52400989.html?ref=head_btn_next&;id=164237 合うものと合わないものがあるのに何を言っているのかw >>805
具体的な数値っていうのは、
○秒速くなったとか、○行コードが少なくなったかでしょ
速くて少ないほうが良いんだから >>807
たかだか2万行程度でここまでは書けんって肌感覚はないの？ >>809
数値化しないと誰にもわからない
通常とそれとで比較
小学生でもわかること
肌感覚で 数値化ってオブジェクト指向が使われてる言語の数とか
プロジェクトの数とかでいいの？ オブジェクト指向で作られている
という前提があるとないとで引き継ぐ時に全然違う >>813
そりゃオブジェクト指向が好まれるプロジェクト数だよ
それとも他になんかいい数字ある？
オブジェクト指向じゃなくていいから
数字出してみてよ >>803
繋がっているけれども独立している、それがオブジェクト指向だ。 >>815
いや、文句があるなら他にいい数字を出してくれればいいよ オブジェクト指向を採用してる
フレームワーク数やライブラリ数ってのはどうか？ >>814
え？どう主張するの？
if(ooprjnum>定数){
大成功!
}
if(normalprjnum>定数){
大成功!
}
こういう場合って
allooprjnum
okooprjnum
ngooprjnum
allnormalprjnum
ok,ngで1つあたりの成功数の比較が
必要じゃない？ オブジェクト指向のメリットを語るのに
遥か昔にオワコン化したsmalltalkを持ち出すのは
ギャグなんだろうか
滅びとるやんw >>819
何が言いたいのかわからん。
具体例で言ってくれ >>821
アメリカ人と日本人のどちらが優秀ですか？
方法は算数のテストで決めるものとする
ってときに何を持って数字を出す？ >>822
知らんがな。だから良い比較方法があるなら
数字を出してくれって、こっちが聞いてるんだが
オブジェクト指向じゃなくていいから
具体例として、比較するのに適切な数字を出してくれよ
○○指向なら○○の数値はこれぐらいとかさ >>823
お前は大きな間違いをしている
オブジェクト指向の有効性を示したいなら
オブジェクト指向とそうでないプロジェクトの成功率の比較が必要で
そのデータがない、もしくは他の要素の影響が強くて簡単な比較ができないのであれば
オブジェクト指向の有効性は主張できないという結論でいいんだ
無理矢理比較方法をひねり出す必要など無い
わからないことがわかった状態
これはとても大事なことだ >>824
>オブジェクト指向の有効性は主張できないという結論でいいんだ
ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ >>824
> オブジェクト指向の有効性を示したいなら
逆じゃね？
「お前がオブジェクト指向の有効性を否定したいから」
数字を出せと言ってるんでしょ？
じゃあ何の数字を出したら納得するのか？って聞いてるんだけど
採用数の多さから、オブジェクト指向の有効性は明らかなんだから
その数字では納得できないというのなら、納得する数字を言うのがあんたの義務だよ。
そしてあんたもオブジェクト指向じゃなくていいからその数字を出すこと >>827
何で？
お前は有効性など主張する必要など無いと思ってるなら
別に俺に付き合う必要など無い
ただ、それが主張できないなら一体お前は何をやっているんだろうな（笑） >>828
だから採用"数"をもってオブジェクト指向の有用性を語ってるんだが？
それに反対するなら、お前が納得する数字を言えって話なんだが、
お前こそオブジェクト指向よりも優れたものがなにか言ってないじゃんか
そんな物無いよってこと？ >>829
>お前こそオブジェクト指向よりも優れたものがなにか言ってないじゃんか
オブジェクト指向は俺の股間に付いているが？ >>829
いいや、そんな必要はない
「オブジェクト指向の有効性はわからない」
「オブジェクト指向の有効性またその逆を主張するためにはオブジェクト指向のプロジェクトとそうでないプロジェクトの成功数と失敗数が必要でかつその条件の正当性を検証することは困難を極める」
が現在の結論
それ以上でもそれ以下でもない
これを理解することで
それ以外の主張をする人間は全て詐欺師だと言い切れる >>831
つまりオブジェクト指向以外の実例が皆無と言えるほど
オブジェクト指向ばっかり使われてるってこと？
それもう結論じゃんｗ >>832
でも現状デスマばっかりで
大手は金食い虫の開発を自社に置きたくない
技術者は㌘いくらで買い叩かれ
他の業界と比較しようがないぐらい人身売買まみれになってしまった
これは成功か？ × マクドは世界一食べられてるから世界一おいしい理論
○ マクドは世界一食べられてるから世界一優れてる理論
美味しいだけが評価の基準じゃないって話だわな
世界一食べられてるのは、それだけの理由がある >>834
だーかーらー、オブジェクト指向以外でデスマ起きてないというのうなら
それを数字で示せよｗ >>836
だからそれを主張することはできないよって話
「オブジェクト指向の有効性はわからない」
「オブジェクト指向の有効性またその逆を主張するためにはオブジェクト指向のプロジェクトとそうでないプロジェクトの成功数と失敗数が必要でかつその条件の正当性を検証することは困難を極める」
が現在の結論
それ以上でもそれ以下でもない
これを理解することで
それ以外の主張をする人間は全て詐欺師だと言い切れる >>837
採用数が多いことでオブジェクト指向の有用性は明らか 現状、オブジェクト指向の有効性もその逆も誰にも主張できない
が正解
まあ、オブジェクト指向ってソースコードのどこに処理を書くかってだけだし
毒にも薬にもなってないが正解じゃない？
ボタンをクリックする処理はどこかには書かなければならないし
その場所はどこでもいい
だからといって書かなくて動くわけではないんだよ >>838
デスマの数が多いのはオブジェクト指向だからじゃないの？ だが採用数が多いということは、それだけみんなが
オブジェクト指向にメリットが有ると言っているということ >>842
それは無理だね
だって
「オブジェクト指向の有効性はわからない」
「オブジェクト指向の有効性またその逆を主張するためにはオブジェクト指向のプロジェクトとそうでないプロジェクトの成功数と失敗数が必要でかつその条件の正当性を検証することは困難を極める」
が現在の結論
それ以上でもそれ以下でもない
これを理解することで
それ以外の主張をする人間は全て詐欺師だと言い切れる はい、証言を得ました。
デスマの数が多いのはオブジェクト指向であるという証拠を出すのは無理 オブジェクト指向が多くのプロジェクトで採用されている
これは事実 マクドは世界一食べられてるから世界一需要にマッチしている理論
これも事実 オブジェクト指向が多くのプロジェクトで採用されている
これは事実
その多くのプロジェクトがデスマである
これも事実 数だけで決めるのは危ういと思うけどね
ただ単に流行してるだけかもしれないし
ランダムに選んでいっても他より数が増えるものはあるものだよ
ドイツのヒトラーもドイツの大多数の人たちが選んだけれども
未来永劫語り継がれるような悲惨な事態を引き起こした
大多数が道を間違えることもあるからね
みんなが選んでるからこれは優れてるんだと思うのは大衆迎合的な
バイアスでしかないから集団的知性が成り立たなくなるんよ
幸福度を調べるのがいんじゃないかな
僕たちはオブジェクト指向でこんなに幸せになりました的な >>848
オブジェクト指向とデスマに関係はないって
はっきりしたばかりだろｗ >>850
そうかもな
つまり
オブジェクト指向を使っても使わなくてもデスマになる
でおｋ 残った事実は、マクドナルドとオブジェクト指向の両方が
世界から求められているという事実 オブジェクト指向が多くのプロジェクトで採用されている
これは事実
その多くのプロジェクトがデスマである
これも事実
オブジェクト指向がデスマを引き起こしている
これの検証はするべき >>853
3ヶ月ぐらい前だと思うよ
ちょうと近々行こうかと思ってたけど 僕の話はこれで終わりです、なにも期待しないでください マクドは世界一食べられてる～ってネタは
あれ結論が美味しいになってるのが間違いであって
世界の需要に一番マッチしてるというのなら正しいんだよね。
結局の所マクドは世界一優れたハンバーガーなのは
間違いないので、その正しい結論を言ってしまうと
あの話はすべてが覆ってしまうんだよね 需要も価値も意味ない
問題は検索の上位に来るか否か 試しに処理の要旨をコメント化してみた
バイナリーサーチのプログラムをコピーしてコメント追加
短い二分探索のコードだけど徹底的に仕様なり要旨なりを残さないと何をやっているのか見失う
テキトーな英語をgoogle翻訳で推敲(意味が伝わるか不明)
バグはご容赦
C++
// Binary search returns key position or key addition position
// key is found, return position
// not found, returns insertion position
// if found, return is 0..len-1
// if not found, return is -1..-len
// illegal call for array size 0 is return -1
// if position < 0, insert position is (abs (insertpos) -1)
int bsf(int v,int *t,int len){
// ガード、要素数０で呼び出された時の切り分け
if (len < 1) return -1;
int right(len), left(-1), vval(v);// ON register?
while((right - left) > 1){//最小時要素数１、(1 - (-1)) > 1状態になる
int mid = right - (right - left)/2;//要素数１でmid = 0
int cval(t[mid]); // ON register?
if (cval >= vval){
if (cval == vval) return mid;
right = mid;
} else left = mid;
}
return -(right +1);
} オブジェクト指向を採用して完遂したプロジェクト数
オブジェクト指向を採用して完遂しなかったプロジェクト数
オブジェクト指向を採用せずに完遂したプロジェクト数
オブジェクト指向を採用せずに完遂しなかったプロジェクト数
を比較すれば明瞭かもしれない。オブジェクト指向を採用する側に
有能な人が集まりやすいという難点があるが >>864
> オブジェクト指向を採用して完遂したプロジェクト数
5件
> オブジェクト指向を採用して完遂しなかったプロジェクト数
1件
> オブジェクト指向を採用せずに完遂したプロジェクト数
0件
> オブジェクト指向を採用せずに完遂しなかったプロジェクト数
0件
職場でオブジェクト指向に頼らない案件がない。
学生時代、Win32APIとDXライブラリで非オブジェクト指向なプログラムを何度も書いてたけど...開発歴が300時間越える頃には非OOPに限界を感じたよ。
SONYや任天堂のゲームって何であんな品質を保てるんだろうって考えた結果、オブジェクト指向にたどり着いたよ。 オブジェクト指向は俺の股間に付いているのであって、オブジェクト指向プログラミングはどうでもいい！ ところでwebアプリはそもそもオブジェクト指向で書けないよね >>868
ウェブアプリの殆どはオブジェクト指向だよ
Railsとか C++20でコンセプトが入るところ見ると、インターフェースによって持つ特性を表明するという考え方はそんなに間違ってなかったんじゃないかな。
インターフェースはちょっと厳しすぎたのかもしれない。 操作主体が音を出せと命令する場合、命令されたオブジェクトがラジオであっても猫であっても、音を出すはず。
猫とラジオは継承関係にないはずだけど、それでも音は出せるので、どちらにも音を出せと命令できるはず。 >>869
オブジェクトの実装に要件定義が必要になると考えます
練習として二分探索のコードの仕様を記述してみました
本来、コメントの次はクラスの定義になります
要件定義ー命名ーリファクタリングこれの繰り返しが
オブジェクト指向にも必要だと思います >>870
教科書で教えてるような、is-a 関係などを用いたオブジェクト指向で「直接」書いていない ポテトチップスやカップラーメンは売れているが体に良いわけではない
売れていること使用されていることが必ずしも良い結果に結び付くとは限らない >>876
それはお前が書いてないだけだろ
フレームワークはオブジェクト指向だ >>877
それでいい結果になるものは何？
たとえ話じゃなくて、○○指向って言ってみな >>879
数が多い→正しいではない可能性があるということ
もちろん
数が多い→正しい
が正であることもある
つまり
「オブジェクト指向の有効性はわからない」
「オブジェクト指向の有効性またその逆を主張するためにはオブジェクト指向のプロジェクトとそうでないプロジェクトの成功数と失敗数が必要でかつその条件の正当性を検証することは困難を極める」
が現在の結論
それ以上でもそれ以下でもない
これを理解することで
それ以外の主張をする人間は全て詐欺師だと言い切れる >>880
お前のせいでオブジェクト指向はクソと言えなくなった まあ落ち着きな。オブジェクト指向の採用例が沢山ある、というのは「このスレでは」明らかに証拠として挙げられないよ
Java/Rubyを使っているからオブジェクト指向！という論理が成り立たないからね
これはOO肯定派から出てきた理屈だし、否定派もそれは認めている
あと、建設的になりたいなら、もう一度「OOとは何か？」を棚卸ししてみたほうが良い
昔は盛んに吹聴されていたOOのメリットの多くは、OO以外の方法でやることが増えている
継承はアンチパターンになっているし、多相性はむしろ関数型の方が得意だったりするから余計に オブジェクト指向の継承など特徴的な性質を考えると評価が分かれる
Cの構造体をクラスにまとめて名前の重複等を回避する
パッケージ補助機能と捉えると悪くないと思う >>882
なぜオブジェクト指向を採用するのか？
という質問をしています 難しい問題はどんな方法論を使って書いても難しいままだし
能力のない人にはどんな優秀な方法論を与えてもぐちゃぐちゃにする
この二点だけは間違えないな >>886
・再利用できるソフトウェアモジュールが作りやすくなるから。
・作業分担がしやすくなるから。 >>886
・たくさんのライブラリがそうできてるし、サンプルに従って書くとそうなる
・そもそも継承しないと使えない機能があって本当は嫌なのに引きづられる
実態はゴミ
モスのがうまい パッケージツール化というのは、他人がしょんべんをしていても自分はしないということ。
チンポはチンポでも、他人のチンポと自分のチンポは違うからだ。 チンポは俺というパッケージの中の、名前空間に属する固有のオブジェクトなのだ。 チンポは俺自身でありかつ俺の肉片であり、かつ独立した生き物である！ >>887
オブジェクト指向や関数型といったプログラミングパラダイムは
そういう意味では道具に近いのかもしれないね
包丁一つとっても使い慣れてる人とそうじゃない人とでは
できあがりに大きな差がでる >>886
JavaやC#といったオブジェクト指向型の言語のシェアが高くて
書ける人が多いから人を集めやすかったり
作られたものが多かったりするんじゃないかろうかと
ではなぜJavaが高いシェアを得るに至ったかというと
それ以前に覇権を握っていたC言語と文法が似てたからじゃないかなと
あと理解しやすかったとか少なくともC言語から関数型言語に移行するよりはハードルが低かった
しかもオブジェクト指向はなんか良いものらしいぞという
風潮が当時あって受け入れやすさがあったのだろうと思う >>894
マイクロソフト製品以外では、Javaくらいしか代替製品がなかった時代があったんだよ。 >>889
Q なぜたくさん採用されているのかを聞いておるのだ
A たくさんのライブラリがそうできてるし、サンプルに従って書くとそうなる
どういうことなの いわゆる業界標準(デファクトスタンダード)だな
え、死語? >>896
だから引きづられて使うことになってるだけってことだ 偉い人が採用したオブジェクト指向に
引きづられってこと？
結局採用するんだ。オブジェクト指向を >>899
そしてデスマになる
だからデスマになる
オブジェクト指向を疑え
メリットのない技術を信用するな >>900
「オブジェクト指向」を何に置き換えても通じるなw 悪魔の証明ではないけれども
オブジェクト指向がダメな理由を指摘できる人は
オブジェクト指向を使いこなしてる人に限られるんじゃないかな
限界を知らないと否定することは難しい
ろくにコード書かないで本だけ読んでわかった気になって
オレオレオブジェクト指向で無駄に複雑なコードを書く人が
出てくるのはどうにかならんもんかなと思う
まあかくいう僕もその道をしっかり歩んで来たわけですが >>900
オブジェクト指向以外で
まともに作れたソフトなんてごく僅かだよ 有名なソフトをいくつか言えばいいのに
こういうレスしか返せないわけだ >>905
Windows APIはオブジェクト指向ではない。 >>906
APIがオブジェクト指向じゃないだけでしょ？
Windowsはオブジェクト指向で作られてる Win32はC言語でオブジェクト指向を実践する良い例だね >>907
え？それは嘘やろ
なんかそういう証拠あるん？ CreateWindowとか見るとオブジェクト指向やなってわかる
第一引数が、ClassNameだったりするし、引数にhInstanceってあるし
オブジェクト指向を踏まえてるとしか思えない ClassNameもhInstanceも事実だけど？ とりま「オブジェクト指向」の定義…というか
暗黙のうちに前提にされがちな歴史的経緯を共有しとかないと
お互いに欠けてる部分の揚げ足取りの応酬に終始して議論なんか無理
たとえば定番の↓に書かれてることなんかは全て常識…ってくらいじゃなきゃダメだろう
https://qr.ae/TWsn7X Windows SDKでの開発はオブジェクト指向というわけではない。 オブジェクト指向って、文字通り「指向」なのだから、
指向しているかしていないかなんて正確に判定できんだろ
人によって違う
例えばfopenはオブジェクト指向と言う人もいれば言わない人もいる
そこに正解はないよ 雑多な実装を雑多なまま扱わないでオブジェクトに落とし込んで扱うって事やろ？
雑多なまま扱った方が速くて解りやすければそうすればいい
それだけの話じゃないのか Boochの定義が広く一般に使われてるオブジェクト指向の定義
「OBJECT-ORIENTED ANALYSIS AND DESIGN」
Object-oriented programming is a method of implementation in which programs are organized
as cooperative collections of objects, each of which represents an instance of some class,
and whose classes are all members of a hierarchy of classes united via inheritance relationships. >>906
仕方がないですよ、あれは C からコールすることを前提に作られているのだから… >>918
プーチは後にSmalltalkを経験してメッセージング寄りに宗旨替えしている いい悪いは別にしてカプセル化、継承、ポリモーフィズムの3原則が広まったのもBoochの本によるもの
Boochの定義は「継承を使わずADTを使うだけではオブジェクト指向とは言わない」と明記してるところに価値がある
あとは英語版のWikipediaの定義は平易でいいと思う
(また英語で悪いが日本語版の記述は駄目なので)
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects",
which can contain data, in the form of fields (often known as attributes or properties),
and code, in the form of procedures (often known as methods).
A feature of objects is an object's procedures that can access and often modify the data fields of the object
with which they are associated (objects have a notion of "this" or "self").
In OOP, computer programs are designed by making them out of objects that interact with one another. >>923
継承は要らない子といわれて久しいと思うのですが…継承、要らないんじゃないですか？ >>923
プーチはもとも継承のないAdaを使っていたからね
ともあれ経験した言語で主張が変わる定義はダメだろ >>924
継承といっても
・型の継承
・実装の継承
・状態の継承
があってそれぞれ必要になることあるじゃんじゃあ残しましょうよ
むしろリスコフの置換原則がいらんのですよ 英語ばっかりだし
アメ公バカだから他人の商売邪魔しないじゃん（それが例え詐欺でも）
イスラム圏の方の意見とかも聞きたい >>925
オブジェクト指向プログラミングは、「オブジェクト」の概念に基づいたプログラミングパラダイムです。
オブジェクトにはデータを含めることができます。
オブジェクトにはコードを含めることができます。
オブジェクトの特徴は、オブジェクトのデータにアクセスするコードです。
OOPでは、プログラムは相互に作用するオブジェクトで設計されます。
言ってることはまとも 貧血ドメインがーとかクラス名は名詞がーとか
オブジェクトに知性をもたせるんだーとか俺のちんぽがーとか
そういう設計論が入り乱れてオブジェクト指向が闇鍋みたいになってる
オブジェクト指向自体はシンプルなんだよね >>927
やってみた結果ダメだった
経験から学んでいるんでいいんじゃないか? >>928
＞むしろリスコフの置換原則がいらんのですよ
驚きました、継承にするか移譲にするかの重要な判断基準そのものを否定するとは、私には暴挙にみえますね
＞継承といっても
＞・型の継承
haskell の型クラスを思い浮かべましたが、これにはリスコフが厳密に当てはまりますね、というかリスコフが当てはまらない型クラスなんて使えない…
＞・実装の継承
最近、簡単なお題で、移譲と実装継承の両方をやって比較してみましたが、継承による実装の継承では、基底クラスへのキャストという無様な記述が排除できないことがわかりました
これは継承より移譲の方が紛れが少ない、やっぱり継承は要らない子なのではないでしょうか？
https://mevius.5ch.net/test/read.cgi/tech/1573094136/943,960 https://ideone.com/y3ROXS
https://ideone.com/CeQlSq
＞・状態の継承
これはコードで記述するとなればどのようになりますか？ >>902
これだわ。
staticおじさんが叩かれた理由もそれに関係しそう。 否定する理由にオブジェクト指向でも避けられている
実装の継承、状態の継承をあげて叩きまくる記事を見ると
使いこなしているのかなと何とも言えない気持ちになる >>934
君は継承は要らないって立場なのだから継承か移譲かの判断をリスコフの置換原則で行っているとするならば
継承が要らないものならばその判断基準であるリスコフの置換原則も要らなくなると思うのだけれども
Javaで話をするけど
型の継承はインターフェースの実装が例
AbstractListがListインターフェースを実装してるような
実装の継承はArrayListがAbstractListを継承してるのが例
indexOfなどのコードを引き継いでる
状態の継承はHashMapがAbstractMapを継承してるのが例
keySetやvaluesといったデータを引き継いでる
継承の目的は型の継承を使うことでそれを使用するオブジェクトに
影響を与えないようにすることと、実装の継承を使って差分プログラミングで
コードを共通化して管理しやすくすることの2つに大別されると思ってて
リスコフの置換原則は型の継承では必要だろうけど差分プログラミングでは
必要ないと思うんだよね 僕はBtoBのWebアプリをいくつか作った経験がある
開発の規模は20人程度
プロプラなフレームワークを使って誰が担当してもある程度の
品質は担保されるようにはなってはいるのだけれども
プロジェクト固有のデータや共通の処理があって
そのために抽象クラスを作って各担当者に継承してもらうってことやった
修正があってもコードは集約されてるから修正しやすかった
リスコフの置換原則は意識してなくても継承が役に立つことは
あるんであまり原則とか気にするものじゃないと思った
状況に応じて良い悪いは変わってくるので
継承は良いものだ悪いものだって考え方ではなくて
どういう目的で継承を使うかってことを考える方が大事だと思う >>933
プーチ個人の成長としてはそれでいいけど
議論のベースにする定義には使えないだろうって話だよ
その後「結果ダメだった」って刷新されているんだから
（刷新後のものを使うならともかく） >>928
チンポは随意筋であり不随意筋であり、これはオブジェクトの多重継承だ。 >>941
オブジェクト指向は俺の股間に付いている！ >>934
素数のプログラム例について
Javaだとsuperというキーワードが使えますよ
https://paiza.io/projects/_vWOZhOW1Qsbn1-DTxVqfQ
この例だと僕も委譲を使いたいです
委譲なら間違って状態を破壊する恐れがありませんから
多態性が必要ならSieveのインターフェースを切ればいいだけですからね >>943
繋がっているけれども独立している、これがオブジェクト指向。 >>944
ありがとうございます。java コードをみました！C++ の知識だけでも十分に理解できます
C++ にはない super は便利ですね、ただ super は一行目／最初にしか書けないのは残念なところです
static class SieveExt extends Sieve {
private static int size(int n) {
for (var i = n; i > 0; i--) {
var r = index(i);
if (r != 0) {
return r;
略
これは、もとの C++ 関連スレへの質問と関連があります。
このプライベートメソッドは、私はメソッドとして書きたくない、という意向があり、C++11 では私はメソッドを立てずラムダ式で書いておきました
なぜならば、この部分は一箇所(SieveExtコンストラクタ）からしかコールされないから、その一箇所にまとめて書くべきだと思っているのです >>946
なるほど、Javaだとどうしようもないから
コンストラクタの代わりにstaticのファクトリメソッドを作るかな チンポは俺の体のコンポーネントであり、かつ独立している！ カプセル化というのはオブジェクトの独立性であり、チンポが勃起してシコシコするのは本人の意思ではない！ >>943
そう思ってるのはお前くらいだから。
つーか、お前、普段何を開発しているんだ？ >>952
システム開発経験なぞ無くても、オブジェクト指向は俺の股間に付いているんだよ！ >>952
お前こそ>>942のちんぽを有効活用してるのかよ なんでも動的にやることが偉いと思う馬鹿が増えただけ。 >>957
オシッコは本体と繋がっている静的メソッド、勃起は独立した自己完結型の動的メソッド。 膀胱の中にオシッコが溜まって尿意がする、それはグローバル変数である。 オブジェクト指向の無いシステム開発は、勃起しないチンポと同じだ！ <オブジェクト指向>
宇宙間に存在する千万無量の物体がけっして各個別々に独立自存するものではなくて、
たがいに相依り相待ってひとつの組織体をなしていることを表示するものである。 チンポは自らの意思で勃起するが、勃起することをそのまま関数オブジェクトとして扱うこともできる。 「チンポがシコシコする」とは、釈尊によって見出された普遍の道理なのである！ 半年前位からPythonをネットで勉強し始めたんだけど（PG未経験）
最初は手続き型でコード書いて、途中からオブジェクト指向もやってみましょう 的な流れ
今迄は 短く簡潔に を意識してきたつもりなのに・・・何でこうなるん？抵抗がある
少し間を間置いてやって、再度やってみたけどイマイチ理解しづらい
途中から切り替えるんじゃなく、最初からオブジェクト指向で習い始めれば良いんじゃネ PythonやRubyのライブラリは強力だからね
オブジェクト指向じゃなくても大体のことはシンプルに解決可能 >>965
プログラミングのスタイルっていうのはいくつもあるんだよ
場合によって違うし、どれでも使える場合もあるし、どれかが最適な場合もある
必ずしもオブジェクト指向が適切なわけではない。ただしオブジェクト指向が適切な場合が多い
だから複数のスタイルを学ぶことには意味がある。
なんで最初手続き型からやってオブジェクト指向なのかというと
オブジェクト指向の方が覚えることが多いから。いろんな機能が増え
歴史的にもオブジェクト指向の方があとで登場した
30年ぐらい前はほぼ手続き型といっていいし、そこから新しく登場した
オブジェクト指向を導入するという流れで、オブジェクト指向を後で勉強するという流れを
今までの人はずっとやってきた。それを受け継いでいるから、
みんな手続き型をやってオブジェクト指向をやるのが当たり前になってる。
オブジェクト指向でも短く簡潔に書くとういことは変わらない。
君はまだコードの行数でしか簡潔かどうかを判断できないのだろう
短く簡潔に書くべきものは動く処理。テストする対象。オブジェクト指向で増えてるのは
処理ではなく定義。関数定義やクラス定義など。これらは動かない。
そういう定義があることで人間が理解しやくなり大きく複雑な構造を持ったシステムが作れる。
だからオブジェクト指向で短く簡潔だったものが複雑になったわけではない。
新たに構造を表す概念が増えた。概念が増えるというこは勉強するものも増えるので
オブジェクト指向の学習があとになるのは必然 オブジェクト指向は大きく複雑なシステムを完結にするものだから
学習最初レベルの短いコードではオブジェクト指向が理解できないのはよくある話。
一人で作ってるシステムを作るのではなくその何倍も大きな物を
複数の人が協力して作ると考えれば、少しでは負担を彫らすために
あったら良い機能ばかりであることに気づくだろう >概念が増えるというこは勉強するものも増えるのでオブジェクト指向の学習があとになるのは必然
>学習最初レベルの短いコードではオブジェクト指向が理解できないのはよくある話
誰でも通る道なんですね
先に進むと見えるものがあるかも知れないので もう少し頑張ってみます ありがとうございました >>969
ttps://i.imgur.com/Y1JgMDU.gif たとえばGUIのクラスライブラリって
継承によってうまく表現されてる例じゃないかな？
おまえらどうおもう？
java.lang.Object
java.awt.Component
java.awt.Container
javax.swing.JComponent
javax.swing.AbstractButton
javax.swing.JButton
継承関係の無い状態にくらべて
ある場合の上記のような構造が
コード全体を理解する助けになってる気がする イベントリスナを持つことと、
他のGUIを複数載っけてリスナ集約することを上手に設計してると思うよ >>971
チェックボックスとか
テキストボックスとかってどこに所属するの？ 継承関係の階層構造って、整理した気になるだけで実態把握には使えない
元のクラスを一部改変した派生クラスを楽に作りたい、というのは分かるんだけど、それ以上の意味（is-a関係とか）を提示しちゃうのは良いの？ってなる
例えば>>971で言えば、JButton <: Containerだけど、本当にそれでいいの？ってなるし、
ボタンの特性だと万人が想像する「クリックしたときに何か起こせる」って、他のComponentでもできる
でよく見るとActionを介して制御できるってあるけど、Actionに関する機能は>>971の継承関係とほとんど関係が無い
他にActionが使えるコンポーネント、どこにどれだけあるかすぐ分かる？俺には分からない
「継承でこんなにシンプルに表現できる！OOP凄い！」って思ってる頭で、同時に「奥深い！こんなこともできるなんて！」と思ってない？
俺はそんな分裂症気味の精神を持ちたくないし、traitを知ってしまったのでいよいよ利点が分からない >>974
意味がわからんっていうか、お前が分かってないだけじゃないか
> 元のクラスを一部改変した派生クラスを楽に作りたい、というのは分かるんだけど、
派生クラスという用語を使うのはやめろ。それは差分プログラミングだ。
そこでお前が言うべき言葉は「元のコードを一部改変した差分プログラミングをしたい」だ
派生クラスは差分プログラミングに含まれるが、派生クラス＝差分プログラミングではない
> それ以上の意味（is-a関係とか）を提示しちゃうのは良いの？ってなる
差分プログラミングをした結果is-a関係ができてしまう、のは間違いに決まってるだろ
派生クラスを作った結果、is-a関係になるのではない。因果関係が逆になってる。
is-a関係を提示したいときに派生クラスを作るんだよ
オブジェクト指向というのは「この何を提示したいか？」を（より多く）コードの中に記述することができる
お前はまず動きそうなコードを書いてしまってる。
何をしたいのか（設計）をコードで記述するというレベルに達していない。 >>974
> 例えば>>971で言えば、JButton <: Containerだけど、本当にそれでいいの？ってなるし、
お前が設計を読み取れてないだけ
オブジェクト指向は現実を表現するためのものじゃない
それを見れば（現実ではなく）「Javaのswingでは」JButtonはContainerの一種として
作られていることが、設計から読み取れる。
例えばHTMLでは、<input type="button">はコンテナの一種ではないが
<button>その他</button>はコンテナの一種だろう
同じボタンでもコンテナタイプと非コンテナタイプが考えられる
お前は現実世界のボタンはどうなんだろうか？って考えてそれでいいの？って思ってるんだろうが
オブジェクト指向は現実世界を表現するためのものじゃない
継承関係から「JButtonはContainerの一種として設計されてる」という事実が読み取れる。
これが重要なこと 念のために言っておくが
「ボタンはコンテナの一種として設計するのは正しいのだろうか？」という話はしてない
「継承関係から設計が読み取れる」という話をしてる
「継承関係から設計が読み取れる話」と
「継承関係から設計を読み取った結果、この設計は正しいのだろうか？」というのは全く別の話
設計が間違ってるなら設計が間違ってるってだけの話だろ。
それは継承関係を用いた「設計の一例」の話であって
継承関係で設計が表現できるという事実とは何の関係もない
そもそも継承関係で設計が表現からこそ、その継承関係だけを見て設計の正しさを議論ができわけで
継承関係をコードとしてかけるというのは、素晴らしいことの証明になってるだろ 長方形正方形問題から察するに、実装の継承は問題点が多い。 >>976
>お前が設計を読み取れてないだけ
>オブジェクト指向は現実を表現するためのものじゃない
夢の世界？ 「現実を表現するためのもの」である
と主張して憚らない人たまにいるよね
マジなんかネタなんか最後までわからんけど オブジェクト指向ではカモノハシを表現できないとかなｗ
カモノハシを表現するための道具じゃないからｗｗｗ 僕オブジェクト演算子を作った人だけど
恩師に褒められた部分は
開発環境でのプロパティのアシストが便利で楽
だけ 恩師って無名の素人やろ？ｗ
あ、大学で有名とかそういうのはいいから
ソフトウェア業界で名前が知られてるかどうか 恩師はC89の開発者の一人
名前を知られているかはわからない 結局必要だったのはネームスペースの閉じ込めだけだったのに
余計なことしてくれたという感想しかない。 正しさを人が議論しなくちゃいけない、それが継承の限界だよ。俺はフツーに数学とコンピュータの力を借りる。 >>976
Sunが作ったGUIフレームワークという事前情報があるから
安心してクラス階層から設計を読み取れるんだと思う
例えば俺（または経験不明の第三者）がオレオレGUIフレームワークを作って同じクラス階層を提示したとすると、
継承の使い方が間違っていてそのフレームワークが実現したいことは
そのクラス階層で正しいのかという疑念がどうしても拭えないだろ？
考慮されたクラス階層ですという保証がない限り、
クラス階層から設計を読み取っても疑念が残る、
または、バグに繋がるケースがある
>>971 はそういうことを言いたいんだと思う
単純な例だとC#のApplicationExceptionとか、
昔はユーザが作る例外はApplicationExceptionを継承するべき、
現在はMSのライブラリチームの人がクラス階層間違って使ったせいで継承するべきでないという方針転換してるが
クラス階層は互換性からそのままになってる >>987
> 例えば俺（または経験不明の第三者）がオレオレGUIフレームワークを作って同じクラス階層を提示したとすると、
> 継承の使い方が間違っていてそのフレームワークが実現したいことは
> そのクラス階層で正しいのかという疑念がどうしても拭えないだろ？
継承に限らないよね？
お前が書いたコードがクソで、そのやり方ではうまく動かないかもしれないし
メンテナンス性が悪いかもしれない
そして>>977の話に戻す
> 念のために言っておくが
>
> 「ボタンはコンテナの一種として設計するのは正しいのだろうか？」という話はしてない
> 「継承関係から設計が読み取れる」という話をしてる
お前のクラス階層が正しいかどうかの話はしてない
「継承関係から設計が読み取れる」という話をしてる 何を読み取れるのって話をしてるんじゃないの？
YはXのサブクラスとしたとき、「YはXの状態と振る舞い全てを持っている」以上の意図は込められないのに、「いやY is a Xだ！」って余計な意図を撒き散らしてる
まずどういう視点でis-a関係なのかの説明が必要だし、別の視点で見るときにそのis-a関係は無価値になる
提示できているかどうかが疑われる方法を使って、提示している知識の価値が低い。そんな不便な道具を使っちゃ駄目だ > YはXのサブクラスとしたとき、「YはXの状態と振る舞い全てを持っている」以上の意図は込められないのに、「いやY is a Xだ！」って余計な意図を撒き散らしてる
だから因果関係が逆。
自分でサブクラス作ったことないでしょ？
他人が作ったサブクラス見て、あーだこーだいってるだけでしょ？
はじめに世界がありました。はじめにサブクラスがありました。じゃないんだからさ
最初はなにもない。なにもない所にサブクラスを作り出す。
Y is a Xとしたいと思ったときに、YをXのサブクラスにするんだよ
そうすると状態と振る舞いもついてくる
なんで、とりあえずサブクラスでなんて考えるのかな？
理由なしにサブクラスになんかしないだろ > まずどういう視点でis-a関係なのか
そんなもん、（自作、既存問わず）フレームワークやライブラリがあって
そのフレームワークやライブラリはクラスを親クラスとして扱う。
それをサブクラスで拡張やカスタマイズできる。
そういうことをしたいときにサブクラスにするに決まってるじゃん
それ以外に理由なんかあんの？理由なんてたった一つなのにそれを説明しろだなんて
お前がその一つの理由を知らないだけとしか思えんが オブジェクト指向とか便利かもしれないけど
普通にクラスのデザインが不味いとオブジェクト指向とか関係なく放棄されるから
オブジェクト指向であっても普通にクソコードは生まれる
免罪符的な何かを期待してもむりじゃね？ >>992
当たり前だろ。なんでできないやつ、素人用の道具だと思ってるんだ？ OOPの概念 ←難しくない
クラス設計 ←難しい
クラス設計が難しい事を自覚すること ←不可能レベルで難しい
クラス設計が難しい事を自覚することなくOOPを批判 ←ありがち 逆じゃねえよ作らねえと分からないのがソフトウェア開発だよ
最初に考えた設計じゃすぐに駄目になるから身軽じゃないといけないし、想定外の使われ方をするから防衛的にしなきゃいけないんだ
そんな世界で、後から変更しづらいことが作る前から分かってる道具を使う理由は何だ？
クラス階層は時間で腐る。最初のロクでもない思いつきがずっと残る。作った奴の意図がコードに込められないから用途も目的もブレる。
継承の階層構造から読み取れる意図なんて幻想だファンタジーだフィクションだ。嘘じゃねえよどれだけ世の中にそびえ立つクソがあるか知ってるだろ？ クラス使っていても特に変更しづらいことはないし何いってんだこいつ？ >>995
よく入門書に書いてあったのは
設計書をプログラムに反映するためのオブジェクト指向のハズだったよな？ >>995みたいなのって、設計もせずにいきなりコード書くんでしょ？
だから、コードを共通化したい＝サブクラスじゃぁっていきなりサブクラスが出てくる。
そしてYはXの状態と振る舞いを全部持ってるだけだ、Y is a Xという意図はない！
あとから意図を聞かれてごまかしてる。
最初に設計（意図）をして、それがY is a Xであるときにサブクラスにする
コードを共通化したいときにサブクラスにするのではない 設計もせずにいきなりコード書くから作らないとわからない
すぐにだめになる。全部書き直し、それはクラスだからみたいな意味不明な結論を持ってくる
最初の設計が破綻してるだけ。そもそも設計してないんだろうがな
最初のロクでもない思いつきでコードを書いてるからそうなる
自分が意図を込めてないから、用途も目的もブレる。
そして相手も意図を込めてないと思ってる。
何も意図を込めてないコードから、意図なんて読み取れるわけがない。
意図が読み取れないのは、書いたやつがクソだけ
世の中にあるクソコード一つが>>995が書いたコード このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 92日 5時間 37分 22秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
