Author: [Artur Trzewik]

[Traits] page descibes know design problem in OO.
How to privide functionality for object that should be reused but can not
be implemented by heritage.
Often it is design decision do not implement some functionlity in object itself
because it would overload the object interface.

Here a design alternative how avoid such problem by using old good
object association or in this case aggregation.

In the original idea traits are set of methods, which can be added to object
and have defined requirment for object interface.
In Java or C# we can define such requirement as Interface in XOTcl we can only document
it or write some policies as XOTcl precondition.

The idea is to have many objects for each functionality and base object only for
as central data container.

Example taken from [Traits] publication

   Class TCircle -parameter circle
   TCircle instproc getArea {} {
      set radius [[my circle] radius]
      expr {$radius*$radius*3.14}
   }
   TCircle instproc bounds {} {
       ....
   }
   Class TDrawing  -parameter circle
   TDrawing instproc draw {} {
      ....
   }

   Class Circle -parameter {center radius}
   Circle init {} {
       # create nested object for manipulation of circle
       TCircle create [self]::@manipulator -circle [self]
       TDrawing create [self]::@drawer -circle [self]    
   }

   # Using
   set aCircle [Circle new -center {2 3} -radius 5]
   $aCircle @drawer draw


So instead of Traits we can build a collaboration of dependant objects and
implement the functionality in serveral classes.

---
Discusion

Thare are also another implementations possible:
  1. no nested objects so we can change the circle object and reuse TCircle instance for many Circle objects
  1. do not create TCircle in Circel constructor because of bidirectional dependiences (Circle <-> TCircle)
  1. create TCircle only if needed

In can observe that is last years OO-programmers tends to split functionlity into many
classes that becomes names as Controller or Action. So not to programm all functionality in
one Class (or Class heritage) itself. Overloaded Classes becomes Antipatterns (the blob or ghost class).

The proven architecture is to define several of layers and provide for each layer own class set.
In such models often the classes are build after choosen name pattern. Here example
of 3-layer design.

   # Business Layer
   Class Customer -superclass DomainObject
   # Data Acces Layer
   Class CustomerDAO -superclass DAOBase -parameter {aCustomer}
   # View Layer
   Class CustomerView -superclass Form  -parameter {aCustomer}

One can image that XOTcl can help with Metaclasses and Forwarding to compose objects together
and construct on the fly object with suitable consistent interface from composing many
object together. It can be good academic exercise.

I think the potency of OO is not inheritance but the possibility of building object colaborations
that use polimorphismus and defined interfaces.
Each object in the colaboration depends on several associated object and expent an interface (protokol)
of them.
To lern how to design such colaboration, the best is to study design patterns. The best known are
described in famous book "Design Patterns" from Erich Gamma, Richard Helm, Ralph Johnson and Jon Vlissides.