0

我发现自己越来越频繁地使用以下设计,我的直觉说这是一种代理,因为我并没有真正添加太多功能。我怀疑它的唯一原因是因为代码往往更像我看到的装饰器示例!

你怎么看?

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
    public virtual string Address { get; set; }
}

class PersonProxyOrDecarator : Person
{
    private Lazy<string> _address;
    public PersonProxyOrDecarator(PersonRepository repository)
    {                
        _address = new Lazy<string>(()=> repository.LoadAddress(this));
    }

    public override string Address
    {
        get
        {
            return _address.Value;
        }
        set { throw new NotImplementedException(); }
    }
}

class PersonRepository
{
    public IEnumerable<Person> LoadPeople()
    {
        return new List<Person>(){
            new PersonProxyOrDecarator(this){ Name="Test",Age=18 }
        };
    }
    public string LoadAddress(Person person)
    {
        return "Address loaded from webservice";
    }
}

这并不重要,但 person 实体类通常位于不同的程序集(域程序集)中,而 personproxyordecorator 类和存储库将位于程序集存储库中。

谢谢

罗斯

4

3 回答 3

0

你不会从这个问题中得到一个简单的答案——但它会引发一次有趣的讨论。

是代理吗? 引用Wikipedia,一个代理类:

是一个类,作为其他东西的接口。

足够模糊,但您的示例肯定会让您满意-您继承的类充当该类的网关Person。但是,代理的这种“通用”定义似乎适合您作为开发人员编写的每个类,所以我不确定在没有某些上下文的情况下它有多有用(例如,如果我在面向服务的应用程序上下文中谈论服务术语代理变得更有意义)。

是装饰器吗? 是的!您继承的类为属性添加了额外的装饰Address(它不会让您设置它)。

让我们再加入一个 - 我建议它也是一个工厂- 因为您正在从继承的类中“水合” Person 接口的属性。

于 2013-10-21T10:50:34.210 回答
0

IMO 这既不是代理也不是装饰器,因为这些模式需要包装一个对象,而不仅仅是子类。Proxy 或 Decorator 类同时使用继承(ProxyPerson is-a Person)和组合(ProxyPerson has-a Person)。PersonProxyOrDecarator 没有 Person 字段,因此它不控制/装饰 Person 对象,而是一个(子类)Person 对象。代理是装饰器的一个特例。

有关这些模式的一些背景信息,请参阅装饰器代理

于 2013-10-21T00:00:01.200 回答
0

我认为两者兼而有之。从技术上讲,从 Person 派生该类使其成为装饰器,但由于您背后有一些加载逻辑,它也是一个代理。

于 2013-10-20T21:20:32.907 回答