这是代理模式的示例，还是装饰者模式的示例

Question

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

你认为如何？

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实体类通常位于不同的程序集(域程序集)中，而person personproxyordecorator类和存储库将位于程序集存储库中。

谢谢

罗斯

Answer 1

我想两者都有。从技术上讲，从Person派生该类可以使其成为Decorator，但由于您在其背后有一些加载逻辑，因此它也是一个代理。

Answer 2

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

有关这些模式的一些背景知识，请参阅Decorator和Proxy。

Answer 3

你不会从这个问题中得到一个简单的答案--但这是一个有趣的讨论。

它是代理吗？引用Wikipedia，一个代理类：

是一个类，它充当其他东西的接口。

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

是装饰师吗？是的！继承的类为Address属性添加了额外的修饰(它不允许您设置它)。

让我们再添加一个--我建议它也是一个工厂--因为您从继承的类中“补充”了Person接口的属性。