オブジェクト指向はオワコン

**デフォルトの名無しさん** · 2023/08/26(土) 22:00:53.85

最近の言語には採用されないことが増えている

**デフォルトの名無しさん** · 2024/01/19(金) 23:19:40.83

>>687
いいえ
説明したようにRustのtraitに実装継承はありません

**デフォルトの名無しさん** · 2024/01/19(金) 23:28:42.74

何で堂々と嘘つく？
嘘言った人謝ってください

**デフォルトの名無しさん** · 2024/01/19(金) 23:32:10.71

>>687はコードを書いたことがないのか
あるいは意図的に嘘ついているのか

**デフォルトの名無しさん** · 2024/01/19(金) 23:44:00.48

インターフェースは継承と違ってインターフェースもとのプロパティをオーバーロードして定義し直すから、継承のわけわからん隠蔽されてないプロパティでごっちゃごちゃにならないのがいい（java民）

**デフォルトの名無しさん** · 2024/01/20(土) 02:15:01.44

オブシコくんどこいったん？
インターフェイスは人間が理解しやすくするためのものだと力説しなよ

**デフォルトの名無しさん** · 2024/01/20(土) 02:28:42.63

疑似マルチスレッド君も反応ないんやけど、こないならQiita更新してくれよー

**デフォルトの名無しさん** · 2024/01/20(土) 03:07:14.53

>>685 >>687
これはデフォルト実装が同じtrait内メソッドと結合することまで実装継承と言うか話なんじゃないかな
実装継承の定義をtraitに拡張する時に生じた無理が意味の拡散を産んで無意味な争いを招いただけというかなんというか

**デフォルトの名無しさん** · 2024/01/20(土) 03:09:43.76

書き途中で「書き込む」ボタンを押しちゃった。てへ

>>685 >>687
これはデフォルト実装が同じtrait内のメソッドと結合することまで実装継承と言うかという話なんじゃないか
実装継承の定義をtraitへ無理やり拡張する時に生じた意味の拡散ですれ違ってるだけに見える

**デフォルトの名無しさん** · 2024/01/20(土) 05:41:23.80

>>694
そもそもはある具体型A(もしくはクラスA以下同様)の実装が別の具体型Bの実装として継承されることを指すよね

一方でRustのトレイトのデフォルト実装では具体型の実装は全く出て来なくて具体型とは切り離されているよね
したがってある具体型の実装が別の具体型の実装として継承されることは起きないため明確かな

**デフォルトの名無しさん** · 2024/01/20(土) 09:43:00.30

継承用の基底クラスを提供するのはライブラリやフレームワークで、フロント屋はその提供された基底クラスを継承して使う
フロント屋は用意された基底クラスを使う以外はインターフェースやシールドクラスで継承もどきをやるだけで事足りてる

**デフォルトの名無しさん** · 2024/01/20(土) 10:27:27.05

staticおじさんが結局正しかったね。

**デフォルトの名無しさん** · 2024/01/20(土) 10:38:22.56

うん、知らんけど

**デフォルトの名無しさん** · 2024/01/20(土) 11:13:01.53

>>696
いま思い出したことなんだけど。具体型の継承はできないと思うけど、traitをtraitに実装するということが出来る
traitAにデフォルト実装を書いて、traitBに実装すると、traitBを実装した型はtraitAのデフォルト実装を引き継ぐ

**デフォルトの名無しさん** · 2024/01/20(土) 11:29:56.55

trait TraitA {
fn method_a(&self);
}

trait TraitB {
fn method_b(&self) {
println!("Method B called");
}
}

// TraitBをTraitAを実装するすべての型に対して実装する
impl<T: TraitA> TraitB for T {}

struct MyStruct;

// MyStructにTraitAを実装する
impl TraitA for MyStruct {
fn method_a(&self) {
println!("Method A called");
}
}

fn main() {
let my_struct = MyStruct;
my_struct.method_a(); // TraitAのメソッド
my_struct.method_b(); // TraitBのメソッド（TraitAを実装するため自動的に利用可能）
}

