0

という問題のインターフェースが欲しいIProblemです。Solve() と CheckArguments() の 2 つのメソッドを使用します。このProblemクラスは、すべての問題で同じであるため、CheckArguments() 関数を実装します。しかし、私はさまざまな種類の問題を抱えてEasyProblemおりHardProblem、Solve() メソッドの実装が異なりますが、CheckArguments() メソッドは常に同じであり、基本クラス Problem() の実装を常に使用したいと考えています。

私は正しい修飾子を持ちたいのですが、どのメソッドがどのクラス/インターフェースで定義されているかについて少し混乱しています。言うまでもなく、これら両方の機能のテスト プロジェクトもあります。

4

3 に答える 3

3

次のようなものを試すことができます：

public interface ISupportArguments
{
   bool CheckArguments();
}

public abstract class AbstractProblem : ISupportArguments
{
   public bool CheckArguments() {
        return true;
   }

   public abstract void SolveProblem();
}

したがって、すべてのクラスは独自のバージョンから派生し AbstractProblem てオーバーライドします

SolveProblem(..)
于 2013-11-06T09:13:50.737 に答える
0

The class structure has been shown by Matten very well.
As regards access modifiers: I'd propose a defensive approach, so that you use the most restrictive access modifier that solves the problem. It is easier to be less restrictive afterwards than to be more restrictive as you might have to explain to some users of your code why they cannot use it anymore.

So for the types (interface and classes): if you don't need them in other assemblies, rather define them as internal. If you want to access the types from your test project, you can use the InternalsVisibleTo attribute to be able to access them from specific assemblies. You add the attribute to the assembly containing the types and provide the name (and for strong named assemblies some additional data) of the test assembly as a parameter.

The same applies to the members. You can also think about implementing the interface explicitly, so you can access the methods only if you access the class via the interface.

于 2013-11-06T09:21:41.750 に答える