Example: class SqlConnectionDataProvider.
Lets’ say I want to create a custom SqlConnectionDataProvider:
public class MyDbDataProvider : SqlConnectionDataProvider
{
public MyDbDataProvider(string hostName, string client)
: base(CreateConnection(string hostName, string client))
{
}
private static SqlConnection CreateConnection(string hostName, string client)
{
return new SqlConnection(...);
}
public override Init()
{
base.Init();
// Do something after Init();
}
}
From my point, if the developer follows the Liskov Supstitution principle, there is no reason to be so restrictive, since any class that inherits SqlConnectionDataProvider will behave like its parent class.
Of course this suggestion is not limited to DataProviders.
For instance It would make sense if I could just inherit from DesignerFunction and override a virtual method CheckFunctionSyntax / EvaluateFunction instead of creating a DesignerFunction instance and handeling the events.
Even if I would implement the IDesignerFunction interface myself to achive this I could not assign it to an ListLabel instance because ListLabel.DesignerFunctions.Add(...) only accepts an DesignerFunction instance and not an IDesignerFunction implementation. And DesignerFunction is sealed.