**デフォルトの名無しさん** · 2024/01/20(土) 11:37:18.66

Rustに多重継承は存在しないという場合、意味的にはフィールドを継承しないことと、
スーパートレイトを使用すれば、トレイトのデフォルト実装を別のトレイトに暗黙では引き継がないことを指すんじゃないかな
かな、というのは、まあここら辺は人によって受け取り方が違うから議論しても仕方のないことなんだけど

**デフォルトの名無しさん** · 2024/01/20(土) 12:00:42.41

>>700 >>701
それは実装継承ではないよ
なぜならtraitは具体型ではなく、さらにRustの場合はデフォルト実装から具体型の固有フィールド(メンバ変数)や固有メソッドに一切アクセスができない
つまり実装継承における問題が発生しない

**デフォルトの名無しさん** · 2024/01/20(土) 12:26:39.60

実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい？

**デフォルトの名無しさん** · 2024/01/20(土) 12:38:21.50

>>704
両方
まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない

次に>>701が例示している件に対して
＞// TraitBをTraitAを実装するすべての型に対して実装する
＞impl<T: TraitA> TraitB for T {}
これは実装継承ではないだけでなく、類似しているように見えても、実装継承の問題と同じことは発生しない

**デフォルトの名無しさん** · 2024/01/20(土) 12:39:32.26

実装継承ができないと不便じゃない？
リソース管理を一元化したくなったりとかしないの？

**デフォルトの名無しさん** · 2024/01/20(土) 12:40:39.50

Rustにも実装継承はあるんじゃないかな

**デフォルトの名無しさん** · 2024/01/20(土) 12:53:48.29

>>706
Rustでは異なる型の間でコードを共有一元化するためにトレイト制約を使ってジェネリックにコードを書ける
そのコードは特定の型に対して一切書かれていないため実装継承とならないだけでなく実装継承と類似の問題も発生しない

>>707
Rustに実装継承はない

**デフォルトの名無しさん** · 2024/01/20(土) 12:58:32.97

ジェネリックで書いてコンパイラに整合性を取らせる
うむ、完璧だ

**デフォルトの名無しさん** · 2024/01/20(土) 13:04:04.37

Structの合成があるじゃないか
実装継承の問題が発生しないのはわかったけど
実装継承の便利さが失われてたら元も子もないじゃん
リソース管理を一元化したくなったりとかしないの？

**デフォルトの名無しさん** · 2024/01/20(土) 13:08:56.68

オブシコは機能とデータを一緒に管理することだけど
それができないRustは不便なのでRustは滅びます

**デフォルトの名無しさん** · 2024/01/20(土) 13:16:14.55

>>709
Rustはそのためにトレイト制約がありコンパイラは整合性を必ず確認できる

>>710
Rustではトレイト制約を伴うジェネリックコードにより異なる型間でも安全にコードを共有化できる

>>711
Rustでも型(データ)に対してメソッド(機能)を実装できる

**デフォルトの名無しさん** · 2024/01/20(土) 13:18:48.25

>>712
データにメソッドを生やして継承もできるん？

**デフォルトの名無しさん** · 2024/01/20(土) 13:20:04.95

オブシコにおいて実装の継承は正義です
Rustに正義はあるのかを問うています

**デフォルトの名無しさん** · 2024/01/20(土) 13:34:19.14

>>713
やりたいことの本質は異なる型の間でのコードの共有一元化でしょう
Rustではトレイト制約を用いて特定の型に依存しない形でコードの共有一元化ができます

>>714
オブジェクト指向に実装の継承は必要ありません

**デフォルトの名無しさん** · 2024/01/20(土) 13:35:44.30

誰かさ、適当な文法で単一のC言語ソースファイルを出力するトランスレータ作ってくんない？
仮想関数テーブルとかRTTIとかそれならなんとかなるだろ？

**デフォルトの名無しさん** · 2024/01/20(土) 13:36:27.03

じゃあオブシコはオワコンかも知れませんね

