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

1 名前：デフォルトの名無しさん mailto:sage [2023/08/26(土) 22:00:53.85 ID:H4l7y46b.net] 最近の言語には採用されないことが増えている 666 名前：デフォルトの名無しさん [2024/01/19(金) 11:50:05.51 ID:iTaoyDeQ.net] >>647 最新調査でPythonが人気なのと、Pythonが多重継承をサポートしているのは、どう説明するのかな？ 667 名前：デフォルトの名無しさん [2024/01/19(金) 12:04:44.60 ID:iTaoyDeQ.net] 集約と継承を使い分けることが大切ね！ >>623 >欲しかったのはバナナだけなのに、あなたが得たのはバナナを持っていたゴリラと、ジャングル全体だった。 ジャングルーーーーーーーーーー ┃　ゴリラーーーー　　　　　┃　　　　　　　　┃ ┃　バナナ ┃　　　　　┃　　　　 ┃　ーーーーーーー　　　　　┃　　　　　　　 ┃　　　　　　　　　　　　　┃ ーーーーーーーーーーーーーーー クリントンーーーーーーーーーー ┃　　　　　　　　　　　　　┃ ┃　　　　　　　　　　　　　┃ ┃　　　　　　　　　　　　　┃ ┃　　　　　　　　　　　　　┃ ┃　　　　　　　　　　　　　┃ ーーーーーーーーーーーーーーー 　　　　　┃ﾁﾝﾎﾟ┃ 　　　　　￣￣￣￣ 668 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:26:06.50 ID:SK8TlxrV.net] >>631 多態性・情報隠蔽ですら無くて、単にインスタンス間でやり取りするときのインターフェイスとプロトコルを確定しておきたいだけだよ。 継承みたいなコンパイラ都合のお作法はうざったいだけだし、インターフェイスとプロトコルを守っているなら多態かどうかもどうでもいい。結果的に多態になるけど、あくまで結果論。 669 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:31:42.38 ID:arzVgFZ3.net] >>648 pythonで複雑なシステムは普通の感性を持ってれば組まないし別にいいんじゃない？ 継承がゴミだと言われる理由を考えてみて 670 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:38:25.66 ID:SK8TlxrV.net] オブジェクト指向がオワコンというのは正しくて、よりインスタンス間のルール管理に注力した契約プログラムとかに発展的解消してんじゃないのかね。 671 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:44:39.23 ID:arzVgFZ3.net] >>650 インスタンス間でやり取りするときのインターフェイスとプロトコルを確定（カプセル化）することがまさしく不要な情報の隠蔽なのでは？ それでカプセル化したらポリモーフィズムに基づいてアクセスさせるか～みたいな感じでしょ？ 672 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:45:36.30 ID:arzVgFZ3.net] そんでカプセル化したものを継承させるのはプログラムが煩雑になるからやめましょうよ、継承の実装を省くならクラスもいらないねってそういう話じゃん 673 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:52:25.37 ID:rg+QtK0B.net] >>646 多重継承の中でも型継承さえできれば十分ならインターフェースでよくね？ それなら他の言語でもできるぞい✌ 674 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 12:54:01.11 ID:SK8TlxrV.net] >>653 そう、そう。 実装の結果ついてきた結果論。 スタートはインターフェイスとプロトコル。 675 名前：デフォルトの名無しさん [2024/01/19(金) 12:54:57.24 ID:iTaoyDeQ.net] オンラインゲームのアップデートは「カプセル化したものを継承」では？ >>654 >そんでカプセル化したものを継承させるのはプログラムが煩雑になるからやめましょうよ、 大型アップデート情報 バージョン6.5[後期]　（2023/11/21 更新） https://hiroba.dqx.jp/sc/topics/detail/0e4f5cc9f4f3f7f1651a6b9f9214e5b1/ システムのアップデートは一般的に「継承」と自分は思うが、丸ごと作り直したほうが良いのかな？ 676 名前：デフォルトの名無しさん [2024/01/19(金) 13:07:12.61 ID:iTaoyDeQ.net] 私見としてはオンラインゲームと言えども、大型バージョンアップ時は丸ごと作り直したほうがいいと思う ドラクエ10のバージョン7ということなら、すべてを再インストール化でもいい 677 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 13:15:20.79 ID:arzVgFZ3.net] >>657 オンラインゲームのアップデートってなに？もっと具体的に頼む バグ修正？新機能の追加？新キャラの追加？ バグ修正や新機能はカプセル化の対応部分の丸ごと書き換え等いろいろあるだろうね 新キャラ追加はカプセル化したクラスモデルを継承して作り上げて、それをロードしてやれば、ポリモーフィズムに基づいて動いてくれるだろうね 678 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 13:17:20.00 ID:2+ ] [ここ壊れてます] 679 名前：AapLKd.net mailto: さすがにアプデを継承と考えるのはややこしくなるからやめたほうがいい [] [ここ壊れてます] 680 名前：デフォルトの名無しさん [2024/01/19(金) 13:25:42.10 ID:iTaoyDeQ.net] >>659 >オンラインゲームのアップデートってなに？もっと具体的に頼む オンラインゲームというのは、リリース後も次々とアップデートを繰り返し、機能が増えていきます。 よって、一番最初の設計で、どれだけ未来の変化を予測して、準備しておけるかが大事になってきます。 後になって苦しまないために、最初は多少面倒でも、柔軟でわかりやすい、変化に耐えうる設計を心がけたいものです。 https://developer.aiming-inc.com/programming/design-battle-program/ オブジェクト指向を初めて勉強していたころ、クラスの継承は（個人的には）理解しやすかったですが、 インターフェースはいまいち利点が分かりづらい印象がありました。 そこで、デザインパターンのひとつ「Observerパターン」を取り上げて、 継承とインターフェースの使用法を見ていきます。Observerパターンは先ほどの一斉攻撃にも近いパターンになります。 https://qiita.com/kcpoipoi/items/e6c495e7a481e02847d8 681 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 14:00:28.63 ID:arzVgFZ3.net] >>661 うん、新キャラ新技はカプセル化の継承だね そんな表面層の部分を指して継承だ継承だ騒いでたの？ 682 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 14:14:12.14 ID:arzVgFZ3.net] あ、継承をゴミと言ってるのであって、インターフェースやトレイトは存分に使うべきものだから 勘違いしてもらったら困るぞ 683 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 14:21:52.28 ID:arzVgFZ3.net] 新キャラ新技くらいならカプセル化の継承でもなくてインターフェースをただ実装するだけで済ませてるか>>661 自分の作品見てたら画面追加は継承を使ってたわ 684 名前：デフォルトの名無しさん [2024/01/19(金) 14:23:53.15 ID:2Txscu7W.net] >>663 継承自体はただの機能なので良いも悪いもない。 継承を理解していない人、不適切な使い方をしている人が存在するだけ。 どんな使い方をしても不具合が出ない機能なんて無い。 685 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 14:33:48.49 ID:arzVgFZ3.net] >>665 大いに同意 継承は基底クラスがよほど煩雑にならない程度なら使ってもよい ただ煩雑に組む輩等が多すぎたから継承を実装しないプログラム言語が生まれた それだけなんだ 686 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 14:51:07.26 ID:2+AapLKd.net] お勉強発表会はたのちいね 687 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 14:54:55.85 ID:arzVgFZ3.net] >>667 むちゃくちゃ楽しい 688 名前：デフォルトの名無しさん [2024/01/19(金) 14:59:58.61 ID:2Txscu7W.net] >>667 と暇人が申しております 689 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 17:41:08.81 ID:wxu2zgr7.net] >>665 継承は設計を初期の段階で固める「早すぎる最適化」だから避けるべき。 やるなら継承関係の実装だけ切り出したadapter用のholder templateを用意したほうがまだマシ。 690 名前：デフォルトの名無しさん [2024/01/19(金) 18:11:39.79 ID:Hi84WC+x.net] >>670 それは将来の変更可能性が低くない場合。 実際変更可能性が低いケースなんかいくらでもあり、その場合避ける理由にならない。 691 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 18:21:46.43 ID:9QtN1Vnk.net] >>670 つまりinterfaceで十分ってことだな 692 名前：デフォルトの名無しさん [2024/01/19(金) 19:20:32.13 ID:iTaoyDeQ.net] 　　　　＿w　　　　　　　　　　　、...　　　ｮ　　┌┐　　　　　ｨ　　　　　′　　 　　　￣＋　　　　　ﾍe、　　　j｢.　　.￢气￢''..~''~　　　　,．ﾙw、.ｰu、す　　　　　 　　^^"~~l|~~^'''　　　　　　　ｫ′　　　.,.　l|　┐　　　　　　.√　j|　　_~+,.、.　 　.　　　.,/.　　　　　　ょ＿／　　　　､j｢　｛　　`￢..　　　〃　.、l|　　　　､　　 　..　　~＾.　　　　　　　　　　　　　　　~　　`　　　　　　　　　　~＾　　　　　　 　.　　；.　　　　　　　　　　　　　　　　　ｮ　　　　　　　　　＿_　　　　　　 　.　　j|　　　　　　　~ラ￢￢+　　　　　|.　　　　　　　￣.　　￣..　　　　 　.　　ｵ　　　　　　　　　　　　　　　　　｜..　　　ｫ　　　　　　　　,､　　 　　　　k、　,j〃.　　　Ｌ＿.　　_ｪ　　　　~'――'~.　　　^^^^^^￣´　　　　 　　　　　￣′　　　　　　￣￣　　　　　　　　　　　　　　　　　　　　　　　　 693 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 19:28:18.36 ID:r1TqRAYd.net] 一人で書き込みお疲れ様。 694 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 19:43:32.99 ID:SK8TlxrV.net] >>671 熟練の設計者が慣れた問題領域やるんでもなければ無理だろ。 695 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 19:52:40.51 ID:SK8TlxrV.net] >>672 だいたいインターフェイスで十分だわ。もっと機能強化したのが出てこないかね。 c++のコンセプトをインターフェイスに使いたいところ。 696 名前：デフォルトの名無しさん [2024/01/19(金) 20:09:04.02 ID:XrKZZkrv.net] >>675 超大型建築より普通の一軒家の方が数、つまりニーズが圧倒的に多い アプリは常にスケールする可能性がある、というのは理論的な話で実際スケールするアプリなんかほんの一握り。結局作ってそのままなんていくらでもある。変更が無いケースで熟練どうたらとか全く無関係。 697 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 20:34:16.00 ID:SK8TlxrV.net] >>677 普通の一軒家とか、問題領域の知識が無くて失敗する事例の宝庫だろ。あとになって大抵の人間は「コンセントが足りない」と言うしな。 変更しないままなのは「変更しなくていい」じゃなくて「変更は不可能に近いから不便・危険でも諦める」だからな。 698 名前：デフォルトの名無しさん [2024/01/19(金) 20:49:36.09 ID:XrKZZkrv.net] 結局継承で都合が悪いケースなんて極一部というのが現実。 ヤグニの原則に反して嬉しいのは客の金でただで勉強・実験したいエンジニアだけ。 699 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 21:05:02.67 ID:SK8TlxrV.net] >>679 まあ、いいんじゃない？ 初期に設計したクソ仕様を客に「大したことはないから変更しない」と放置できるなら。 700 名前：デフォルトの名無しさん [2024/01/19(金) 21:27:25.19 ID:K5SD+kWD.net] >>672 インターフェースだけだとコピペ継承が乱立するんだよ そこでインターフェースのデフォルト実装等クラス継承と同じ実装継承を使うことになる でもクラス継承はとにかく悪だと思ってる人は実装継承のメリットとデメリットを正しく理解できてないから結局同じ問題を引き起こすだけ 701 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 22:05:02.77 ID:yy9dhl7c.net] >>681 インターフェイスと実装は永続性や影響範囲が違うんだから、密に関連づけるのは悪設計。 継承はさらに基底と派生の関係性もガチガチに固めるから、根元になる基底がクソ設計だとどうしようもない。 702 名前：デフォルトの名無しさん [2024/01/19(金) 22:20:13.70 ID:XrKZZkrv.net] >>680 5chで勝手にクソ仕様認定してるクソレスを気にする人はいないw 703 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 22:21:58.98 ID:sTJV5iPD.net] 顧客に設計なんか分からないから突き進むだろ 704 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 22:22:17.78 ID:EWU8L+d2.net] >>681 その点ではRustのtraitが最も良いね Rustのtraitでのデフォルト実装は各型のメンバーや固有メソッドを呼び出せないので実装継承の問題が起きない そのtrait(とそのtrait制約)のメソッドしか呼び出せないから移譲と合成の形になる 705 名前：デフォルトの名無しさん [2024/01/19(金) 22:54:39.62 ID:2Txscu7W.net] >>685 こういう感じで言語によって前提が違う場合があるから抽象的な議論の有効性はかなり微妙 706 名前：デフォルトの名無しさん [2024/01/19(金) 23:13:57.01 ID:k/iqMx14.net] >>685 はい残念 Traitのデフォルト実装も実装継承だからクラス継承のデメリットの大半を”継承”してる メリットとデメリットを理解して使い分けられるようにならないうちは結局のところ何使っても同じ 707 名前：デフォルトの名無しさん mailto:sage [2024/01/19(金) 23:19:40.83 ID:EWU8L+d2.net] >>687 いいえ 説明したようにRustのtraitに実装継承はありません 708 名前：デフォルトの名無しさん [2024/01/19(金) 23:28:42.74 ID:2Txscu7W.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なら整数のようなものしか 使えない言語の問題をライブラリでなんとかしようとした結果�

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef