Esiste un nome per questo motivo di progettazione (che si avvolge dinamicamente attorno ad un'altra classe)?

Question

Supponiamo di avere una classe uicontrolWrapper, che è un wrapper per un uicontrol (ma non la sottoclasse). Il materiale uicontrol è conservato in una proprietà privata per uicontrolWrapper. Fondamentalmente, voglio essere in grado di fare set/get contro il wrapper, e le chiamate si alimentano in uicontrol.

avrei potuto fare questo:

classdef uicontrolWrapper < handle 
    properties (Access = private) 
     uic 
    end 
    properties (Dependent) 
     Style 
     String 
     Value 
     ... 
    end 
    methods 
     function set.Style(obj, val) 
      obj.uic.Style = val; 
     end 
     function val = get.Style(obj) 
      val = obj.uic.Style; 
     end 
     ... 
    end 

ma hardcoding come questo è, ovviamente, piuttosto brutto.

Oppure, potrei fare dynamically generate properties dependent on what I'm trying to wrap:

classdef uicontrolWrapper < dynamicprops 
    properties (Access = private) 
     uic 
    end 
    methods 
     function obj = uicontrolWrapper(hObj) 
      obj.uic = hObj; 
      cellfun(@(prop) obj.createProperty(prop, fields(get(hObj)); 
     end 
     function createProperty(obj, prop) 
      p = addprop(obj, prop); 
      p.Dependent = true; 
      p.SetMethod = @setUicontrolProp; 
      p.GetMethod = @getUicontrolProp; 

      function setUicontrolProp(obj, val) 
       obj.uic.(prop) = value; 
      end 
      function val = getUicontrolProp(obj) 
       val = obj.uic.(prop); 
      end 
     end 
    end 
end 

Il punto è quello di evitare di violare il Law of Demeter da non "raggiungendo in" la proprietà che stiamo cercando di modificare.

Non so se questo è un motivo di progettazione, ma ho usato questo tipo di cose per avvolgere oggetti di diverso tipo quando la sottoclasse è per qualche motivo o un altro inappropriato. (Ad esempio, la classe matlab.ui.control.UIControl è Sealed e non può essere sottoclasse.) Ha un nome effettivo e un uso tipico previsto?

Answer 1

Questo è il Decorator Pattern - creazione di uno strumento che decora le nuove funzionalità su oggetti esistenti (a volte anche diverse volte) in particolare senza influire su altre istanze dello stesso tipo (o su di esse in modo esplicito se desiderato).

Questo differisce dal motivo Proxy nel senso che non si rinvia l'operazione di invio dell'operazione corretta al proxy, si sta effettivamente innestando la nuova funzionalità su dell'oggetto.

Answer 2

Credo che tu stia chiedendo del motivo di progettazione Proxy qui (fornisci un'interfaccia ad altri oggetti creando una classe wrapper come proxy).

Un paio dei suoi vantaggi sono l'aggiunta dell'accesso di sicurezza e la semplificazione dell'API per l'oggetto spostato (il proxy può fornire una semplice API in modo che il codice client non debba occuparsi della complessità dell'oggetto di interesse).