Переопределение полей или свойств в подклассах

Question

У меня есть абстрактный базовый класс, и я хочу объявить поле или свойство, которое будет иметь разные значения в каждом классе, который наследуется от этого родительского класса.

Я хочу определить его в базовом классе, чтобы я мог ссылаться на него в методе базового класса - например, переопределив ToString, чтобы сказать «Этот объект имеет тип свойство / поле ». У меня есть три способа сделать это, но мне было интересно - как лучше всего это сделать? Вопрос новичка, извините.

Вариант 1:
Используйте абстрактное свойство и переопределите его в унаследованных классах. Это полезно от принудительного применения (вы должны переопределить его), и оно чисто. Но кажется немного неправильным возвращать значение жесткого кода, а не инкапсулировать поле, и это всего лишь несколько строк кода, а не просто. Я также должен объявить тело для «set», но это менее важно (и, вероятно, есть способ избежать того, о чем я не знаю).

abstract class Father
{
    abstract public int MyInt { get; set;}
}

class Son : Father
{
    public override int MyInt
    {
        get { return 1; }
        set { }
    }
}

Вариант 2
Я могу объявить открытое поле (или защищенное поле) и явно переопределить его в унаследованном классе. Приведенный ниже пример предупредит меня об использовании «new», и я, вероятно, могу это сделать, но он кажется неправильным и нарушает полиморфизм, что и было всем. Не кажется хорошей идеей ...

abstract class Mother
{
    public int MyInt = 0;
}

class Daughter : Mother
{
    public int MyInt = 1;
}

Вариант 3
Я могу использовать защищенное поле и установить значение в конструкторе. Это выглядит довольно аккуратно, но я полагаюсь на то, что конструктор всегда устанавливает это, а при наличии нескольких перегруженных конструкторов всегда существует вероятность того, что путь кода не установит значение.

abstract class Aunt
{
    protected int MyInt;
}

class Niece : Aunt
{
    public Niece()
    {
        MyInt = 1;
    }
}

Это немного теоретический вопрос, и я думаю, что ответ должен быть вариант 1, так как это единственный безопасный вариант, но я только начинаю разбираться с C # и хотел спросить это у людей с больше опыта.

Answer 1

Только из трех решений Вариант 1 является полиморфным .

Поля сами по себе не могут быть переопределены. Именно поэтому Опция 2 возвращает предупреждение о ключевом слове new .

Решение для предупреждения заключается не в добавлении ключевого слова «new», а в реализации варианта 1.

Если ваше поле должно быть полиморфным, вам нужно обернуть его в свойстве.

Опция 3 в порядке, если вам не нужно полиморфное поведение. Однако следует помнить, что при доступе к свойству MyInt производный класс не имеет никакого контроля над возвращаемым значением. Базовый класс сам по себе способен возвращать это значение.

Так может выглядеть по-настоящему полиморфная реализация вашего свойства, позволяя производным классам находиться в control .

abstract class Parent
{
    abstract public int MyInt { get; }
}

class Father : Parent
{
    public override int MyInt
    {
        get { /* Apply formula "X" and return a value */ }
    }
}

class Mother : Parent
{
    public override int MyInt
    {
        get { /* Apply formula "Y" and return a value */ }
    }
}

Answer 2

Вариант 2 не является стартовым - вы не можете переопределить поля, вы можете только скрыть их.

Лично я бы выбрал вариант 1 каждый раз. Я стараюсь всегда держать поля закрытыми. Это, если вам действительно нужно иметь возможность переопределить свойство вообще, конечно. Другой вариант - иметь свойство только для чтения в базовом классе, которое устанавливается из параметра конструктора:

abstract class Mother
{
    private readonly int myInt;
    public int MyInt { get { return myInt; } }

    protected Mother(int myInt)
    {
        this.myInt = myInt;
    }
}

class Daughter : Mother
{
    public Daughter() : base(1)
    {
    }
}

Вероятно, это наиболее подходящий подход, если значение не изменяется в течение времени жизни экземпляра.

Answer 3

