タグ付けされた質問 「abstract-class」

いくつかのデフォルト/共有機能を持つクラスがあります。私abstract classはそれを使用します： public interface ITypeNameMapper { string Map(TypeDefinition typeDefinition); } public abstract class TypeNameMapper : ITypeNameMapper { public virtual string Map(TypeDefinition typeDefinition) { if (typeDefinition is ClassDefinition classDefinition) { return Map(classDefinition); } ... throw new ArgumentOutOfRangeException(nameof(typeDefinition)); } protected abstract string Map(ClassDefinition classDefinition); } ご覧のとおり、インターフェイスもありますITypeNameMapper。私がすでに抽象クラスを持っているTypeNameMapperか、それでabstract class十分な場合、このインターフェイスを定義するのは理にかなっていますか？ TypeDefinition この最小限の例でも抽象的です。

12 c#  interfaces  abstract-class 

最近、使用しているOSSの抽象基本クラスを更新して、仮想化することでテストしやすくしました（2つを組み合わせたインターフェイスを使用できませんでした）。これにより、仮想に必要なすべてのメソッドをマークするか、すべてのパブリックメソッド/プロパティを仮想にマークする必要があるかを考えるようになりました。私は一般的に、すべての方法を仮想化する必要があるというロイ・オセロベに同意しますが、これが必要かどうかについて考えさせられるこの記事に出会いました。ただし、簡単にするためにこれを抽象クラスに限定します（具体的なパブリックメソッドがすべて仮想であるべきかどうかは、特に議論の余地があります）。 サブクラスがメソッドを使用できるようにするが、実装をオーバーライドしたくない場所を確認できました。しかし、リスコフの代替原則に従うことを信頼している限り、オーバーライドすることを許可しないのはなぜですか？抽象としてマークすることで、とにかく特定のオーバーライドを強制しているので、抽象クラス内のすべてのパブリックメソッドは実際に仮想としてマークする必要があるように思えます。 しかし、私が考えていないかもしれない何かがある場合に備えて尋ねたいと思いました。抽象クラス内のすべてのパブリックメソッドを仮想化する必要がありますか？

12 c#  abstract-class 

組み込みデバイスの状態パターンでコーディングしています。Stateと呼ばれる基本/抽象クラスがあり、各離散（コンクリート）状態クラスが抽象状態クラスを実装します。 Stateクラスには、いくつかの抽象メソッドがあります。ディスクリート（コンクリート）クラスに抽象メソッドを実装しない場合、Visual Studioは次のようなエラーを出します。 ...エラー1 'myConcreteState'は継承された抽象メンバー 'myAbstractState'を実装していません さて、StateNameというStateごとにStringプロパティを作成しようとしています。新しい具象クラスを作成するときはいつでも、StateNameを定義する必要があります。使用しない場合はVSでエラーをスローする必要があります。これを行う簡単な方法はありますか？ 私は抽象/基本クラスでこれを試しました： public abstract string StateName { get; set; } ただし、各状態にGetメソッドとSetメソッドを実装する必要はありません。 改訂された質問：理想的な状況では、各Stateクラスは、StateNameを定義して抽象基本クラスから継承する必要があります。 StateName = "MyState1"; //or whatever the state's name is そのステートメントがない場合、Visual Studioは上記のエラーを生成します。これは可能ですか？可能な場合、どのようにですか？

10 c#  design-patterns  visual-studio  abstract-class 

最近、抽象クラスの使用について困っています。 時々、抽象クラスが事前に作成され、派生クラスがどのように機能するかのテンプレートとして機能します。つまり、多かれ少なかれ、それらはいくつかの高レベルの機能を提供しますが、派生クラスによって実装される特定の詳細を除外します。抽象クラスは、いくつかの抽象メソッドを配置することにより、これらの詳細の必要性を定義します。そのような場合、抽象クラスは設計図、機能の高レベルの説明、またはそれと呼ぶもののように機能します。単独では使用できませんが、高レベルの実装から除外された詳細を定義するために専門化する必要があります。 場合によっては、いくつかの「派生」クラスの作成後に抽象クラスが作成されることがあります（親/抽象クラスがそこにないため、それらはまだ派生されていませんが、私が何を意味するか知っています）。これらの場合、抽象クラスは通常、現在の派生クラスに含まれるあらゆる種類の共通コードを配置できる場所として使用されます。 上記の観察をしたので、私はこれらの2つのケースのどちらがルールであるべきか疑問に思っています。派生クラスすべてに共通しているという理由だけで、抽象クラスに詳細を吹き込む必要がありますか？高レベルの機能の一部ではない一般的なコードがありますか？ たまたま派生クラスに共通しているからといって、抽象クラス自体には意味がないコードが存在する必要がありますか？ 例を挙げましょう。抽象クラスAにはメソッドa（）と抽象メソッドaq（）があります。メソッドaq（）は、派生クラスABとACの両方で、メソッドb（）を使用します。b（）をAに移動する必要がありますか？もしそうなら、誰かがAだけを見ている場合（ABとACがそこにないふりをしよう）、b（）の存在はあまり意味がありません！これは悪いことですか？誰かが抽象クラスを見て、派生クラスにアクセスせずに何が起こっているのかを理解できる必要がありますか？ 正直なところ、この質問をしている時点で、派生クラスを調べなくても意味のある抽象クラスを書くことは、クリーンなコードとアーキテクチャの問題だと信じがちです。anyあらゆる種類のコードのダンプのように機能する抽象クラスのアイデアが、すべての派生クラスで一般的に発生するのを嫌う あなたはどう思いますか/練習しますか？

