Wednesday, 11 March 2009

Signals, slots and ignoring OOP principies

Refactoring of gadu_protocol module is now in cleanup mode. There are still some missing things, like DCC not supporting NAT connections, DCC configuration is not moved to Account settings page and so on...

I had some thoughts that I've got while I did the refactoring: about signals and slots overuse in gadu_protocol code. This Qt extension of C++ is supposed to help programmers with connecting events that happens on one object with actions that another object should perform when an event is triggered. The overuse occurs when the connection is always one-to-one and we know that no another object ever will try to connect to these slots or signals. Just like in gadu_protocol - classes like GaduProtocol, GaduProtocolSocketNotifiers, DccManager, DccSocketNotifiers were communicating with each other using this, but I think it is not the optimal solution. It needs connecting these objects (this is a lot of code to write!) and signals-slots invoking is really very slow (I know it is not a concern because of small frequency of these calls in protocol classes, but I still does not like this solution).

I've got into conclusion that these classes are really an one big class that is just split for convenience. So I've removed signal-slots where it was possible and made these classes each ones friends. They can now access private members of each other ;) In the result, it is easier now to understand how this whole group works together. We did not lost any of flexibility, because there was not any either (you cannot just extend a closed communication protocol like this).

This is not very good solution from view of OOP (no accessors, just friend classes), but it is the best one for my simple mind ;)

No comments:

Post a Comment