Refactor default parameters on interface, virtual methods about ontopic-library HOT 1 OPEN

The downside of this is that these overloads are only available if the namespace of the extension method is in scope.

That can be a problem when derived classes relying on those overloads are in a different namespace. E.g.,

• OnTopic.Repositories.ITopicRepository
• OnTopic.Data.Sql.SqlTopicRepository

In this case, if the caller only applies a using statement for OnTopic.Data.Sql.SqlTopicRepository, then the defaults won’t be available.

That said, this issue is at least mitigated for interfaces and/or abstract classes intended for use with dependency injection, such as ITopicRepository, since code references for dependencies should only be aware of the interface or abstract class, and not the concrete implementations, and will thus use the using statement for the interface (e.g., OnTopic.Repositories).

The only exception to this is in the composition root, when assembling the dependency graph, where there will be references to the concrete class. (This also applies when registering dependencies via a container.) Since constructors for dependency injection shouldn’t have optional or default parameters, however, this doesn’t affect that case.

This concern, however, may impact classes which are subject to extensibility, but not subject to dependency injection.

The alternative in those cases is to continue to rely on defaults on the interface and virtual methods, as we do today. As “Framework Design Guidelines” warns, however:

A disagreement between an interface declaration and the implementation on a default value creates an unnecessary source of confusion for your users.

As such, this should be carefully considered.

from ontopic-library.