вариант 2 - плохая идея. Это приведет к тому, что называется затенением; По сути, у вас есть два разных члена «MyInt», один в матери, а другой в дочери. Проблема заключается в том, что методы, которые реализованы в матери, будут ссылаться на «MyInt» матери, в то время как методы, реализованные в дочери, будут ссылаться на «MyInt» дочери. это может вызвать некоторые серьезные проблемы с читабельностью и привести к путанице в дальнейшем.

Лично я считаю, что лучшим вариантом является 3; потому что он обеспечивает четкое централизованное значение, и на него могут ссылаться дети, не стесняясь определять свои собственные поля - что является проблемой с вариантом 1.

Answer 4

Вы можете определить что-то вроде этого:

abstract class Father
{
    //Do you need it public?
    protected readonly int MyInt;
}

class Son : Father
{
    public Son()
    {
        MyInt = 1;
    }
}

Устанавливая значение только для чтения, оно гарантирует, что значение для этого класса останется неизменным в течение всего времени жизни объекта.

Полагаю, следующий вопрос: зачем тебе это?

Answer 5

Вы могли бы сделать это

class x
{
    private int _myInt;
    internal virtual int myInt { get { return _myInt; } set { _myInt = value; } }
}

class y : x
{
    private int _myYInt;
    public override int myInt { get { return _myYInt; } set { _myYInt = value; } }
}

virtual позволяет получить свойство - тело, которое что-то делает, и все же позволяет подклассам переопределять его.

Answer 6

Если вы строите класс и хотите, чтобы для свойства существовало базовое значение, используйте ключевое слово virtual в базовом классе. Это позволяет вам при желании переопределить свойство.

Используя ваш пример выше:

//you may want to also use interfaces.
interface IFather
{
    int MyInt { get; set; }
}


public class Father : IFather
{
    //defaulting the value of this property to 1
    private int myInt = 1;

    public virtual int MyInt
    {
        get { return myInt; }
        set { myInt = value; }
    }
}

public class Son : Father
{
    public override int MyInt
    {
        get {

            //demonstrating that you can access base.properties
            //this will return 1 from the base class
            int baseInt = base.MyInt;

            //add 1 and return new value
            return baseInt + 1;
        }
        set
        {
            //sets the value of the property
            base.MyInt = value;
        }
    }
}

В программе:

Son son = new Son();
//son.MyInt will equal 2

Answer 7

Я сделал это ...

namespace Core.Text.Menus
{
    public abstract class AbstractBaseClass
    {
        public string SELECT_MODEL;
        public string BROWSE_RECORDS;
        public string SETUP;
    }
}

namespace Core.Text.Menus
{
    public class English : AbstractBaseClass
    {
        public English()
        {
            base.SELECT_MODEL = "Select Model";
            base.BROWSE_RECORDS = "Browse Measurements";
            base.SETUP = "Setup Instrument";
        }
    }
}

Таким образом, вы все еще можете использовать поля.

Answer 8

Вы можете воспользоваться опцией 3, если вы измените свой абстрактный базовый класс, чтобы требовать значение свойства в конструкторе, вы не пропустите ни одного пути. Я бы действительно рассмотрел этот вариант.

abstract class Aunt
{
    protected int MyInt;
    protected Aunt(int myInt)
    {
        MyInt = myInt;
    }

}

Конечно, тогда у вас все еще есть возможность сделать поле частным, а затем, в зависимости от необходимости, выставить получателя защищенной или публичной собственности.

Answer 9

Я бы выбрал вариант 3, но у меня есть абстрактный метод setMyInt, который подклассы вынуждены применять Таким образом, у вас не будет проблемы с производным классом, забывшим установить его в конструкторе.

abstract class Base 
{
 protected int myInt;
 protected abstract void setMyInt();
}

class Derived : Base 
{
 override protected void setMyInt()
 {
   myInt = 3;
 }
}

Кстати, с первым вариантом, если вы не указали set; в вашем абстрактном свойстве базового класса производный класс не должен будет его реализовывать.

abstract class Father
{
    abstract public int MyInt { get; }
}

class Son : Father
{
    public override int MyInt
    {
        get { return 1; }
    }
}