22

の動作をモックアウトしたいという理由だけで、かなりの数のラッパー クラスを作成していることに気づきました。

  • RhinoMocks 分離モデルに適していないクラス (たとえば、DirectoryInfoや などWindowsIdentity)
  • ネイティブ Win API メソッド (私は通常、必要なすべてのメソッドを 1 つのクラスにまとめ、ネイティブ呼び出しをクラス メソッドとしてラップします)

次に、「W」でラップされたクラスを追加していることに気づき（ラッパーであることを示すため）、最終的には（かなり冗長に見えるのとはDirectoryInfoW対照的に）になります。DirectoryInfoWrapper同様に、ラップされたネイティブ メソッドと呼ばれるNativeMethods.DuplicateTokenW.

ラッパークラスに名前を付けるときに従うべき良い経験則は何ですか?

4

4 に答える 4

20

命名規則は、一緒に作業しているチームに適したものです。誰もが特定の規則に同意している限り、それは問題ありません。

DirectoryInfoWrapperただし、コードに精通していない人に何も説明しない単一の文字を使用するよりも、より冗長なバージョンを好む傾向があります。しかし、それは私だけです。

于 2009-07-24T06:51:21.530 に答える
3

私はaberrant80に同意します。あなたが使用している規則に全員が同意すれば、それは機能します。

私は個人的に、クラスの目的を説明するために短くて説明的な名前を使用することを好みます。少なくともインターフェースレベルでは。モックフレームワークを使用している場合は、IDirectoryまたはIDirectoryInfoが適切な名前のセットになり、DirectoryInfoWまたはDirectoryInfoWrapperがインターフェイスの実装者になります。

より良い例は、HttpRequestをラップすることです。「これは私のアプリケーションにとって重要なことです」と述べるIRequestを定義すると、Request、HttpRequestWrapper、Requestなどが実装者になります。

したがって、要約すると、説明的で過度に冗長ではないインターフェイス名を使用してみてください。

于 2009-07-24T13:02:22.473 に答える
0

余談ですが、ネイティブ メソッド呼び出しをラップする、より見た目に美しい (まあ、私にとっては) 方法を見つけました。

public class NativeMethods
{
        // made virtual so that it can be mocked - I don't really want
        // an interface for this class!
        public virtual bool RevertToSelf()
        {
            return WinApi.RevertToSelf();
        } 

        ...

        private static class WinApi
        {
            [DllImport("advapi32.dll")]
            public static extern bool RevertToSelf();

            ...
        }
}

つまり、ネストされたプライベート クラスでネイティブ メソッド呼び出しをカプセル化することにより、名前の衝突を回避します。

ただし、ラッパー クラスの命名の問題に対する「適切な」解決策はありません。おそらく aberrant80 の提案に従い、ラッパー ラッパーを明示的に呼び出します。

于 2009-07-30T02:35:31.090 に答える