I am writing a full fledged p2p networking library on top of Indy’s UDP server with an intention of publishing it online. The design I have implemented has a P2P manager ( TIdUDPServer ) which can act as a server or a peer. Each connected peer is represented by a separate object which contains additional features and information about them. The classes are both contained in a single unit.
For the purpose of simplification, I have declared those members used by either, under protected. Somehow, my instincts are giving me a bad feeling about this. The P2P manager has very few members but the peer object has nearly everything under protected. Going the other way will most certainly introduce a whole lot of code and method calls.
I need to know;
- Is it a good practice for networking libraries to have protected members?
- Should I replace the variables with properties under protected? With getters and setters or direct access would be fine?
I can’t see what the type of library should have to do with the architecture of your code in general.
As a general rule of thumb, it is better to start with high restrictions, you can lower them all the time. Encapsulation is a valuable good, it can help a great deal to keep things decoupled. It’s much harder going the other way, moving something from published down the road to private. For example, for interfaced classes (especially refcounted ones), I would recommend to put all interface methods under protected to enforce this way for such classes and just leave the CTOR/DTORs public.
Regarding getters/setters: If in doubt, make it a property. Delphi is smart enough to replace acesses to simple properties like
property foo : string read ffoo write ffoo;
with direct variable access, just check the generated CPU code.
Aside from that, I would prefer strict protected/private rather than just protected/private wherever possible.