1 名前:デフォルトの名無しさん mailto:sage [2023/08/26(土) 22:00:53.85 ID:H4l7y46b.net] 最近の言語には採用されないことが増えている
709 名前:デフォルトの名無しさん mailto:sage [2024/01/19(金) 23:32:10.71 ID:EWU8L+d2.net] >>687 はコードを書いたことがないのか あるいは意図的に嘘ついているのか
710 名前:デフォルトの名無しさん mailto:sage [2024/01/19(金) 23:44:00.48 ID:jOoBVxG+.net] インターフェースは継承と違ってインターフェースもとのプロパティをオーバーロードして定義し直すから、継承のわけわからん隠蔽されてないプロパティでごっちゃごちゃにならないのがいい(java民)
711 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 02:15:01.44 ID:pJVjc8l1.net] オブシコくんどこいったん? インターフェイスは人間が理解しやすくするためのものだと力説しなよ
712 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 02:28:42.63 ID:9SMgv4xr.net] 疑似マルチスレッド君も反応ないんやけど、こないならQiita更新してくれよー
713 名前:デフォルトの名無しさん [2024/01/20(土) 03:07:14.53 ID:ppE6WkEJ.net] >>685 >>687 これはデフォルト実装が同じtrait内メソッドと結合することまで実装継承と言うか話なんじゃないかな 実装継承の定義をtraitに拡張する時に生じた無理が意味の拡散を産んで無意味な争いを招いただけというかなんというか
714 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 03:09:43.76 ID:ppE6WkEJ.net] 書き途中で「書き込む」ボタンを押しちゃった。てへ >>685 >>687 これはデフォルト実装が同じtrait内のメソッドと結合することまで実装継承と言うかという話なんじゃないか 実装継承の定義をtraitへ無理やり拡張する時に生じた意味の拡散ですれ違ってるだけに見える
715 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 05:41:23.80 ID:OqC8H1ED.net] >>694 そもそもはある具体型A(もしくはクラスA以下同様)の実装が別の具体型Bの実装として継承されることを指すよね 一方でRustのトレイトのデフォルト実装では具体型の実装は全く出て来なくて具体型とは切り離されているよね したがってある具体型の実装が別の具体型の実装として継承されることは起きないため明確かな
716 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 09:43:00.30 ID:tKcafxZR.net] 継承用の基底クラスを提供するのはライブラリやフレームワークで、フロント屋はその提供された基底クラスを継承して使う フロント屋は用意された基底クラスを使う以外はインターフェースやシールドクラスで継承もどきをやるだけで事足りてる
717 名前:デフォルトの名無しさん [2024/01/20(土) 10:27:27.05 ID:mMSNo4e1.net] staticおじさんが結局正しかったね。
718 名前:デフォルトの名無しさん [2024/01/20(土) 10:38:22.56 ID:WbtYcj4O.net] うん、知らんけど
719 名前:デフォルトの名無しさん [2024/01/20(土) 11:13:01.53 ID:ppE6WkEJ.net] >>696 いま思い出したことなんだけど。具体型の継承はできないと思うけど、traitをtraitに実装するということが出来る traitAにデフォルト実装を書いて、traitBに実装すると、traitBを実装した型はtraitAのデフォルト実装を引き継ぐ
720 名前:デフォルトの名無しさん [2024/01/20(土) 11:29:56.55 ID:ppE6WkEJ.net] 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を実装するため自動的に利用可能) }
721 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 11:37:18.66 ID:ppE6WkEJ.net] Rustに多重継承は存在しないという場合、意味的にはフィールドを継承しないことと、 スーパートレイトを使用すれば、トレイトのデフォルト実装を別のトレイトに暗黙では引き継がないことを指すんじゃないかな かな、というのは、まあここら辺は人によって受け取り方が違うから議論しても仕方のないことなんだけど
722 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 12:00:42.41 ID:+uoYRouQ.net] >>700 >>701 それは実装継承ではないよ なぜならtraitは具体型ではなく、さらにRustの場合はデフォルト実装から具体型の固有フィールド(メンバ変数)や固有メソッドに一切アクセスができない つまり実装継承における問題が発生しない
723 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 12:26:39.60 ID:pJVjc8l1.net] 実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい?
724 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 12:38:21.50 ID:+uoYRouQ.net] >>704 両方 まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない 次に>>701 が例示している件に対して >// TraitBをTraitAを実装するすべての型に対して実装する >impl<T: TraitA> TraitB for T {} これは実装継承ではないだけでなく、類似しているように見えても、実装継承の問題と同じことは発生しない
725 名前:デフォルトの名無しさん [2024/01/20(土) 12:39:32.26 ID:BTn7foKi.net] 実装継承ができないと不便じゃない? リソース管理を一元化したくなったりとかしないの?
726 名前:デフォルトの名無しさん [2024/01/20(土) 12:40:39.50 ID:BTn7foKi.net] Rustにも実装継承はあるんじゃないかな
727 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 12:53:48.29 ID:UT8XEnd7.net] >>706 Rustでは異なる型の間でコードを共有一元化するためにトレイト制約を使ってジェネリックにコードを書ける そのコードは特定の型に対して一切書かれていないため実装継承とならないだけでなく実装継承と類似の問題も発生しない >>707 Rustに実装継承はない
728 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 12:58:32.97 ID:S3QqAIL4.net] ジェネリックで書いてコンパイラに整合性を取らせる うむ、完璧だ
729 名前:デフォルトの名無しさん [2024/01/20(土) 13:04:04.37 ID:BTn7foKi.net] Structの合成があるじゃないか 実装継承の問題が発生しないのはわかったけど 実装継承の便利さが失われてたら元も子もないじゃん リソース管理を一元化したくなったりとかしないの?
730 名前:デフォルトの名無しさん [2024/01/20(土) 13:08:56.68 ID:BTn7foKi.net] オブシコは機能とデータを一緒に管理することだけど それができないRustは不便なのでRustは滅びます
731 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 13:16:14.55 ID:UT8XEnd7.net] >>709 Rustはそのためにトレイト制約がありコンパイラは整合性を必ず確認できる >>710 Rustではトレイト制約を伴うジェネリックコードにより異なる型間でも安全にコードを共有化できる >>711 Rustでも型(データ)に対してメソッド(機能)を実装できる
732 名前:デフォルトの名無しさん [2024/01/20(土) 13:18:48.25 ID:BTn7foKi.net] >>712 データにメソッドを生やして継承もできるん?
733 名前:デフォルトの名無しさん [2024/01/20(土) 13:20:04.95 ID:BTn7foKi.net] オブシコにおいて実装の継承は正義です Rustに正義はあるのかを問うています
734 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 13:34:19.14 ID:UT8XEnd7.net] >>713 やりたいことの本質は異なる型の間でのコードの共有一元化でしょう Rustではトレイト制約を用いて特定の型に依存しない形でコードの共有一元化ができます >>714 オブジェクト指向に実装の継承は必要ありません
735 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 13:35:44.30 ID:JKkFvgES.net] 誰かさ、適当な文法で単一のC言語ソースファイルを出力するトランスレータ作ってくんない? 仮想関数テーブルとかRTTIとかそれならなんとかなるだろ?
736 名前:デフォルトの名無しさん [2024/01/20(土) 13:36:27.03 ID:BTn7foKi.net] じゃあオブシコはオワコンかも知れませんね
737 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 13:44:22.78 ID:tKcafxZR.net] さすがRust有識者だ😳 トレイトへの理解度が高い
738 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 14:51:20.08 ID:pJVjc8l1.net] 継承はすべてのオブジェクトに共通のデータと手続きを強制するからな 途中で一部しか共通してないオブジェクトの存在が判明したら、 クラスツリーをがっつり再設計しないといけなくなる こんなものをオブシコに入れちゃったやつの罪は深い
739 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 15:05:28.23 ID:UvH2GUkc.net] >機能とデータを一緒に カリー化された関数を部分適用すればいい じゃあ何故カリー化と部分適用はオワコンではないのか 無意味だからだ 意味を見出せないから終わったという判断もできない
740 名前:デフォルトの名無しさん [2024/01/20(土) 15:06:09.94 ID:ppE6WkEJ.net] 能力の高いプログラマーしかプロジェクトに参加しないこと前提ならば継承の副作用は目立たないけど Javaのような大規模開発向けの言語に継承を入れたのは間違ってたなあ Javaの仕様を考えた時は、親クラスは能力の高いエンジニアが書くという前提だったんだろうね
741 名前:デフォルトの名無しさん [2024/01/20(土) 15:25:38.27 ID:WbtYcj4O.net] >>719 再設計は不要 はい光速の論破
742 名前:デフォルトの名無しさん [2024/01/20(土) 15:56:26.55 ID:BTn7foKi.net] 大規模開発向けにはRustを採用すべきだ
743 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 16:02:56.24 ID:JKkFvgES.net] アスペクト指向との統一解ってことなのかな ろくに勉強してないんだけど
744 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 16:28:12.97 ID:JKkFvgES.net] もともとアスペクト指向の提唱者たちが言い始めたことだからね どんなに上手くクラスツリーを設計しても何らかのコードを横断的に埋め込みたくなるニーズがなくならないって
745 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 17:05:53.11 ID:pJVjc8l1.net] >>722 つまんねーのに無理すんな
746 名前:デフォルトの名無しさん mailto:sage [2024/01/20(土) 23:20:19.94 ID:ppE6WkEJ.net] Rustは学習コストが重すぎるからねえ スタックフレームとか、ライフタイムとか、そこら辺の知識は普通のPGには余計だろう Rustのスクリプト言語版が出たら流行るかなー
747 名前:デフォルトの名無しさん mailto:sage [2024/01/21(日) 00:07:59.00 ID:bASnz3O7.net] RustじゃなくてもGoくらいでちょうどいい
748 名前:デフォルトの名無しさん mailto:sage [2024/01/21(日) 08:12:46.78 ID:yW5L0zfB.net] >>723 お前Rustのことわかってない上にプログラムできないじゃん つかとっとと埋めてしまえよこんなスレタイだけでキチガイがわくスレ 真面目に語りたい人ならマ板でやる
749 名前:デフォルトの名無しさん [2024/01/21(日) 11:29:38.85 ID:oaoSrz7+.net] >>729 俺のことは関係ない、俺は世の中のことを言ってる そんなことも読み取れない認知能力チンパンジーの分際で 俺様に文句言うなんて100年早えわ お前はRustだけ頑張ってろアホンダラ 俺は日本の未来を考えとく
750 名前:デフォルトの名無しさん [2024/01/21(日) 11:31:12.83 ID:oaoSrz7+.net] Rustの未来も俺が決める Rustはもっとオブシコ頑張ったが良い Rustは学習コストが高すぎると言われている これはオブシコで解決できるはずだ
751 名前:デフォルトの名無しさん mailto:sage [2024/01/21(日) 13:06:59.82 ID:JVSLhHIM.net] Rustってそんなに学習コストが高いか? C++11以降のがトチ狂ってると思うんだけど
752 名前:デフォルトの名無しさん mailto:sage [2024/01/21(日) 13:40:55.67 ID:FqjwRk5K.net] スマポより生ポのが気持ちいい だからわたしは生ポインタ
753 名前:デフォルトの名無しさん mailto:sage [2024/01/21(日) 15:09:59.21 ID:LGH4j5ie.net] >>705 >まず実装継承とは具体型の実装が別の具体型に継承されることだから該当しない これは間違い 実装継承とは文字通り「実装」が「継承」されること <== この意味を理解できるかどうかが重要 実装継承における問題というのはこれも文字通り「実装」が「継承」されることによって起きる 継承元が具体型扱いかどうかは関係ない >>704 >実装継承ではないのか、実装継承における問題が発生しないだけなのか、どっちなんだい? Rustのトレイトデフォルト実装は実装継承の一種でもあるし、実装継承ににおける問題も発生する C++等一部の言語で発生する実装継承における問題の一つが発生しにくいようになってるだけ
754 名前:デフォルトの名無しさん mailto:sage [2024/01/21(日) 21:44:12.50 ID:r/H1GIpX.net] >>734 Rustに実装継承はない Rustのトレイトのデフォルト実装では、いわゆるメンバ変数やメンバ関数にアクセスできない したがってRustでは実装継承と同様の問題は発生しない
755 名前:デフォルトの名無しさん mailto:sage [2024/01/22(月) 00:42:25.64 ID:CM1Sn+EA.net] トレイトはインターフェースとも継承とも違う新しい考え そこを誤解してはならない
756 名前:デフォルトの名無しさん mailto:sage [2024/01/22(月) 02:11:51.31 ID:d/h6/f8z.net] >>735 実装は継承してるけれども実装継承ではない? 「募ってはいるが募集はしていない」より酷くね?
757 名前:デフォルトの名無しさん mailto:sage [2024/01/22(月) 02:24:04.21 ID:WDLNMI9J.net] >>737 Rustに実装継承はない Rustのトレイトのデフォルト実装からは、いわゆるメンバ変数やメンバ関数にアクセスできない メンバ変数やメンバ関数にアクセスできる部分はトレイトのデフォルト実装から分離されている その部分はトレイトを実装するときに各型で個別に実装する したがってRustでは実装継承はなく問題も発生しない
758 名前:デフォルトの名無しさん mailto:sage [2024/01/22(月) 12:41:11.25 ID:SpT9Xs4x.net] 実装継承は派生側に開放する部分と基底側で閉鎖する部分の管理が難しいから、やはり「早すぎる最適化」になりがち。 開放/閉鎖の原則を守るためには基底側と派生側のインターフェイスとプロトコルを厳密に管理する必要があるけど、そこまでサポートしているオブジェクト指向言語てあったっけ?
759 名前:デフォルトの名無しさん mailto:sage [2024/01/22(月) 12:43:36.23 ID:SpT9Xs4x.net] >>736 トレイトてこのこと? まずは認識合わせをしないとな。 ja.m.wikipedia.org/wiki/%E3%83%88%E3%83%AC%E3%82%A4%E3%83%88
760 名前:デフォルトの名無しさん [2024/01/22(月) 15:21:25.58 ID:eIK4O4RB.net] 最新鋭のRust言語と同等の最小コンパイル単位でよければもっとクリーンなオブジェクト指向言語があり得たって話で、 残念なことに30年前のハードウェアでやんなきゃいけなかった 仮想関数の方がデフォであるようなC++ 文字列じゃなくて関数ポインタの配列のインデックスであるようなObjective-C ガベコレの無いJava こだわる人は今からでも作ればいい ソースを一気に引数に取って単一のC言語のソースファイルを出力するトランスレータを作ればいい
761 名前:デフォルトの名無しさん [2024/01/23(火) 22:17:38.84 ID:3AfREKFo.net] オブシコプログラムの難しいところってオブジェクト同士の連携が オブジェクトに書かれるところだと思うんだよ 全体のフローがよくわからなくなる オブジェクトには自律的に他のオブジェクトと連携することをやらなくさせて コーディネートする処理を関数型や手続き型で書くのがいんじゃないかね 昔はオブジェクトが知性を持ってるかのように書くのが良いオブシコだと言われてたけど スパゲティ製造工場にしかならんかった
762 名前:デフォルトの名無しさん mailto:sage [2024/01/23(火) 22:19:52.82 ID:lLzKFCPg.net] ObjectiveCの[]←こんな奴でメッセージ送ると幸せになれるよ
763 名前:デフォルトの名無しさん [2024/01/23(火) 22:19:59.28 ID:3AfREKFo.net] フロー制御をオブシコでやりだしたら危険信号、これがぼくの経験から導き出された結論
764 名前:デフォルトの名無しさん [2024/01/23(火) 22:23:03.86 ID:PPNQFWhj.net] おしりがおまんこになっちゃうのがオブジェクト指向
765 名前:デフォルトの名無しさん mailto:sage [2024/01/24(水) 00:11:12.99 ID:X/KtyNlm.net] >>738 基本的な実装継承の問題を理解してないから話噛み合わないね メンバ変数・メンバ関数の話はFragile Base Class Problem(FBCP)について言及してるつもりなんだろうけど メンバ変数やメンバ関数にアクセスできるかどうかはFBCPの根本的な発生条件とは関係ないよ 継承元のメソッド実装がオーバーライドされた継承先のメソッドを呼び出せるならFBCPは発生する 当たり前だけどFBCPは実装継承の問題のうちの一つであってすべてではないからね ちなみにトレイトのデフォルト実装も別のトレイトのメソッド経由でメンバ変数やメンバ関数にアクセスできる クラス継承でベースクラスのメソッドがオーバーライドされたメソッド経由でメンバ変数やメンバ関数にアクセスするのと同じ
766 名前:デフォルトの名無しさん mailto:sage [2024/01/24(水) 00:14:41.63 ID:1XOdKji/.net] >>744 イベントループをブラックボックス化したのは 「次のイベント」の種類ごとに分岐する際にifならbool値、switchなら整数のようなものしか 使えない言語の問題をライブラリでなんとかしようとした結果
767 名前:セ [] [ここ壊れてます]
768 名前:デフォルトの名無しさん mailto:sage [2024/01/24(水) 00:16:21.62 ID:X/KtyNlm.net] ついでに言っておくとRustのDeref/DerefMutも実装継承の一種なんだけどこっちはFBCPは発生しない
769 名前:デフォルトの名無しさん mailto:sage [2024/01/24(水) 02:14:43.30 ID:fgSFyL+S.net] >>746 Rustには基底クラスが存在しないため FBCPも含めて実装継承に関する問題は発生しないよ
770 名前:デフォルトの名無しさん [2024/01/24(水) 12:30:29.92 ID:JqKAHMdE.net] 影響力ゼロの人がどれだけオワコンオワコン繰り返しても全く影響無い。
771 名前:デフォルトの名無しさん mailto:sage [2024/01/24(水) 13:30:09.74 ID:1XOdKji/.net] それなら人の力ではなく天変地異の影響を主に想定したほうがいい
772 名前:デフォルトの名無しさん mailto:sage [2024/01/24(水) 16:22:26.10 ID:XaeHtqc/.net] 妻がダイエットのために乗馬を始めたんだけど一ヶ月で10キロ痩せたよ 馬がね
773 名前:デフォルトの名無しさん mailto:sage [2024/01/27(土) 12:58:37.96 ID:mbfTQf92.net] has a関係は被害者と加害者が別人で、責任の連鎖がある 鎖を切って悪い影響を0にする変更はしやすい is aは影響力を不変にする 責任の連鎖をなくして自分自身の責任とする
774 名前:デフォルトの名無しさん [2024/01/27(土) 19:38:08.87 ID:w8m8MtP7.net] 241 伝説の名無しさん sage 2020/10/13(火) 15:00:15.08 「胸がドキドキする」というのはいわば生理現象であり、抑えることはほぼ不可能だ。 月末のクレジットカードの支払額に、想像以上に可愛かったデリヘル嬢のおマンコにと胸を 突かれるのは悪いことではない。 翻って「チンポがシコシコする」というのは能動的な衝動であり、極めて不埒な責任転嫁である。 シコシコはチンポが勝手にやったことであり、決してチンポの持ち主の意向ではないという、どこぞの 政治家の「秘書が勝手にやったこと」のような言い逃れがしばしば聞かれ、あまつさえそれがまかり 通ってきたことは周知の事実である。 チンポからシコシコを奪取し、各人の掌に戻る日は果たしてやってくるのだろうか……。
775 名前:デフォルトの名無しさん mailto:sage [2024/01/27(土) 22:55:15.08 ID:QdyqwSfC.net] 責任という概念自体に違和感を表明する者がよくいるが 馬クラスと動物クラスには責任の擦り合いや利害対立がなさそうなところが共感されるんじゃないか
776 名前:デフォルトの名無しさん [2024/01/27(土) 22:55:50.75 ID:BuZgAgXz.net] 令和になっても継承批判は聞きたくないね 手垢ついてるとかいうレベルじゃないぞ OOPには価値がない OOPのメリットとやらは無意味だ というふうな大きい批判が聞きたい
777 名前:デフォルトの名無しさん mailto:sage [2024/01/27(土) 22:56:54.43 ID:BuZgAgXz.net] あ、>>756 は別に特定のレスにむけたレスじゃなくて ざっくりとした意見ね
778 名前:デフォルトの名無しさん mailto:sage [2024/01/27(土) 23:08:28.46 ID:9xE1RMNT.net] オブジェクト指向は継承という一つの要素が終わっただけだしなあ 未だ現役すぎる
779 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 00:58:58.58 ID:stV8Z8Wq.net] 何らかの違和感の解消がオブジェクト指向のメリットだとするなら 元から違和感などなかった奴にとって無価値である
780 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 03:30:55.01 ID:z8UBzo+x.net] 5chになにを期待してんだかな
781 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 14:48:42.54 ID:EVWA08mD.net] >>756 概念的にはインターフェイスとコンポジションに発展的解消したから、オブジェクト指向はオワコンだろ。
782 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 14:56:56.93 ID:z8UBzo+x.net] インターフェイスもコンポジションも人間が簡易に理解するためのものだろ なめてんのか
783 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 15:18:10.03 ID:gBYyPSdU.net] >>761 それオブジェクトの継承が別の概念に変わっただけでカプセル化とポリモーフィズムは健在じゃん… もっとおもしろいこと言ってくれ…
784 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 16:44:30.08 ID:nAHL+G+L.net] オブジェクト指向プログラミングのコアコンセプトは「データと操作をまとめて一つの型として扱うこと」これだけ オブジェクト指向プログラミングではなくオブジェクト指向言語といった場合は ブーチの定義が普及したせいでカプセル化、ポリモーフィズム(基本はサブタイプポリモーフィズム)、継承の3点セットを基準にすることが多いが 言語機能としての継承はオブジェクト指向プログラミングに必須のものではないし ポリモーフィズムもオブジェクト指向言語特有のものではないので両方ともコアコンセプトではない
785 名前:デフォルトの名無しさん mailto:sage [2024/01/28(日) 17:24:51.96 ID:EVWA08mD.net] >>763 オブジェクトのカプセル化はインターフェイスとデータを密結合するけど、インターフェイスによるカプセル化はデータと密結合しない。 オブジェクトのポリモーフィズムはオブジェクト同士が(継承関係とかで)密結合するけど、インターフェイスは継承関係とかの密接な関係を結ぶこと無しに(理想的には)ダックタイピングで多態できる。 まあ、そこまでのダックタイピングをサポートするインターフェイスとか知らんけど。 c++のコンセプトがそのまま型になったらいいんだけどなぁ。
786 名前:デフォルトの名無しさん [2024/01/28(日) 17:54:19.13 ID:uVCrPT47.net] オブジェクトという言葉と同じでカプセル化という言葉は人によって意味が違うので困る
787 名前:デフォルトの名無しさん [2024/01/28(日) 19:52:00.86 ID:cMZBK/kO.net] 70 名無しヒーリング 2021/04/26(月) 09:45:57.57 ID:jZDy/LpM 先生、実際にシコシコするのは
788 名前:`ンポでなく俺の右手だと思います。 ✖チンポがシコシコする ○ 俺の右手がチンポをシコシコする 71 名無しヒーリング 2021/04/26(月) 09:56:38.18 ID:jZDy/LpM あと、「胸がドキドキする」と「チンポをシコシコする」は比較対象になりません。 「胸がドキドキする」は「チンポがヒリヒリする」のように状態・感覚を擬音語で現しているのであって、 「チンポをシコシコする」は「胸をモミモミする」の様に人間や動物が対象に対して何かを行う行為の表現だと思います。 [] [ここ壊れてます]
789 名前:デフォルトの名無しさん mailto:sage [2024/01/29(月) 09:05:57.54 ID:MhZcn14S.net] くだらない比喩でいつまやってんだ?
790 名前:デフォルトの名無しさん [2024/01/29(月) 15:05:39.33 ID:oNy2vKqL.net] >>767 だからシコシコは男性器を擦る擬音で勃起のことではない 君は女性かな? それともシコシコが勃起を表す地方が日本のどこかにあるのか どっちにしろいくらがんばってもメジャーなコピペになれないのは大多数の人に表現がピンとこないのが原因だと思うよ
791 名前:デフォルトの名無しさん [2024/02/01(木) 21:11:10.96 ID:RS6y7MOu.net] PHPでアブストラクトやりまくってる これやってればいい ここまで来るのに2年かかったわ
792 名前:デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:38:06.66 ID:/UMw8Y/Y.net] 再利用しようにもパーツに分解できない大きなプログラムのスパゲッティ化を防ぐために ひと塊のルーチンを“関数”として入り口出口を決めましょうがカリー化まで続く一方の流れで その塊をどうやって集団として機能に固めたり制御するのかを考えるのがオブジェクト指向 そういう上位レベルでの制御やメンテナンスの汎用的な考えから出てきた概念を 小さいレベルでのプログラムAの脚を車輪に付け替えるにはとか プログラムAの塊を継承してプログラムBにするのが“オブジェクト指向”なんだよ!って 鬼子でしかないC++最初に来ちゃったせいで現代に至るまで あれがオブジェクト指向だと思い込んでるおじいちゃんがですね…
793 名前:デフォルトの名無しさん [2024/02/04(日) 20:30:59.20 ID:owhn6I10.net] おじいちゃん構文丸出しでおじいちゃん批判ww しかも中身が間違いだらけとかwww
794 名前:デフォルトの名無しさん mailto:sage [2024/02/04(日) 21:58:45.40 ID:nqsMiwRK.net] インターフェース楽しいな~ 継承無しでコーディングできる~
795 名前:デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:05:40.25 ID:iyTJzl7x.net] 塊って言いたいだけ
796 名前:デフォルトの名無しさん [2024/02/04(日) 23:11:46.13 ID:SuDI4pWX.net] >ひと塊のルーチンを“関数”として入り口出口を決めましょう これ現役引退してるような世代の方ですよね?
797 名前:デフォルトの名無しさん mailto:sage [2024/02/05(月) 10:19:20.77 ID:z455Qu8w.net] 役割で固めるってのを忘れてる
798 名前:デフォルトの名無しさん mailto:sage [2024/02/05(月) 11:38:56.86 ID:iuJxPrpx.net] 横断的関心事の意味が分からんと常々思っていたけど 役割で固めるのをやめるという意味なのかね 固めようと思ったことがない奴にとっては無意味なことだ
799 名前:デフォルトの名無しさん mailto:sage [2024/02/05(月) 12:31:22.93 ID:29NJAnme.net] 横断的にシコシコする役割の塊がオブシコである
800 名前:デフォルトの名無しさん mailto:sage [2024/02/05(月) 17:30:42.79 ID:UM+1T8m6.net] オブジェクト指向はモジュラリティを高めるために考え出されたものだが「どの抽象化階層のモジュラリティを高めるものなのか」という大前提を理解していないと何を見てもオブジェクト指向だと感じるようになる
801 名前:デフォルトの名無しさん mailto:sage [2024/02/05(月) 23:45:04.18 ID:29NJAnme.net] そりゃオブシコするぐらいだからモジャラリティは高いだろ
802 名前:デフォルトの名無しさん [2024/02/07(水) 14:59:43.29 ID:LJRNIYaK.net] 1. 簡単な言葉を使う 頭が良い人は、複雑なことや専門知識も「簡単な言葉」で説明することができます。 この能力は、深い理解があるからできること。相手が理解しやすいように情報を整理して伝えることは思いやりでもあります。 https://news.yahoo.co.jp/expert/articles/9bb7a62121796847a941127e3d5040008fedd464 クリントン大統領にどんな強大な権限が有っても、自らのチンポがしこしこしてしまうのは止められない! class チンポ extends クリントン{ super.不適切な関係; } クリントンの再定義、クリントンの拡張された人格ということだ!
803 名前:デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:31:45.94 ID:1UgkqCq+.net] 世界一オブジェクト指向に忠実なメインクラスできたで class Main(): def do(): pass m=Main() m.do()
804 名前:デフォルトの名無しさん mailto:sage [2024/02/13(火) 15:11:48.80 ID:g/oXQBQp.net] オブジェクト指向はオワコン 継承はよくない文化
805 名前:デフォルトの名無しさん [2024/02/13(火) 17:38:57.37 ID:TeIoV+iR.net] Template Methodパターン便利ですよ
806 名前:デフォルトの名無しさん mailto:sage [2024/02/13(火) 18:33:53.66 ID:vbRTXFPD.net] has a関係は抽象度の低いクラスを参照することはマナー違反ではない is a関係は自分よりも抽象度低いクラスを継承したらマナー違反だよな
807 名前:デフォルトの名無しさん [2024/02/13(火) 19:00:08.50 ID:mLNp/E4P.net] 継承を理解してれば問題無い 理解していないけどら問題無く使える道具は存在しない つまり須く低レベルということ
808 名前:デフォルトの名無しさん mailto:sage [2024/02/13(火) 19:17:02.49 ID:022XTqy3.net] >>786 俺は使えるから問題ないんだが部下や上司に無能がいると困る 全ての言語で機能ごと消去するべき
809 名前:デフォルトの名無しさん mailto:sage [2024/02/13(火) 19:19:14.84 ID:cHpLMfgk.net] C/C++でいいところを無能のためにRustでわざわざメモリ管理を強制的に縛るのと一緒やね