**デフォルトの名無しさん** · 2024/01/20(土) 13:44:22.78

さすがRust有識者だ😳
トレイトへの理解度が高い

**デフォルトの名無しさん** · 2024/01/20(土) 14:51:20.08

継承はすべてのオブジェクトに共通のデータと手続きを強制するからな
途中で一部しか共通してないオブジェクトの存在が判明したら、
クラスツリーをがっつり再設計しないといけなくなる
こんなものをオブシコに入れちゃったやつの罪は深い

**デフォルトの名無しさん** · 2024/01/20(土) 15:05:28.23

>機能とデータを一緒に
カリー化された関数を部分適用すればいい
じゃあ何故カリー化と部分適用はオワコンではないのか
無意味だからだ
意味を見出せないから終わったという判断もできない

**デフォルトの名無しさん** · 2024/01/20(土) 15:06:09.94

能力の高いプログラマーしかプロジェクトに参加しないこと前提ならば継承の副作用は目立たないけど
Javaのような大規模開発向けの言語に継承を入れたのは間違ってたなあ
Javaの仕様を考えた時は、親クラスは能力の高いエンジニアが書くという前提だったんだろうね

**デフォルトの名無しさん** · 2024/01/20(土) 15:25:38.27

>>719
再設計は不要
はい光速の論破

**デフォルトの名無しさん** · 2024/01/20(土) 15:56:26.55

大規模開発向けにはRustを採用すべきだ

**デフォルトの名無しさん** · 2024/01/20(土) 16:02:56.24

アスペクト指向との統一解ってことなのかな
ろくに勉強してないんだけど

**デフォルトの名無しさん** · 2024/01/20(土) 16:28:12.97

もともとアスペクト指向の提唱者たちが言い始めたことだからね
どんなに上手くクラスツリーを設計しても何らかのコードを横断的に埋め込みたくなるニーズがなくならないって

**デフォルトの名無しさん** · 2024/01/20(土) 17:05:53.11

>>722
つまんねーのに無理すんな

**デフォルトの名無しさん** · 2024/01/20(土) 23:20:19.94

Rustは学習コストが重すぎるからねえ
スタックフレームとか、ライフタイムとか、そこら辺の知識は普通のPGには余計だろう
Rustのスクリプト言語版が出たら流行るかなー

**デフォルトの名無しさん** · 2024/01/21(日) 00:07:59.00

RustじゃなくてもGoくらいでちょうどいい

**デフォルトの名無しさん** · 2024/01/21(日) 08:12:46.78

>>723
お前Rustのことわかってない上にプログラムできないじゃん
つかとっとと埋めてしまえよこんなスレタイだけでキチガイがわくスレ
真面目に語りたい人ならマ板でやる

**デフォルトの名無しさん** · 2024/01/21(日) 11:29:38.85

>>729
俺のことは関係ない、俺は世の中のことを言ってる
そんなことも読み取れない認知能力チンパンジーの分際で
俺様に文句言うなんて100年早えわ
お前はRustだけ頑張ってろアホンダラ
俺は日本の未来を考えとく

**デフォルトの名無しさん** · 2024/01/21(日) 11:31:12.83

Rustの未来も俺が決める
Rustはもっとオブシコ頑張ったが良い
Rustは学習コストが高すぎると言われている
これはオブシコで解決できるはずだ

**デフォルトの名無しさん** · 2024/01/21(日) 13:06:59.82

Rustってそんなに学習コストが高いか？
C++11以降のがトチ狂ってると思うんだけど

**デフォルトの名無しさん** · 2024/01/21(日) 13:40:55.67

スマポより生ポのが気持ちいい
だからわたしは生ポインタ

**デフォルトの名無しさん** · 2024/01/21(日) 15:09:59.21

>>705
>まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない
これは間違い
実装継承とは文字通り「実装」が「継承」されること <== この意味を理解できるかどうかが重要
実装継承における問題というのはこれも文字通り「実装」が「継承」されることによって起きる
継承元が具体型扱いかどうかは関係ない

