refactor(core): separate public/private API of IService
Description
IService
is one the most important and widely used class interface of Sight
. It is currently quite heavy and a significant part of its interface is not meant to be private. A big part of it is only used for instance by the AppConfigManager
which is part of the same library.
The expected benefit is to gain readability, and we also might reduce build time.
Functional specifications
- Separate
IService
public and private API.
Technical specifications
- Separate
IService
public and private API with the pimpl idiom (sight::service::detail::IService
)- All functions used only by the
AppConfigManager
should be in the private part - Only keep virtual functions in the public API
- All functions used only by the
-
sight::service::ObjectService
should go the in be private section
Test plan
Nothing more than usual CI tests.