Re: Expanding entity that is agile

(From Wikipedia)

Decoration pattern is a design pattern
<http://en.wikipedia.org/wiki/Design_pattern_(computer_science)> that
allows behavior to be added to an individual object
<http://en.wikipedia.org/wiki/Object_(computer_science)>, either statically
or dynamically.

The decorator pattern can be used to extend (decorate) the functionality of
a certain object statically, or in some cases at run-time
<http://en.wikipedia.org/wiki/Run_time_(program_lifecycle_phase)>,
independently of other instances of the same class
<http://en.wikipedia.org/wiki/Class_(computer_science)>, provided some
groundwork is done at design time. This is achieved by designing a new
*decorator* class that wraps <http://en.wikipedia.org/wiki/Wrapper_pattern> the
original class. This wrapping could be achieved by the following sequence
of steps:

   1. Subclass the original "Component" class into a "Decorator" class (see
   UML diagram);
   2. In the Decorator class, add a Component pointer as a field;
   3. Pass a Component to the Decorator constructor to initialize the
   Component pointer;
   4. In the Decorator class, redirect all "Component" methods to the
   "Component" pointer; and
   5. In the ConcreteDecorator class, override any Component method(s)
   whose behavior needs to be modified.


*Joao Oliveira*
*Software Engineer*

*P:* +353 831 467 299 | *E: *[email protected]  | Connect with me
on Linkedin <http://ie.linkedin.com/in/jnicolau>

On Tue, Dec 2, 2014 at 1:12 PM, [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> I have an entity similar to *Product*. It has many properties/attributes
> like Name, Description, few different prices like *Original Price, Sales
> Price, Discounted Price, Cost, Manufacturer* etc... Counting all the
> properties of this *Entity* that I use, it has 20 properties. To be
> agile, I see that this *Entity* can grow by adding new properties.
>
>
> I'm sure I'm not modelling this *Entity* properly. I should have all
> pricing properties as Value objects. And move some properties to a
> different entity. However, I'm anticipating more properties are added which
> can ultimately change the version of the Entity. To put this way "Embrace
> change".
>
>
> Is there a pattern to make an Entity agile, so a compilation is not needed
> for the Entity when a property/containing object is added and thus no
> deployment of the existing Entity is needed?
>
>
> Is using a Key/Value pairs for this Entity a good practice?
>
>
> Or use the inheritance with a hierarchy like *ProductBase, ProductInfo
> (derived from ProductBase), ProductSpec1 (derived from ProductInfo),
> ProductSpec2 (derived from ProductSpec1)*? By following this pattern,
> when a new property is added, I can create a new class called
> *ProductSpec3* and derive from *ProductSpec2* and deploy through a new
> assembly or DLL and don't touch the existing assemblies.
>
>
> Thoughts?
>
>
>  
>