9 object-oriented  clean-code  abstract-class 

抽象クラスがあり、このクラスに抽象メソッドのみがあるとします。この抽象クラスは、同じメソッドのみを持つインターフェースとは異なりますか？ 私が知りたいのは、抽象的メンバーのみを持つ抽象クラスと同等のインターフェイスの間に、哲学的、客観的、および基礎となるプログラミング言語の実装に違いがあるかどうかです。

9 programming-languages  object-oriented  interfaces  abstract-class 

多くの場合、オブジェクトのインターフェイスを分離するための抽象基本クラスを用意することをお勧めします。 問題は、C ++ではデフォルトでコピー構築であるIMHOがかなり壊れており、コピーコンストラクターがデフォルトで生成されていることです。 では、抽象基本クラスと派生クラスに生のポインタがある場合の落とし穴は何ですか？ class IAbstract { ~IAbstract() = 0; } class Derived : public IAbstract { char *theProblem; ... } IAbstract *a1 = new Derived(); IAbstract a2 = *a1;//??? そして、階層全体のコピー構築を完全に無効にしますか？コピー構造をプライベートとして宣言しますIAbstractか？ 抽象基本クラスで3つのルールはありますか？

9 c++  abstract-class 

私が持っているabstract class A抽象メソッドを宣言しているがdoStuff。現在、を継承しAて実装するクラスが多数ありますdoStuff。 クラスのインスタンスはAFactory、ユーザー入力に基づいて実行時に初期化されます。元々、すべてのクラスには同じ単一のパラメーター（ユーザー入力）がありました。しかし今、私はAニーズを継承する新しいクラスだけである追加のパラメーターを持っています。 だから私はそれを次のロジックで分解します： ユーザー入力（AFactoryもちろん使用）に基づいてインスタンスを生成するインタープリタークラスは、この追加のパラメーターを認識していませんでした。 それをクラスインタープリタクラスにプッシュしようとすると、本当に厄介なことになります。それは、いつファクトリーに渡すかを知らなければならず、そもそもファクトリーを持つという全体の目的に反するためです。 それを何かに使うかもしれないと期待して盲目的にファクトリーに送ることも、かなり醜いようです。 私の現在の解決策：一方、にリファクタリングA.doStuff(Param param)することにしましたA.doStuff(AParams params)。 AParams必要なパラメータをすべて保持doStuffでき、興味がない場合は無視できます。これは私にとっても少し厄介なようで、WIN32APIで構造体を送信することを抑制します。この構造体は、醜く役に立たない多くのパラメーターを保持する可能性があり、私はそれが好きではありません。 この問題に取り組むよりエレガントな方法はありますか？それとも私が見落とし、これを解決したいくつかのデザインパターン？ 注： Java 1.7を使用しています クラスの名前は、理論上の設計上の問題を強調するためにばかげていますが、実際には、わかりやすく意味のある名前が付けられています。 私はかなり多くのことを検索しましたが、（このコードをXスローしている理由とは対照的に）特定の抽象的な理論的な問題をWebで検索するのは非常に難しいことがわかったExceptionので、とにかく尋ねることにしたので、これが複製。 編集1： 明確化：サブクラス固有の引数をdoStuffメソッドに渡す必要があります。 編集2： 私はKilian Fothの意図を完全には理解していなかったので、問題をよりよく説明し、解決策を理解するのに役立つJava疑似コードをいくつか書きました。そう： これは私の問題の骨組みです。 これは私のソリューションの骨組みです。 これは キリアンフォスの解決策かもしれないと思いますが、よくわかりません。

8 java  design  design-patterns  abstraction  abstract-class 

再利用できるように手直ししているJavaコードがかなりあります。問題は、プロジェクト固有の部分が多く、アプリケーションプロジェクトとコードベースプロジェクト間の結合のレベルが高くなることです。 抽象メソッドの使用を実装するクラスを使用して子クラスからリソースを取得する以下の状況と、インスタンス変数を宣言するだけの状況と比較してください。 抽象メソッド： public abstract class SuperBaseClass { public abstract int getNumberOne(); public abstract String getStringOne(); public abstract String getStringTwo(); public printStuff() { Log.i("IntAndTwoStrings", String.format("%i %s and %s", getNumberOne(), getStringOne(), getStringTwo())); } } public class ReusedAppClass extends SuperBaseClass { public int getNumberOne() { return 1; } public String getStringOne() { …

8 java  architecture  code-reuse  abstraction  abstract-class