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

由于

罗斯

Answer 1

我认为这两者都是。从技术上从Person派生该类使它成为Decorator，但由于你背后有一些加载逻辑，它也是一个代理。

Answer 2

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

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

Answer 3

你不会从这个中得到一个简单的答案 - 但它会引起一个有趣的讨论。

是代理吗？引用Wikipedia代理类：

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

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

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

让我们再添一个 - 我建议它也是工厂 - 因为你从继承的类中“保湿”Person接口的属性。

这是代理模式或装饰器模式的示例

3 个答案: