Hi!<br><br>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. <br>
<br>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.<br>
<br>So what we have now:<br><a href="http://dimula73.narod.ru/strokes_naming.png">http://dimula73.narod.ru/strokes_naming.png</a><br><br>You can see three hierarchies here. <br>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.<br>
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.<br>
3) DabProcessingData. These classes store information like KisPaintingInformation, a pointer to KisPainter.<br><br>KisStrokeJob class is introduced to create a link between KisDabProcessingStrategy and DabProcessingData those describe an action fully.<br>
<br><br>Ok, what I don't like about this naming:<br><br>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"? :)<br>
I want to call it like KisStrokeJobStrategy. What do you think, is it easy to distinguish it form KisStrokeJob class?<br><br>2) I don't like the fact that the definition of the subtype of the class is put into the beginning of the name.<br>
<br>KisPainterBasedStrokeStrategy -- probably, not good<br>KisStrokeStrategyPainterBased -- better?<br><br>FreehandStrokeStrategy -- not good<br>KisStrokeStrategyFreehand -- better?<br><br>What do you think? What is the common practice here?<br>
<br>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?<br>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.<br>
<br>Thanks for your advices in advance! =)<br clear="all"><br>-- <br>Dmitry Kazakov<br>