+1 800 256 3608 (toll-free in North America) or +49 7531 90 60 10| service@combit.com

Do not seal your classes.

(combit Team) #1

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.
(combit - Jochen Bartlau) #2

We’ll look at this in LL22. As a workaround in the meantime, our full sources are available to subscription customers.

(combit - Jochen Bartlau) #3

We’ve just changed the signature for the Add() method to accept IDesignerFunction in LL22. Thanks for the suggestion. Leaving this open as the “sealed” topic also refers to other classes.