I'm designing a configurable api and I've seen a few ways to accept options from the caller. One is using an options object like so:var options = new MyApiConfigurationOptions {    Option1 = true,    Option2 = false};var api1 = MyApiFactory.Create(options);Another is using a configuration function:var api2 = MyApiFactory.Create(o => {    o.Option1 = true;    o.Option2 = false;});Is one approach any better/worse/different than the other? Is there any real difference or would it be nice to support both so the caller can use whatever syntax they prefer?
Configuration object vs function
c#;configuration
The function approach, whilst appearing less intuitive at first glance, has a couple of significant advantages:The function is supplied with the config object, ie the API has total control over the creation of the object. It could have internal only constructors for example, ensuring only the API itself gets to create the object.The API can support full-blown delayed initialisation. Not only can the API perform lazy initialisation of itself, it gets to then call back to the main code in a delayed fashion for the configuration data. Such an approach can prove really useful when, for example, plumbing together a system via IoC, allowing references to the API object to be injected into various objects and then the configuration supplied to the API afterwards.It's all too easy to dismiss this approach as just being fancy for fanciness' sake or obscure and pointless. But take the time to understand the benefits and it's easy to see why it can be a powerful (and simple to understand once the concept is understood) mechanism.Of course, whether you need the function-approach completely depends on your API. If neither of the above points offer any obvious benefits to your code, then more devs will find your API easier to use if you adopt the simpler approach.