Strokes framework naming problem

[Dmitry Kazakov]

Hi!

I need some help with discussing the design stuff again. I think the current
version of names inside the stroke framework is not the best option for the
future. I guess, I should rename the classes in some way before I start
porting other tools, but I'm not sure how.

Maybe, someone knows some books or articles about the class naming topic? Or
there are any KDE-wide standards describing that? Many classes are going to
appear there soon, so there should be some policy how to name them now to
avoid vast renames in the future.

So what we have now:
http://dimula73.narod.ru/strokes_naming.png

You can see three hierarchies here.
1) Classes derived from KisStrokeStrategy. These classes explain the
scheduler what to do in the beginning and the end of the user action, how to
create a transaction, initialize the painter and so on. This is quite a
highlevel class. The stroke may contain several jobs those are executed by
the scheduler. These jobs are described with KisDabProcessingStrategy
strategy.
2) KisDabProcessingStrategy derived classes. They describe a single action
executed by the scheduler. E.g. "initialize stroke", "paint one dab". These
classes define the behavior only. It means they do not store information
about any particular "dab". They describe *how* to paint any particular dab.
The information about the specific "dab" is given to the strategy with a
DabProcessingData class.
3) DabProcessingData. These classes store information like
KisPaintingInformation, a pointer to KisPainter.

KisStrokeJob class is introduced to create a link between
KisDabProcessingStrategy and DabProcessingData those describe an action
fully.


Ok, what I don't like about this naming:

1) I don't like KisDabProcessingStrategy name. Some actions like
"initialization of the stroke" do not work with "dabs" in Lukas' meaning.
Btw, what is exact meaning of the term "dab"? :)
I want to call it like KisStrokeJobStrategy. What do you think, is it easy
to distinguish it form KisStrokeJob class?

2) I don't like the fact that the definition of the subtype of the class is
put into the beginning of the name.

KisPainterBasedStrokeStrategy -- probably, not good
KisStrokeStrategyPainterBased -- better?

FreehandStrokeStrategy -- not good
KisStrokeStrategyFreehand -- better?

What do you think? What is the common practice here?

3) I don't know where I should add Kis- prefix and where not. These classes
are too small, too specific and too private to use such global prefix. What
is the general rule there?
4) Well, and, finally, the word 'strategy' is too long for names =( But I
can't simply remove it because there are classes like KisStroke and
KisStrokeJob.

Thanks for your advices in advance! =)

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110710/5d0bf9a6/attachment.htm