1

I'm getting Resharper warnings here in the base form where I set the EditMyDataObject property, and in the extended form where I grab the Text value and then restore it afterwards.

In both cases nothing is blowing up when I run the app. I don't think there's any potential for problems as implemented because my overridden property doesn't depend on anything initialized in the constructor, but would appreciate a 2nd opinion before gagging Resharper.

public class MyDataObject
{
    //Data Members

    public MyDataObject()
    {
    }
}

public class MyDataObjectEx : MyDataObject
{
    //Data Members

    public MyDataObjectEx()
    {
    }

    public MyDataObjectEx(MyDataObject myDataObject)
    {
    }       
}

public partial class MyDataObjectEditFrm : Form
{
    private MyDataObject _myDataObject;

    protected virtual MyDataObject EditMyDataObject
    {
        get { return _myDataObject; }
        set { _myDataObject = value; }
    }

    /// <summary>
    /// Parameterless constructor needed for designer support of derived classes.
    /// </summary>
    protected MyDataObjectEditFrm()
    {
        InitializeComponent();
    }

    protected MyDataObjectEditFrm(MyDataObject myDataObject)
    {
        InitializeComponent();
        EditMyDataObject = myDataObject;  // Warning: Virtual member call in a constructor

        Text = GetDialogNameFromInputParameters()

        //Remainder of initialization here
    }

    GetDialogNameFromInputParameters()
    {
        //Figure out what the text should be
    }
}


public partial class MyDataObjectExEditFrm : MyDataObjectEditFrm
{
    private MyDataObjectEx _myDataObjectEx;

    protected override MyDataObject EditMyDataObject
    {
        get { return _myDataObjectEx; }
        set
        {
            if (value == null)
                _myDataObjectEx = null;
            else _myDataObjectEx = value as MyDataObjectEx ?? new MyDataObjectEx(value);
        }

    }

    public MyDataObjectExEditFrm(MyDataObject myDataObject) : base(myDataObject)
    {
        //preserve the value computed and set in the base class to prevent the generic form name from the designer overriding it here
        string dialogText = Text; // Warning: Virtual member call in a constructor
        InitializeComponent();
        Text = dialogText; // Warning: Virtual member call in a constructor


        //Remainder of additional initialization for extended data here
    }
}


  • EDIT: wrong, thanks Daniel If you want, you can remove the first warning by setting the underlying variable instead of property. I don't have an opinion on this being a good idea or not, I'm just saying. - jv42
  • @jv42: That would change the behavior. Have a look at the overridden property, it has some logic in it... - Daniel Hilgarth
  • @vj42: I think I tried that, but it caused problems when MyDataObjectExEditForm was only passed a base MyDataObject because it wasn't converted to a MyDataObjectEx - Dan Neely
  • Yes sorry, I missed the fact that you were actually overriding it in the derived class. - jv42
  • You can always pipe the virtual call into an abstract method, which forces any derived classes to implement this abstract method. This means that its impossible for the class not to implement the method, which means that there can never be any errors with missing methods in an inherited class. This future proofs your class. - Contango

1 답변


6

As long as each derived class overrides this virtual member in a way that it doesn't rely on variables that are initialized in the constructor of that derived class, you are safe. Problem is, you can't know that every class that derives from your base class behaves like this. Because of that, the warning is legit.


  • I knew it was possible to screw things up in the future; but since it's not a public library the hazard is manageable if it can't be redesigned away without losing functionality. - Dan Neely

Related

Latest