Re: A Design Problem
- From: "Daniel T." <daniel_t@xxxxxxxxxxxxx>
- Date: Wed, 22 Aug 2007 07:50:30 -0400
Mousam <mousam.dubey@xxxxxxxxx> wrote:
"Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
Mousam <mousam.du...@xxxxxxxxx> wrote:
Now I am bit confused about the design of Tool class because
there will be several functionalities which will be valid for
button type of tool but does not make sense for list box type
of tool and vice versa. Say e.g button tool can have one API to
change the image of button but this API does not make any sense
to have in list box tool.
The problem here is that you are thinking of the member-functions
as commands to order the Button or ListBox to do some specific
thing. Instead think of the member-functions as a way of informing
the Button or ListBox what is going on around it. Instead of
"button.highlight()" think of the reasons *why* the button would
be highlighted and use those for method names. Like
"button.mouseDownAt( x, y )" Note, this function (mouseDownAt) is
also useful for ListBoxes.
Unfortunately I can not think in this way because the set of toolbar
classes I want to design is a wrapper over existing C APIs. So as a
library designer I don't know how and when the client will use
functionality (API). e.g I have to provide an API to change the
image of the button, now its up to client when he wants to change
the button image on left mouse button down event or on right mouse
button down event or at some other time.
On the one hand, it sounds like the "existing API" is a framework that
you need to provided callbacks to, but on the other hand you are telling
us you want to do what is traditionally done by the framework. What is
this existing API that you are working with?
.
- Follow-Ups:
- Re: A Design Problem
- From: Mousam
- Re: A Design Problem
- Prev by Date: A Design Problem
- Next by Date: Re: A Design Problem
- Previous by thread: Re: A Design Problem
- Next by thread: Re: A Design Problem
- Index(es):