>>704
>実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい？
Rustのトレイトデフォルト実装は実装継承の一種でもあるし、実装継承ににおける問題も発生する
C++等一部の言語で発生する実装継承における問題の一つが発生しにくいようになってるだけ

**デフォルトの名無しさん** · 2024/01/21(日) 21:44:12.50

>>734
Rustに実装継承はない
Rustのトレイトのデフォルト実装では、いわゆるメンバ変数やメンバ関数にアクセスできない
したがってRustでは実装継承と同様の問題は発生しない

**デフォルトの名無しさん** · 2024/01/22(月) 00:42:25.64

トレイトはインターフェースとも継承とも違う新しい考え
そこを誤解してはならない

**デフォルトの名無しさん** · 2024/01/22(月) 02:11:51.31

>>735
実装は継承してるけれども実装継承ではない？
「募ってはいるが募集はしていない」より酷くね？

**デフォルトの名無しさん** · 2024/01/22(月) 02:24:04.21

>>737
Rustに実装継承はない
Rustのトレイトのデフォルト実装からは、いわゆるメンバ変数やメンバ関数にアクセスできない
メンバ変数やメンバ関数にアクセスできる部分はトレイトのデフォルト実装から分離されている
その部分はトレイトを実装するときに各型で個別に実装する
したがってRustでは実装継承はなく問題も発生しない

**デフォルトの名無しさん** · 2024/01/22(月) 12:41:11.25

実装継承は派生側に開放する部分と基底側で閉鎖する部分の管理が難しいから、やはり「早すぎる最適化」になりがち。

開放/閉鎖の原則を守るためには基底側と派生側のインターフェイスとプロトコルを厳密に管理する必要があるけど、そこまでサポートしているオブジェクト指向言語てあったっけ？

**デフォルトの名無しさん** · 2024/01/22(月) 12:43:36.23

>>736
トレイトてこのこと？
まずは認識合わせをしないとな。
ja.m.wikipedia.org/wiki/%E3%83%88%E3%83%AC%E3%82%A4%E3%83%88

**デフォルトの名無しさん** · 2024/01/22(月) 15:21:25.58

最新鋭のRust言語と同等の最小コンパイル単位でよければもっとクリーンなオブジェクト指向言語があり得たって話で、
残念なことに30年前のハードウェアでやんなきゃいけなかった

仮想関数の方がデフォであるようなC++
文字列じゃなくて関数ポインタの配列のインデックスであるようなObjective-C
ガベコレの無いJava

こだわる人は今からでも作ればいい
ソースを一気に引数に取って単一のC言語のソースファイルを出力するトランスレータを作ればいい

**デフォルトの名無しさん** · 2024/01/23(火) 22:17:38.84

オブシコプログラムの難しいところってオブジェクト同士の連携が
オブジェクトに書かれるところだと思うんだよ
全体のフローがよくわからなくなる

オブジェクトには自律的に他のオブジェクトと連携することをやらなくさせて
コーディネートする処理を関数型や手続き型で書くのがいんじゃないかね

昔はオブジェクトが知性を持ってるかのように書くのが良いオブシコだと言われてたけど
スパゲティ製造工場にしかならんかった

**デフォルトの名無しさん** · 2024/01/23(火) 22:19:52.82

ObjectiveCの[]←こんな奴でメッセージ送ると幸せになれるよ

**デフォルトの名無しさん** · 2024/01/23(火) 22:19:59.28

フロー制御をオブシコでやりだしたら危険信号、これがぼくの経験から導き出された結論

**デフォルトの名無しさん** · 2024/01/23(火) 22:23:03.86

おしりがおまんこになっちゃうのがオブジェクト指向

**デフォルトの名無しさん** · 2024/01/24(水) 00:11:12.99

>>738
基本的な実装継承の問題を理解してないから話噛み合わないね
メンバ変数・メンバ関数の話はFragile Base Class Problem(FBCP)について言及してるつもりなんだろうけど
メンバ変数やメンバ関数にアクセスできるかどうかはFBCPの根本的な発生条件とは関係ないよ
継承元のメソッド実装がオーバーライドされた継承先のメソッドを呼び出せるならFBCPは発生する
当たり前だけどFBCPは実装継承の問題のうちの一つであってすべてではないからね

