4

これはすでに質問されて回答されていると確信しているので、事前にお詫び申し上げますが、検索する正しいキーワードがわかりません. 「パターン」で検索すると、あまりにも多くの Q & A がヒットし、役に立ちません。

私は回帰テストアプリに取り組んでいます。画面にフォームを表示していますが、アプリにログインしているユーザーに応じて、フィールドの一部を読み取り専用にする必要があります。フィールド オブジェクトを抽象化し、ユーザー オブジェクトを抽象化できますが、これら 2 つの概念の交差を説明するには、どのパターンを見ればよいのでしょうか? つまり、フィールド 1 とユーザー A のフィールドが読み取り専用であることをどのように説明すればよいでしょうか。読み取り専用 (またはそうでない) は Field クラスのプロパティであるように見えますが、私が言ったように、どのユーザーがフォームを見ているかによって異なります。単純な 2 次元配列 (例: ReadOnly[Field,User] = True) を検討しましたが、これを表す最も効果的な構造を選択したことを確認したいと思います。

この種のデータ構造に関するソフトウェア設計パターンはありますか? 私は物事を過度に複雑にしていますか? 2 次元配列がここに行くための最良の方法でしょうか? 私が言ったように、これが尋ねられて答えられた場合、私はお詫び申し上げます。私はここで検索しましたが、何も見つかりませんでした.Google検索でも何も見つかりませんでした.

4

2 に答える 2

2

テーブル主導の設計は効果的です。Steve Maguire は、Writing Solid Codeでいくつかの良い例を挙げました。

また、テストをキャプチャする優れた方法でもあります。 fitを参照してください。

あなたの場合、次のようなものです：

Field1ReadonlyRules = {
    'user class 1' : True,
    'user class 2' : False
}

field1.readOnly = Field1ReadonlyRules[ someUser.userClass ]

余談ですが、ユーザーとユーザー クラス/ロール/グループを組み合わせるのではなく、それらの両方をモデル化することをお勧めします。通常、ユーザーは誰を取得するか(認証)、グループ/ロールは何を取得するか(権限、機能)を取得します。

于 2008-09-09T18:01:48.340 に答える
1

一見すると、2 つの異なるタイプのユーザーがいて、アクセス レベルが異なるように思えます。これは、継承 (PowerUser、User) によって、またはユーザーのレベルを設定するセキュリティ オブジェクトまたはトークンを含めることによって解決できます。

原則として継承が気に入らない場合は、アプリケーションで State パターンを使用したり、ユーザー オブジェクトを装飾したり (Shudder)、さまざまなセキュリティ レベルの戦略パターンを追加したりできます。しかし、まだ少し早いと思います。アイテムがどのように成長し、維持されるかをしっかりと把握するまで、通常はパターンを適用しません.

于 2008-09-09T17:26:16.180 に答える