問題タブ [abstract-class]

Start()ここでの問題は、オブジェクトを派生クラスに渡したいということですが、基本クラスはオブジェクトを使用する派生クラスのメソッドをすぐに呼び出すため、基本クラスのコンストラクターの前に行う必要があります。

以下は、基本クラスからの抜粋です (便宜上、 BarcodeScannerから名前が変更されています)。

これが私が作成している派生クラスです。

基本コンストラクターの前に派生コンストラクターを C# で実行できるとは思えません。オブジェクトが使用される前に、オブジェクトを派生クラスに渡すためのソリューションを本当に探しています。

MyDerivedコンストラクター内に Initialize/Start if ブロックを配置することで、これを回避しました。ただし、基本クラスから派生する他のクラスがあります。そのため、すべての派生クラスでこの初期化/開始コードのブロックを繰り返さなければならなくなりました。基本クラスを変更する代わりの方法を知りたいです。

いくつかの異なるケースタイプのハンドラーを作成する必要があります（Pythonで）。これらすべてのタイプのインターフェースは同じですが、処理ロジックが異なります。

1つのオプションは、特定のハンドラータイプを__init__パラメーターの1つとして受け取る共通クラスを定義することです。

ただし、これによりTypeErrorが発生します。

TypeError：バインドされていないメソッドhandleStuff（）は、最初の引数としてHandler_Case1インスタンスを使用して呼び出す必要があります（代わりにタプルインスタンスを取得します）

もう1つのオプションは、次に示すように、抽象関数を模倣することです（ "Q：Pythonで抽象クラスを0行のコードで実装できますか？"）：

したがって、実際には、2つの質問があります。

1. 2つのアプローチのどちらがよりPythonicですか？と
2. 最初のものを実装する方法は？

C# では、いつインターフェイスを使用し、いつ抽象クラスを使用する必要がありますか? 何が決定的な要因になり得るでしょうか？

LINQ to SQL クラスの部分クラスで継承できる抽象クラスを作成しています。LINQ to SQL クラスには、組み込みの部分メソッドが多数含まれています。抽象クラスに 1 つ以上の部分メソッドを実装する方法はありますか? 部分メソッドは部分クラスまたは構造体にのみ含めることができることを知っています。きっと何か別の方法があるに違いない。

詳細は次のとおりです。

• News というデータベース テーブルがあるとします。このテーブルを含む LINQ to SQL dbml ファイルを作成すると、自動生成されたコードによって News の部分クラスが生成されます。
• この部分クラスには、いくつかの部分メソッドが含まれています。
• すべての LINQ to SQL クラスで使用したいいくつかのメソッドを含む、作成中のクラスがあります。
• これらのメソッドの 1 つは、各 LINQ to SQL クラスに追加される部分メソッドです。このメソッドに使用する共通のボディがあります。このメソッドを各部分クラスに追加するのではなく、一度作成して基本クラスの継承で継承する方法を探しています。

詳細を説明するのに役立つことを願っています。

特定のクラスではなくコントラクトをプログラミングすると同時に、IoC/依存性注入を使用することに同意しようとしています。私が抱えているジレンマは、次の間の緊張です。

1. Do program to interfaces to IoC : インターフェイスに大きく依存する IoC から始めました。Spring のサンプル プロジェクトから判断すると、IoC とのコントラクトに合わせてプログラミングする場合は、インターフェースが最適です。

2. ( ... 一般的には抽象クラスが好まれますが、インターフェイスの主な欠点は、API の進化を可能にすることに関して、クラスよりもはるかに柔軟性が低いことです)

3. コンストラクターを介してクラスの依存関係を明示的にする 私の直感では、クラスのコンストラクターに依存関係を渡すことは、プログラミングの良い実践方法であるということです。実際、これは依存性注入です。

4. ...インターフェース/抽象クラスでコンストラクター署名を強制できないことを除いて:インターフェースも抽象クラスもコンストラクター署名を定義することを許可しません(簡単/エレガントに)。フレームワーク設計ガイドラインのセクション 4.4 も参照してください:抽象型でパブリックまたは保護された内部コンストラクターを定義しないでください。... コンストラクターは、ユーザーが型のインスタンスを作成する必要がある場合にのみパブリックにする必要があります。

