Adding virtual + override support in AmazonS3Client

[stephbu]

I'm thinking about subclassing options for AmazonS3Client - its not marked as sealed, opening the door - but none of the methods are marked virtual, making subclassing less valuable.

The specific scenario I had in mind was retrospectively adding cached support - by enabling effectively "drop in replacements" wherever AmazonS3Client was used. (currently have factory object that instantiates AmazonS3Clients - could imagine that issuing CachingAmazonS3Clients instead without changing the rest of the code)

Wondered how far from project intent this would be.

This could be achieved by encapsulation of AmazonS3Client within another factory class -the work required to implement subclass and factory are quite similar - but it implies another round of refactoring to introduce the factory object.

Flicking through AmazonS3Client there is of course lots of implementation detail in these members - so you'd almost certainly need to call base at all times to get core functionality.

I suspect there are other places where this would be useful too.

[PavelSafronov]

This can already be done with the existing SDK, simply by using the AmazonS3 interface. If you modify all your code to use the interface instead of the concrete class (AmazonS3Client), then you can implement the class CachingAmazonS3Clients that implements AmazonS3, but with caching. The new class could then use an instance of AmazonS3Client for non-cached calls.