4

Is it wrong to initialize a virtual property in the constructor? It just does not feel right because if you override the property in a derived class the property will first be initialized with the value from the base class constructor then it will be assigned again by the derived class constructor. is there an alternative for doing this? I'm talking about something like this

internal class B1
{
    public B1()
    {
        Ti = "Hello";
    }

    public virtual string Ti { get; set; }
}

internal class B2 : B1
{
    public B2()
    {
        Ti = "HelloKitty";
    }

    public override string Ti { get; set; } //<--"Hello" will be assigned first then "HelloKitty" will be assigned
}

internal class Program
{
    private static void Main(string[] args)
    {
        var b2 = new B2();
        Console.WriteLine(b2.Ti);
        Process.GetCurrentProcess().WaitForExit();
    }
}

UPDATE 1: As recommended by @AK_

internal class Bb1
{
    private string _ti;

    public Bb1()
    {
        _ti = "Hello";
    }

    public virtual string Ti
    {
        get { return _ti; }
        set { _ti = value; }
    }
}

internal sealed class Bb2 : Bb1
{
    public Bb2()
    {
        Ti = "HelloKitty";
    }

    public override string Ti { get; set; }
}

the variable _ti in the base class is initialized by "Hello". _ti is still in the base class

what if instead of string type I'm using type which explicitly needs to be exposed?

Abdullah Saleem
  • 3,701
  • 1
  • 19
  • 30

1 Answers1

1

On the other hand this is reasonable (notice that B2 is sealed )

internal class B1
{
    private string m_ti;
    public virtual string Ti { get{return m_ti;} set{m_ti = value;} }
    public B1()
    {
        m_ti = "Hello";
    }


}

internal sealed class B2 : B1
{
    public B2()
    {
        Ti = "HelloKitty";
    }

    public override string Ti { get; set; } //<--"Hello" will be assigned first then "HelloKitty" will be assigned
}

another option a protected constructor:

internal class B1
{
    private string m_ti;
    public virtual string Ti { get { return m_ti; } set { m_ti = value; } }
    public B1()
    {
        m_ti = "Hello";
    }

    protected B1(String word)
    {
        m_ti = word;
    }
}

internal sealed class B2 : B1
{
    public B2():base("kitty")
    {

    }
}
AK_
  • 7,981
  • 7
  • 46
  • 78
  • 1
    It's also ok if you seal the property itself (in which case you don't need to seal the entire class) – Matthew Watson Feb 07 '15 at 13:00
  • my point was using the private data member, and avoiding the property. but you are right too... – AK_ Feb 07 '15 at 13:03
  • But the base class will still contain the m_ti which is assigned to "Hello". what if we are not talking about string, a type which explicitly needs to be disposed? – Abdullah Saleem Feb 07 '15 at 13:06
  • @AbdullahSaleem then it would be a bad idea. Look i don't know what you are trying to do, but is sounds like something that requires composition and not inheritance. – AK_ Feb 07 '15 at 13:10
  • @AbdullahSaleem look at the edit... – AK_ Feb 07 '15 at 13:15
  • @AK_ then there is no point in making the property virtual? – Abdullah Saleem Feb 07 '15 at 13:18
  • @AbdullahSaleem it depends on what you are actually doing. In this specific example, you are right - it doesn't make sense. – AK_ Feb 07 '15 at 13:21
  • @AK_ let us suppose instead of 1 virtual property we have 10 virtual properties, all of them need to be initialized in the base constructor and we want to override 5 of them in the derived class? Will we make a constructor with 10 arguments? – Abdullah Saleem Feb 07 '15 at 13:25
  • @AbdullahSaleem I would probably use a Builder design pattern then... http://en.wikipedia.org/wiki/Builder_pattern – AK_ Feb 07 '15 at 13:39