@Simplicius-Simplicissimus said in Stylesheet for a subset of widgets:
I see that my attitude originates from a time when I participated in the production of generated code and drafted documentation for a Design Pattern course. Mission statements like “Aggregation is better than Inheritance” left their mark.
I know that currently there is a strong push against traditional OOP, especially inheritance. Inheritance is not a silver bullet and sometimes there are better solutions. But also, never using inheritance is also not a silver bullet. I'm not saying you should use inheritance instead of aggregation in general, but rather you should make an informed decision (instead of just blindly following rules like "Aggregation is better than Inheritance").
@Simplicius-Simplicissimus said in Stylesheet for a subset of widgets:
Qt has nothing to do with that.
Actually, Qt has something to do with that. Qt does not use interfaces/abstract classes. This is a design decision that was made and you have to conform to this with your own classes. Qt dictates that you MUST use inheritance instead of aggregation/composition. If you want to use Qt it is not your choice anymore (except for classes that don't directly interact with the Qt eco system).
As you have mentioned interfaces are implemented as abstract classes in C++. The mechanism is still inheritance to implement an interface. You gain nothing by using interfaces instead of just regular inheritance in C++. As I said before, you'd need to forward a lot of member functions when using aggregation. Nobody wants to write that much code! And with the design Qt has chosen you certainly don't need any dynamic_casts. Don't go through the trouble of rewriting Qt to use interfaces instead, just because of some stupid rule (most "rules" should actually be "guidelines"). BTW, the original design pattern book just collected patterns they observed in existing source code and gave them a name. The authors never said to force the patterns everywhere in your own code. If a pattern solves your problem–good, use it. But don't try to use as many patterns as possible. This was never the intention. Use them as guidelines.