Design Question: Delegation vs. callbacks

Jason House jason.james.house at gmail.com
Sat Jun 16 15:55:35 PDT 2007


Honestly, it sounds like you need to take a step back and look at the 
higher level design.

   Normally, I'd expect thing (or widget) to be a base class for many 
graphics objects.
   If you want a coherent architecture that doesn't confuse the user, 
I'd recommend avoiding differing types of functionality with the same 
function name.  Maybe it's best to rename one or both of your isIn 
functions?
   If position is defined to be the upper left corner of a bounding box 
(or some similar definition), one of two things should result:
   a. The position to change if a component has been changed.  The 
object has changed, so its properties changed.  The user must live with it.
   b. The containing object forces everything inside it to conform to 
its dimensions.  Drawing a circle that goes outside of a window 
shouldn't leave a mark on the desktop...

Henning Hasemann wrote:
> Say I have basically three classes which form my problem:
> Thing, Area and Animation.
> 
> A thing is something on the screen you can interact with, and area just
> defines a number of pixels (there are rectangular areas as well as
> bitmasks), an animation is something you can actually see.
> 
> Now a thing has a Position somewhere on the screen and it has an area,
> so you can check if it was clicked, also it will probably have an
> animation from wich an area can be get with the method boundingBox().
> 
> Say Area has a method isIn(x,y) which says if the coordinate is inside
> the area. Now I have two possibilities:
> 
> "Delegation":
>   Thing's area is private but Thing has its own isIn(x,y) method
>   where it substracts its own method and then delegates the call
>   to area, so area doesnt have a position at all.
>   Similar approach then for animation and a render() method.
> 
>   cons:
>   - I cant position a plain animation on the screen without a thing or
>     an other wrapper class.
>   - This pattern drastically flattens structure: thing re-implements
>     lot of the methods of area and animation with the delegates,
>     but *does not* inherit from their possible interfaces.
>     (If it would, the isIn() etc... methods would have different
>     semantics: in thing isIn would accept a screen-position whereas
>     in area isIn would operate on a position relative to the area)
> 
> "Callbacks":
>   Everything operates with absolute screen-coordinates and area as well
>   as animation have function pointers / delegates to check, what the
>   position of the thing is, they belong to.
> 
>   cons:
>   - the callbacks feel somewhat "magical", especially when you consider
>     the bounding box stuff: the area returned by .boundingBox() would
>     look up its position from the animation wheres the animation would
>     look at the thing.
>     It might feel weird that the .position attribute of something can
>     change, just because I change a totally different thing.
> 
> What would you choose? Do you see other alternatives to solve this?
> 
> TIA
> Henning
> 
> 
> 
> 
> 
> 


More information about the Digitalmars-d-learn mailing list