Now that ClientBufferDepository is a concrete class, injecting it into MirSurface is much less useful. I'd rather we injected the BufferFactory directly, and make the ClientBufferDepository an implementation detail. This direction is also supported by the MirSurface tests, where we currently need to mock an indirect dependency of the class under test. This approach presumes that we don't need to share depositories between surfaces, which seems to be the case currently.
Concerning making ClientBufferDepository concrete in the first place, I think it's a valid option as long as we are still able to perform the tests we want. The MirSurface unit-tests need some more tests (e.g. MirSurface.get_buffer_returns_last_received_buffer), so perhaps we are not yet at a position to answer this.
Now that ClientBufferDep ository is a concrete class, injecting it into MirSurface is much less useful. I'd rather we injected the BufferFactory directly, and make the ClientBufferDep ository an implementation detail. This direction is also supported by the MirSurface tests, where we currently need to mock an indirect dependency of the class under test. This approach presumes that we don't need to share depositories between surfaces, which seems to be the case currently.
Concerning making ClientBufferDep ository concrete in the first place, I think it's a valid option as long as we are still able to perform the tests we want. The MirSurface unit-tests need some more tests (e.g. MirSurface. get_buffer_ returns_ last_received_ buffer) , so perhaps we are not yet at a position to answer this.