0

次のコードを考慮する

public interface IEntity {
int Id { get; set; }
}

public class User : IEntity {
    public int Id { get; set; }
}

public abstract class RepositoryBase<TEntity> where TEntity : IEntity {

    public bool Save(TEntity entity) {
        if (!IsValid(entity)) return false;

        // Write to data store

        return true;
    }

    public abstract TEntity CreateNew();

    protected abstract bool IsValid(TEntity entity);
}


public class UserRepository : RepositoryBase<User> {

    public override User CreateNew() {
        return new User {
            Id = 3
        };
    }

    protected override IsValid(User entity) {
        return entity.Id > 0;
    }
}

これはオープン/クローズの原則ですか？つまり、ほとんどの責任を基本クラスに委譲し、特定の機能的責任を継承クラスに許可します。

って感じではないので、開閉主義じゃないとしたらどういうデザインパターンなんですか？

乾杯

4

2 に答える 2

1

RepositoryBase<TEntity>のコードを変更することなく、さまざまな方法で拡張することにより、さまざまなデータ構造の新しいリポジトリを作成できますRepositoryBase<TEntity>。これが、オープン/クローズド原則の核となる意味です。

つまり、オープン/クローズの原則は一般的な設計原則であり、設計パターンではありません。SaveとIsValidメソッドの関係で見える主な設計パターンはTemplate Methodです。

于 2011-05-26T11:19:10.750 に答える
0

ウィキペディアで読むことができるように、OCPにはいくつかの定義があります。おそらくstackoverflowで主に使用されるのは、多態的なものです。理想的には、1つの場所でバリエーションを許可し、それらのバリエーションに依存する特定の（保護された）クラスに影響を与えない設計が必要なため、保護されたバリエーションのスピンが好きです。

あなたの例では、クライアントと実装の間に直接結合がない限り、IEntityの実装のバリエーションはIEntitiesを使用するクライアントクラスに影響を与えません。つまり、クライアントは、特定の実装についてではなく、IEntitiesについてのみ知っている必要があります。これには、クライアントが具体的に知らなくても実装にアクセスできるように、ファクトリを実装する必要があることがよくあります。

于 2012-04-13T12:57:23.573 に答える