View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003326||3 - Current Dev List||Maintenance||public||2019-06-05 16:11||2019-06-05 16:11|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0003326: CConnection class in Rig Control has architectural problems|
The CConection class in Rig Control implements a connection between Rig Control and the radio. The class has several design issues which make it difficult to manage the code's complexity and add features to the design. We should consider an aggressive refactoring of the class. I think such a refactoring, if aggressive enough, would have valuable long-term benefits for the product ... even if the refactoring was in actuality a re-write of the class.
|Steps To Reproduce||At the high level, there are two problems.|
One is that the class performs no encapsulation. The Connection.h header starts out with a long list (more than twenty!) of other classes which are friends of the CConnection. The friend relationships are necessary for two reasons. One is to let the other classes access synchronization objects in the CConnection class which prevent code on differen threads from working the connection simultaneously. This would better be solved by internally managing thread ownership; or by coming up with some more sensible ownership mechanism for exclusivity.
The other friendship problem is due to poor factoring of the class. Radio-specific routines and data exist in CConnection; vendor- or protocol-specific code should be in an specific class derived from CConnection and completely public to that class. Instead, implementation-specific code is private ... until it's exposed by friendship.
The friendship problem is an example of the secondary high-level problem: bad abstraction. CConnection does all sorts of things for a radio, not just a connection. The class should be more carefully factored against CRadioOptions and its other consumers so that it can be used in a more modular, sensible way.
For now, I'm continuing to work on the code without touching the structure of this class. It's awful, but that means that sometimes I make changes which simply make these problems worse. When the team is ready to make a focused investment in code quality, we might be able to recover this debit and have a more sensible implementation. I'm opening this issue to document and hopefully prioritize this issue.
|Tags||No tags attached.|