I've inherited a project and the developer uses lots of interfaces (All good here!).
I've inherited a project and the developer uses lots of interfaces (All good here!).
Then when they develop the interfaced classes, the methods from the interface are added in the private section of the class instead of the public.
All works good because of the interface.
I was wondering if this structure is a problem.
Then when they develop the interfaced classes, the methods from the interface are added in the private section of the class instead of the public.
All works good because of the interface.
I was wondering if this structure is a problem.
John Kouraklis Got it. I would ask why change the visibility in the class declaration? It won't alter the actual visibility controlled by the interface. I don't see that it does any harm, apart from offering a degree of confusion.
ReplyDeleteThe compiler will map the methods declared in the interface to the correct methods in the class no matter if they are private, protected or public.
ReplyDeleteThe disadvantage is from a re-usability point of view (inheritance). Making methods "private" means that a descendent class can't simply access those methods.
And completely hiding a class in the implementation section of a unit (exposing only the class factory) means that none of that code can be inherited/modified/re-used. The class is effectively sealed forever.
Often it is better to separate the interface and its implementations into different units (and maybe even a third unit that contains the class factories).
That way you can still hide the implementation, whilst retaining the possibility to inherit from the base classes and re-using code.
/sub
ReplyDelete