ちなみにトレイトのデフォルト実装も別のトレイトのメソッド経由でメンバ変数やメンバ関数にアクセスできる
クラス継承でベースクラスのメソッドがオーバーライドされたメソッド経由でメンバ変数やメンバ関数にアクセスするのと同じ

**デフォルトの名無しさん** · 2024/01/24(水) 00:14:41.63

>>744
イベントループをブラックボックス化したのは
「次のイベント」の種類ごとに分岐する際にifならbool値、switchなら整数のようなものしか
使えない言語の問題をライブラリでなんとかしようとした結果だ

**デフォルトの名無しさん** · 2024/01/24(水) 00:16:21.62

ついでに言っておくとRustのDeref/DerefMutも実装継承の一種なんだけどこっちはFBCPは発生しない

**デフォルトの名無しさん** · 2024/01/24(水) 02:14:43.30

>>746
Rustには基底クラスが存在しないため
FBCPも含めて実装継承に関する問題は発生しないよ

**デフォルトの名無しさん** · 2024/01/24(水) 12:30:29.92

影響力ゼロの人がどれだけオワコンオワコン繰り返しても全く影響無い。

**デフォルトの名無しさん** · 2024/01/24(水) 13:30:09.74

それなら人の力ではなく天変地異の影響を主に想定したほうがいい

**デフォルトの名無しさん** · 2024/01/24(水) 16:22:26.10

妻がダイエットのために乗馬を始めたんだけど一ヶ月で10キロ痩せたよ
馬がね

**デフォルトの名無しさん** · 2024/01/27(土) 12:58:37.96

has a関係は被害者と加害者が別人で、責任の連鎖がある
鎖を切って悪い影響を0にする変更はしやすい
is aは影響力を不変にする
責任の連鎖をなくして自分自身の責任とする

**デフォルトの名無しさん** · 2024/01/27(土) 19:38:08.87

241 伝説の名無しさん sage 2020/10/13(火) 15:00:15.08
「胸がドキドキする」というのはいわば生理現象であり、抑えることはほぼ不可能だ。
月末のクレジットカードの支払額に、想像以上に可愛かったデリヘル嬢のおマンコにと胸を
突かれるのは悪いことではない。

翻って「チンポがシコシコする」というのは能動的な衝動であり、極めて不埒な責任転嫁である。
シコシコはチンポが勝手にやったことであり、決してチンポの持ち主の意向ではないという、どこぞの
政治家の「秘書が勝手にやったこと」のような言い逃れがしばしば聞かれ、あまつさえそれがまかり
通ってきたことは周知の事実である。

チンポからシコシコを奪取し、各人の掌に戻る日は果たしてやってくるのだろうか……。

**デフォルトの名無しさん** · 2024/01/27(土) 22:55:15.08

責任という概念自体に違和感を表明する者がよくいるが
馬クラスと動物クラスには責任の擦り合いや利害対立がなさそうなところが共感されるんじゃないか

**デフォルトの名無しさん** · 2024/01/27(土) 22:55:50.75

令和になっても継承批判は聞きたくないね
手垢ついてるとかいうレベルじゃないぞ
OOPには価値がない
OOPのメリットとやらは無意味だ
というふうな大きい批判が聞きたい

**デフォルトの名無しさん** · 2024/01/27(土) 22:56:54.43

あ、>>756は別に特定のレスにむけたレスじゃなくて
ざっくりとした意見ね

**デフォルトの名無しさん** · 2024/01/27(土) 23:08:28.46

オブジェクト指向は継承という一つの要素が終わっただけだしなあ
未だ現役すぎる

**デフォルトの名無しさん** · 2024/01/28(日) 00:58:58.58

何らかの違和感の解消がオブジェクト指向のメリットだとするなら
元から違和感などなかった奴にとって無価値である