この質問は、以前のスタックオーバーフローの質問に関連しています:コンストラクターの署名を定義するインターフェイス?

しかし、私の質問は次のとおりです。

上記の質問で尋ねたように、C# インターフェイス/抽象クラスではコンストラクターを定義できないため、実用的なレベルでは次のようになります。

これを、コンストラクターを介して依存関係を渡すという賢明な慣行とどのように調和させますか?

編集：答えてくれてありがとう。この場合、どうすればよいかについての洞察を期待しています。コンストラクター引数を使用しないだけですか? 依存関係を取るある種の Init() メソッドを使用しますか? Edit2:素晴らしい回答をありがとう、とても役に立ちました。

私は頭を悩ませている奇妙な問題を抱えています。

1 つのプロジェクトで次のクラスを定義しています。

今、このようなことを試してみると、期待どおりに動作します:

これで、Web メソッドを公開する別のプロジェクトができました。このメソッドは AbstractUnitModel を取得してリモートで実行し、結果をクライアントに返します。したがって、サーバーには次のものがあります。

そして、クライアントにはこれがあります：

しかし、私のプロジェクトはコンパイルされず、次のエラーが発生 します。

エラー 110 引数 '1': 'UnitModelWrapperInterface.BlastFurnaceUnitModel' から 'CalibrationClient.UnitModelRemoteServer.AbstractUnitModel' に変換できません

なぜこれが起こっているのかわかりません。サーバー プロジェクトには、AbstractUnitModel が定義されている名前空間への参照があります。少しおかしいと思ったのは、UnitModelWrapperInterface ではなく「CalibrationClient」名前空間の AbstractUnitModel を使用していることだけです。VS がクライアントで Web サービスのプロキシを生成すると、AbstractUnitModel の部分的な抽象実装が作成されるようです。これが私の問題の原因ですか？もしそうなら、どうすればそれを修正できますか？

解決策の編集: 指摘したように、クライアントはネットワーク経由で送信される可能性のあるすべてのクラスについて知る必要があります。生成されたプロキシ クラスを削除し、共通ライブラリを参照することで、これを解決しました。理想的ではありませんが、この状況では十分です。

これは初心者の質問かもしれませんが、Wheel プロパティの複製を抽象クラスにリファクタリングしながら、Part タイプへの明示的なキャストを維持する標準的な方法はありますか? FastCarWheel が SlowCar に配置されないようにする必要があり、このようなプロパティが多数あるとします。

このタイプのシナリオでは、このタイプの重複を許可するのが一般的ですか? ジェネリックを利用することを考えていましたが、問題を動かしているように見え、このように動作する追加のプロパティごとに悪化します。

ありがとう

抽象クラスよりもインターフェース+拡張メソッド（ミックスイン）の方が望ましいですか？

あなたの答えが「それは依存する」であるならば、それは何に依存しますか？

インターフェイスと拡張機能のアプローチには、2つの利点があります。

• インターフェイスは複数回継承可能ですが、クラスは継承できません。
• 拡張メソッドを使用して、インターフェイスを壊さない方法で拡張できます。（インターフェイスを実装するクライアントは、新しい基本実装を取得しますが、それでもオーバーライドできます。）

このアプローチの欠点についてはまだ考えていません。インターフェイスと拡張機能のアプローチが失敗するという、明らかに単純な理由があるかもしれません。

このトピックに関する2つの役立つ記事は次のとおりです。

• インターフェイスと拡張メソッドを使用してミックスインを作成する
• 抽象基本クラスにはバージョン管理の問題もあります

たとえば、抽象クラスを拡張し、インターフェイスを実装するクラスがある場合はどうなりますか。

インターフェイスと抽象クラスの両方からメソッドにアクセスできるように、このクラスを初期化するにはどうすればよいですか？

私がする時：

インターフェイスからメソッドにアクセスできません。