Re: [Flightgear-devel] Abstracting/Mocking FGScenery

[James T. <ja...@fl...>]

> On 3 Oct 2022, at 16:38, Keith Paterson <mid...@gm...> wrote:
> 
> Yes it looks like a half way house. I don't imagine I can create a mock for FGScenery without finishing cleaner dependency tree. 
> 

I think you can do the mock without touching this stuff, because your mock won’t have any upstream dependencies, I would say. (Unless I’m missing something fundamental)

> From my previous expirience with systems like Osgi here some ideas : 
> 
> Each subsystem must directly inherit from SGSubSystem. (required by the registrar) 
> The staticSubsystemClassId() must reside in a abstract base class for all implementations of said subsystem otherwise getSubsystem<Subsystem>() will pull in a certain Impl
> This superclass will also include the public interface of said subsystem

Right, for any subsystem we want to mock, that’s what we need to do. 

Except … actually there is another approach I’ve used sometimes, which is to use the pimpl idiom, and have real- and mock- versions of the pimpl, i.e a single FGScenery containing a std::unique_ptr<FGScenery::Impl> which is an interface, and then FGScenery::RealImpl and FGScenery::MockImpl. This keeps the outside view clear, but tends to make the internals a bit less clear than a ‘normal’ pimpl pattern.

I would say for FGScenery the original approach we discussed is better, because switching to a pimpl style is just as disruptive as switching to an abstract superclass, but for some other systems which already use pimpls the opposite would be true.

Kind regards,
James