[Interest] How to do it better?

[Bo Thorsen]

Den 30-12-2014 kl. 11:26 skrev Igor Mironchik:
> Hi,
>
> On Tue, 30 Dec 2014 11:41:05 +0300, Till Oliver Knoll
> <till.oliver.knoll at gmail.com> wrote:
>
>>
>>> Am 30.12.2014 um 05:24 schrieb Igor Mironchik
>>> <igor.mironchik at gmail.com>:
>>>
>>> Hi,
>>>
>>> cool, after a whole day of work
>>
>> My whiskey tasted great yesterday evening (also after a day of work, and
>> after a great self-made dinner with friends).
>
>
> Fresh sight can be much more better than hours of work. :)
>
>
>>
>> ;)
>>
>>> my brain is clouded.
>>
>> Ah, I wasn't aware that you were looking for a Cloud(tm)-based solution!
>>
>> ;)
>>
>> Ok, whiskey and jokes aside: your base class could also simply emit a Qt
>> signal (to relate this thread a little bit with Qt) whenever that
>> property changed (again, setter/getter accesss, make sure the property
>> actually /did/ change before emitting the signal, ... you know the game).
>>
>> Your derived class could then simply connect "to itself" (to that
>> signal) and react accordingly in its own slot.
>>
>>
>> But I have to ask: for me it sounds like your base class is some kind of
>> "data" (Model) class, and your derived class a QWidget-based class, aka
>> "the View" (you've mentioned QResizeEvent). Or in other words: does your
>> derived class inherit from two base classes: your "Model" and some
>> QWidget class (multiple inheritance)?
>>
>> If yes: why not a "has-a" relationship between your Model (currently
>> your "base class") and your View (currently your "derived class"),
>> instead of your current "is-a" situation?
>>
>> If no, then why does your base class (which must then be a QWidget based
>> one in this case) not handle the resize event itself; derived classes
>> could still overwrite the resize method and add custom code, e.g. after
>> (or before) calling the base class' resize method?
>>
>
>
> The situation is the next. My base class is QWidget-based implented
> signals, slots and properties. And my derived class is template class that
> doing actual work. And in setter of one property I had to
> recalculateSize() in template class, and template method pattern is very
> good in this situation...

In proper Qt based architectures, template method patterns are not as 
common as in other places. At least not if you code Qt like I do. Using 
a template method means the base class decides when the sub classes do 
something. That's a very tight coupling between the base class and 
subclasses. Tight coupling means you're one step closer to the dreaded 
spaghetti code.

I (almost) always preach using signals to avoid tight coupling. By 
emitting a signal in the base class when the property changes, you stop 
this class from knowing what subclasses do. Or any other use that you 
might think of in the future. This means your class becomes a black box 
that needs no info about the other classes.

In case you're not convinced yet, try this thought experiment: If you 
already had a working system where classes are working well. Now your 
subclass changes an implementation detail, so you need the geometry 
recalculation on this property change. So to do that you have to 
implement the logic for this in the base class? That just smells bad. 
With just one subclass this isn't so bad, but how do you know that you 
won't have more in the future?

I don't like the template method pattern in cases like this because it 
moves responsibility from the class where it belongs. Template method 
should be used when the base class orders *all* subclasses to handle 
something. Not in particular cases like this one where it's the subclass 
that needs something done.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu