タグ付けされた質問 「inheritance」

動的言語のミックスインよりも継承パターンを好むのはいつですか？ ミックスインとは、実行時に関数とデータメンバーをオブジェクトに挿入する場合のように、実際に適切にミキシングすることを意味します。 たとえば、いつミックスインの代わりにプロトタイプ継承を使用しますか？mixinが意味することをより明確に説明するために、いくつかの疑似コードを示します。 asCircle(obj) { obj.radius = 0 obj.area = function() { return this.radius * this.radius * 3.14 } myObject = {} asCircle(myObject) myObject.area() // -> 0

19 javascript  inheritance  mixins 

MeyerのObject-Oriented Software Construction（1988）で、彼は次のようにオープン/クローズド原則を定義しています。 モジュールがまだ拡張可能であれば、モジュールは開いていると言われます。たとえば、フィールドに含まれるデータ構造にフィールドを追加したり、実行する一連の機能に新しい要素を追加したりすることができます。 モジュールは、他のモジュールで使用できる場合、閉じられていると言われます。これは、モジュールに明確に定義された安定した説明（情報隠蔽という意味でのインターフェース）が与えられていることを前提としています。 彼は言い​​続けます： モジュールを再度開く場合、古いバージョンに依存しているため、すべてのクライアントを再度開いて更新する必要があります。…[この問題]は、モジュールを新しい関数またはデータ要素によって拡張する必要があるたびに発生し、直接および間接クライアントの変更をトリガーします。...設計とプログラミングに対する古典的なアプローチでは、オープンとクローズの両方のモジュールを記述する方法はありません。 このジレンマに対するMeyerの解決策は、既存のクラスを変更してライブラリモジュールを拡張しないことです。代わりに、既存のクラスをサブクラス化する新しいモジュールを作成し、新しいクライアントがその新しいモジュールに依存するようにします。 今、1988年に、私はTurbo PascalとBlankenship Basicでおもちゃ（手続き）プログラムを書いていました、そして、21世紀の専門的な経験はJVM、CLR、および動的言語でしたので、Meyerの意味がわかりません「設計とプログラミングへの古典的なアプローチ」による。 Meyerのクライアントモジュールを再度開く必要がある理由の具体例（より多くのケースを必要とする、より多くのメンバーを含む列挙のswitchステートメント）は十分に合理的なようですが、ライブラリに機能を追加するたびにアサーションを正当化することはほとんどありませんモジュール、すべてのクライアントを更新する必要があります。 この主張が1988年に自明であると思われる歴史的な理由はありますか？たとえば、C静的ライブラリに関数またはデータ構造を追加すると、下位互換性のあるAPIでもクライアントを再コンパイルする必要があるようにレイアウトが変更されましたか？または、MeyerはAPIの下位互換性を強制するメカニズムについて本当に話しているだけですか？

19 object-oriented-design  inheritance  backward-compatibility  open-close 

OOPの特定の失敗は、Rectangleを継承するクラスSquareで示されます。論理的には、SquareはRectangleの特殊化であるため、Rectangleから継承する必要がありますが、Squareの長さまたは幅を変更しようとすると、すべてがバラバラになります。 そのケースで何が問題になっているのかを説明する特定の用語はありますか？

18 object-oriented  inheritance  liskov-substitution 

Railsアプリケーションでは、通知を追加しています。これらの一部は次のとおりblockingです。リソースに関する情報が欠落しているため、追加されたリソースの進行を停止します。 他の通知は単純な通知であり、情報のみを提供します。 今日、私たちのチームの別のプログラマーと話し合いました。次のような継承構造を作成しました。 しかし、彼は、blocking各通知にブール値を返すメソッドとして追加し、通知親クラス内でブロックしているサブクラスのリストを指定したいだけです。 これらのアプローチの違いはそれほど大きくありません。私のアプローチでは、このリストを指定する必要はなく、ルートクラスをよりクリーンに保ちます。一方、Notification::Blocking現在発生している特別なロジックもそれほど大きくありません。 この問題には、どのような抽象化がより適していますか？

18 object-oriented  inheritance  ruby-on-rails 

現在、2つの派生クラスがAあり、B、両方に共通のフィールドがあり、基本クラスに入れるかどうかを判断しようとしています。 基本クラスから参照されることはありません。また、道路のある時点で別のクラスが派生した場合C、を持たない場合、_field1「最低特権」（または何か）のプリンシパルは違反されませんだった？ public abstract class Base { // Should _field1 be brought up to Base? //protected int Field1 { get; set; } } public class A : Base { private int _field1; } public class B : Base { private int _field1; } public class C : Base { // …

16 object-oriented  inheritance  abstract-class 

Javaには、メソッドに使用可能な4つのアクセス修飾子があります。 public -すべてのクラスがこのメソッドを使用できます。 protected -同じパッケージ内のクラスおよび任意のパッケージ内のサブクラスは、このメソッドを使用できます。 private -このクラスのみがこのメソッドを使用できます。 no modifier （ "package private"）-同じパッケージ内のクラスのみがこのメソッドを使用できます。 よく起こるのは、すべてのサブクラスが使用できる便利なメソッドをスーパークラスに入れたいということです。しかし、他のクラスがこのメソッドにアクセスすることは意味がなく、ある意味ではカプセル化を破ります。 したがって、これらの便利なメソッドをスーパークラスpublicまたはで宣言するprotected必要があります。これにより、少なくともパッケージ内の他のすべてのクラスに公開されます。それらはサブクラスによってのみ使用されることを意図していますが。 subclasses-onlyJavaにアクセス修飾子がない理由はありますか？私にはとても奇妙に思えます。何か不足していますか？ また、subclasses-onlyアクセス修飾子は、サブクラスにのみ変数を公開する場合にも役立ちます。私にはこれがよく起こります。

16 java  object-oriented  inheritance  language-features 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 OOPの継承の概念を説明しようとする場合、一般的な例は哺乳類の例です。私見、これは本当に悪い例です。なぜなら、初心者がこの概念を間違った方法で使用するようになるからです。さらに、彼らが日々のデザインの仕事で直面するのは一般的なデザインではありません。 それでは、継承を使用して解決される素敵でシンプルで具体的な問題は何でしょうか？

16 design-patterns  object-oriented  inheritance 

この答えに触発された： リスコフの代替原則では 、 サブタイプでは前提条件を強化できません。 サブタイプでは事後条件を弱めることはできません。 スーパータイプの不変式は、サブタイプに保存する必要があります。 履歴制約（「履歴ルール」）。オブジェクトは、そのメソッド（カプセル化）によってのみ変更可能と見なされます。サブタイプはスーパータイプには存在しないメソッドを導入する可能性があるため、これらのメソッドの導入により、スーパータイプでは許可されないサブタイプの状態変更が可能になります。これは履歴制約により禁止されています。 これらの4つのポイントに違反するクラス階層を誰かが投稿し、それに応じてそれらを解決する方法を誰かが投稿することを望んでいました。 階層内の4つのポイントのそれぞれを識別する方法と、それを修正する最良の方法について、教育目的で詳細な説明を探しています。 注： 私は人々が作業するためのコードサンプルを投稿したいと思っていましたが、問題自体は障害のある階層を特定する方法に関するものです:)

14 object-oriented  inheritance  solid  design-principles  liskov-substitution 

今日、私は基本的protectedにC ++コードでメソッドを使用しないことに気付きました。親の非パブリックメソッドを呼び出す必要性をほとんど感じないからです。テンプレートメソッドパターンではJavaでprotectedを使用していますが、C ++でプライベートメソッドをオーバーライドできるため、ここでも必要protectedありません。 それではprotected、C ++コードでメソッドを使用する実際のシナリオは何ですか？ （私は一般的に実装の継承があまり好きではないことに注意してください、それは多くを説明するかもしれません...）

14 c++  object-oriented  inheritance  access-modifiers 

このページは、次の引数を使用して継承よりも構成を推奨しています（私の言葉で言い換えます）。 サブクラスでオーバーライドされていないスーパークラスのメソッドのシグネチャの変更により、継承を使用するときに多くの場所で追加の変更が発生します。ただし、Compositionを使用する場合、必要な追加の変更は1つの場所であるサブクラスのみです。 それが本当に継承よりも構成を優先する唯一の理由ですか？その場合、サブクラスが実装を変更しない（つまり、サブクラスにダミーのオーバーライドを設定する）場合でも、スーパークラスのすべてのメソッドをオーバーライドすることを推奨するコーディングスタイルを適用することで、この問題を簡単に軽減できるためです。ここに何かが足りませんか？

13 object-oriented  inheritance  composition 

共通の基本型の別のクラスをラップするクラスがあります。基本型インターフェースは非常に大きいため、これには多くのパススルー関数の作成が含まれます。これを回避する方法を探しています。 例を作りましょう： Car / \ Volvo VolvoWithTrailer ここで、VolvoWithTrailerの車のインターフェイスにすべての関数を実装し、ラップされたVolvoオブジェクトで適切な関数を呼び出す必要があります。ただし、GetMaxSpeed（）は、より低い値を返します。基本的に次のような多くの機能があります int VolvoWithTrailer::GetNumSeats() { return mVolvo.GetNumSeats() } これを解決する明白な方法は、VolvoWithTrailerをVolvoのサブクラスにすることです。 Car | Volvo | VolvoWithTrailer しかし、それは継承よりも構成を優先するという原則に違反しているようです。 これらのすべてのラッパー（言語はC ++）を書くことを他にどのように回避できますか？または-それがあなたの立場である場合-なぜ私はそれらを書くだけですか/単に継承を使用するのですか？これに役立つテンプレートの魔法はありますか？

13 c++  inheritance  templates  composition 

私は自分自身にソフトウェア工学を教えようとしていますが、私を混乱させる矛盾する情報に出くわします。 私はOOPと抽象クラス/インターフェースとは何か、そしてそれらをどのように使用するかを学びましたが、「継承よりも合成を優先する」べきだと読んでいます。構成とは、あるクラスが別のクラスのオブジェクトを構成/作成して、その新しいオブジェクトの機能を利用/対話することです。 だから私の質問は...抽象クラスとインターフェイスを使用しないはずですか？抽象クラスを作成せず、その抽象クラスの機能を具象クラスで拡張/継承し、代わりに、新しいオブジェクトを作成して他のクラスの機能を使用するだけですか？ または、構成を使用し、抽象クラスから継承することになっています。両方を一緒に使用しますか？もしそうなら、それがどのように機能し、その利点のいくつかの例を提供できますか？ 私はPHPに最も慣れているので、他の言語に移り、新しく習得したSEスキルを移転する前に、それを使用してOOP / SEスキルを向上させています。

13 object-oriented  php  interfaces  inheritance  composition 

次のコードはメモリリークを引き起こします。 #include <iostream> #include <memory> #include <vector> using namespace std; class base { void virtual initialize_vector() = 0; }; class derived : public base { private: vector<int> vec; public: derived() { initialize_vector(); } void initialize_vector() { for (int i = 0; i < 1000000; i++) { vec.push_back(i); } } }; …

12 c++  inheritance  memory  allocation 

オプションのフィールドを持つクラスの場合、継承またはnull許容プロパティを使用する方が良いでしょうか？この例を考えてみましょう： class Book { private String name; } class BookWithColor extends Book { private String color; } または class Book { private String name; private String color; //when this is null then it is "Book" otherwise "BookWithColor" } または class Book { private String name; private Optional<String> color; //when isPresent() …

12 java  inheritance  class  null 

空のインターフェースは、私が知る限り、一般的に悪い習慣と見なされます-特に属性のようなものが言語によってサポートされている場合。 ただし、他のインターフェイスから継承する場合、そのインターフェイスは「空」と見なされますか？ interface I1 { ... } interface I2 { ... } //unrelated to I1 interface I3 : I1, I2 { // empty body } 実装があることは何もI3実装する必要がありますI1とI2、および継承があること、異なるクラスのオブジェクトI3、その後（下記参照）を交換可能に使用することができるが、それは右呼び出すことですI3 空の？もしそうなら、これをアーキテクチャ化するより良い方法は何でしょうか？ // with I3 interface class A : I3 { ... } class B : I3 { ... } class Test { void foo() …

12 interfaces  inheritance