**デフォルトの名無しさん** · 2024/01/28(日) 03:30:55.01

5chになにを期待してんだかな

**デフォルトの名無しさん** · 2024/01/28(日) 14:48:42.54

>>756
概念的にはインターフェイスとコンポジションに発展的解消したから、オブジェクト指向はオワコンだろ。

**デフォルトの名無しさん** · 2024/01/28(日) 14:56:56.93

インターフェイスもコンポジションも人間が簡易に理解するためのものだろ
なめてんのか

**デフォルトの名無しさん** · 2024/01/28(日) 15:18:10.03

>>761
それオブジェクトの継承が別の概念に変わっただけでカプセル化とポリモーフィズムは健在じゃん…
もっとおもしろいこと言ってくれ…

**デフォルトの名無しさん** · 2024/01/28(日) 16:44:30.08

オブジェクト指向プログラミングのコアコンセプトは「データと操作をまとめて一つの型として扱うこと」これだけ

オブジェクト指向プログラミングではなくオブジェクト指向言語といった場合は
ブーチの定義が普及したせいでカプセル化、ポリモーフィズム(基本はサブタイプポリモーフィズム)、継承の3点セットを基準にすることが多いが
言語機能としての継承はオブジェクト指向プログラミングに必須のものではないし
ポリモーフィズムもオブジェクト指向言語特有のものではないので両方ともコアコンセプトではない

**デフォルトの名無しさん** · 2024/01/28(日) 17:24:51.96

>>763
オブジェクトのカプセル化はインターフェイスとデータを密結合するけど、インターフェイスによるカプセル化はデータと密結合しない。
オブジェクトのポリモーフィズムはオブジェクト同士が(継承関係とかで)密結合するけど、インターフェイスは継承関係とかの密接な関係を結ぶこと無しに(理想的には)ダックタイピングで多態できる。

まあ、そこまでのダックタイピングをサポートするインターフェイスとか知らんけど。
c++のコンセプトがそのまま型になったらいいんだけどなぁ。

**デフォルトの名無しさん** · 2024/01/28(日) 17:54:19.13

オブジェクトという言葉と同じでカプセル化という言葉は人によって意味が違うので困る

**デフォルトの名無しさん** · 2024/01/28(日) 19:52:00.86

70 名無しヒーリング 2021/04/26(月) 09:45:57.57 ID:jZDy/LpM
先生、実際にシコシコするのはチンポでなく俺の右手だと思います。

✖チンポがシコシコする
○ 俺の右手がチンポをシコシコする

71 名無しヒーリング 2021/04/26(月) 09:56:38.18 ID:jZDy/LpM
あと、「胸がドキドキする」と「チンポをシコシコする」は比較対象になりません。
「胸がドキドキする」は「チンポがヒリヒリする」のように状態・感覚を擬音語で現しているのであって、
「チンポをシコシコする」は「胸をモミモミする」の様に人間や動物が対象に対して何かを行う行為の表現だと思います。

**デフォルトの名無しさん** · 2024/01/29(月) 09:05:57.54

くだらない比喩でいつまやってんだ？

**デフォルトの名無しさん** · 2024/01/29(月) 15:05:39.33

>>767
だからシコシコは男性器を擦る擬音で勃起のことではない
君は女性かな？
それともシコシコが勃起を表す地方が日本のどこかにあるのか
どっちにしろいくらがんばってもメジャーなコピペになれないのは大多数の人に表現がピンとこないのが原因だと思うよ

**デフォルトの名無しさん** · 2024/02/01(木) 21:11:10.96

PHPでアブストラクトやりまくってる
これやってればいい
ここまで来るのに2年かかったわ

**デフォルトの名無しさん** · 2024/02/04(日) 19:38:06.66

再利用しようにもパーツに分解できない大きなプログラムのスパゲッティ化を防ぐために
ひと塊のルーチンを“関数”として入り口出口を決めましょうがカリー化まで続く一方の流れで
その塊をどうやって集団として機能に固めたり制御するのかを考えるのがオブジェクト指向
そういう上位レベルでの制御やメンテナンスの汎用的な考えから出てきた概念を
小さいレベルでのプログラムAの脚を車輪に付け替えるにはとか
プログラムAの塊を継承してプログラムBにするのが“オブジェクト指向”なんだよ！って
鬼子でしかないC++最初に来ちゃったせいで現代に至るまで
あれがオブジェクト指向だと思い込んでるおじいちゃんがですね…

**デフォルトの名無しさん** · 2024/02/04(日) 20:30:59.20

おじいちゃん構文丸出しでおじいちゃん批判ww
しかも中身が間違いだらけとかwww

**デフォルトの名無しさん** · 2024/02/04(日) 21:58:45.40

インターフェース楽しいな～
継承無しでコーディングできる～

**デフォルトの名無しさん** · 2024/02/04(日) 23:05:40.25

塊って言いたいだけ

**デフォルトの名無しさん** · 2024/02/04(日) 23:11:46.13

>ひと塊のルーチンを“関数”として入り口出口を決めましょう
これ現役引退してるような世代の方ですよね？

**デフォルトの名無しさん** · 2024/02/05(月) 10:19:20.77

役割で固めるってのを忘れてる

**デフォルトの名無しさん** · 2024/02/05(月) 11:38:56.86

横断的関心事の意味が分からんと常々思っていたけど
役割で固めるのをやめるという意味なのかね
固めようと思ったことがない奴にとっては無意味なことだ

**デフォルトの名無しさん** · 2024/02/05(月) 12:31:22.93

横断的にシコシコする役割の塊がオブシコである

**デフォルトの名無しさん** · 2024/02/05(月) 17:30:42.79

オブジェクト指向はモジュラリティを高めるために考え出されたものだが「どの抽象化階層のモジュラリティを高めるものなのか」という大前提を理解していないと何を見てもオブジェクト指向だと感じるようになる

**デフォルトの名無しさん** · 2024/02/05(月) 23:45:04.18

そりゃオブシコするぐらいだからモジャラリティは高いだろ

**デフォルトの名無しさん** · 2024/02/07(水) 14:59:43.29

1. 簡単な言葉を使う
頭が良い人は、複雑なことや専門知識も「簡単な言葉」で説明することができます。
この能力は、深い理解があるからできること。相手が理解しやすいように情報を整理して伝えることは思いやりでもあります。
https://news.yahoo.co.jp/expert/articles/9bb7a62121796847a941127e3d5040008fedd464

クリントン大統領にどんな強大な権限が有っても、自らのチンポがしこしこしてしまうのは止められない！

class チンポ extends クリントン{
　　　　　super.不適切な関係;
}

クリントンの再定義、クリントンの拡張された人格ということだ！

**デフォルトの名無しさん** · 2024/02/13(火) 12:31:45.94

世界一オブジェクト指向に忠実なメインクラスできたで

class Main():
def do():
pass

m=Main()
m.do()

**デフォルトの名無しさん** · 2024/02/13(火) 15:11:48.80

オブジェクト指向はオワコン
継承はよくない文化

**デフォルトの名無しさん** · 2024/02/13(火) 17:38:57.37

Template Methodパターン便利ですよ

**デフォルトの名無しさん** · 2024/02/13(火) 18:33:53.66

has a関係は抽象度の低いクラスを参照することはマナー違反ではない
is a関係は自分よりも抽象度低いクラスを継承したらマナー違反だよな

**デフォルトの名無しさん** · 2024/02/13(火) 19:00:08.50

継承を理解してれば問題無い
理解していないけどら問題無く使える道具は存在しない
つまり須く低レベルということ

**デフォルトの名無しさん** · 2024/02/13(火) 19:17:02.49

>>786
俺は使えるから問題ないんだが部下や上司に無能がいると困る
全ての言語で機能ごと消去するべき

**デフォルトの名無しさん** · 2024/02/13(火) 19:19:14.84

C/C++でいいところを無能のためにRustでわざわざメモリ管理を強制的に縛るのと一緒やね