Strokes framework naming problem
Dmitry Kazakov
dimula73 at gmail.com
Mon Jul 11 09:18:26 CEST 2011
>
> I want to call it like KisStrokeJobStrategy. What do you think, is it easy
>> to distinguish it form KisStrokeJob class?
>>
>
> It is easy to distinguish because they are related. KisStrokeJobStrategy
> works with instances of KisStrokeJob (if I understood the diagram
> correctly), describing how to use them.
>
> I think the name KisStrokeJobStrategy is much better.
>
> Dab is very specific to brushes that work like stamps. New brush engines
> like the Sketch Brush do not work with "dabs" anymore; they may use PaintAt,
> but they are not stamping seals over the canvas 1 at a time. So I think we
> should look for a better name to refer to single operations of painting,
> something more general.
>
Ok, I'll rename it then.
> 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?
>>
>
> I (think I) have seen both practices.
> I've seen the Subtype-goes-at-the-end naming strategy in classes like
> KoDocumentSection (there's -View, -Delegate and -Model) and for me it was
> very easy to follow.
>
> The reason it is easy to follow is because I can simply grep for classes
> with the same root and will find all subtypes. That won't work with the
> reverse style of naming which is also less logical if you ask me (obviously
> I can perform a better regular expression search but... it will be more
> contrived).
>
> I think using:
>
> Global Prefix - Type - Subtype - Subsubtype
>
> Is the most logical convention, and useful when looking for related
> classes.
>
Yes, I was not sure about it because I thought it might become quite
difficult to read. Btw, we have a kind of such naming for KisTool hierarchy:
KisToolPaint, KisToolFreehand.
And we can expand this idea to namespaces, it'll be more obvious, i guess:
StrokeStrategy::Freehand, StrokeJobStrategy::Freehand.
--
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110711/02d3b617/attachment-0001.htm
More information about the kimageshop
mailing list