геттеры и сеттеры для суперклассов?

Question

Является ли все еще стандартной практикой предоставление методов получения и установки в суперклассе, для подклассов для доступа к атрибутам суперкласса (другими словами, установить атрибуты как частные)?Или доступ к атрибутам должен осуществляться напрямую (объявлять атрибуты защищенными) подклассами?

Существует ли стандартное соглашение?

Answer 1

Это полностью зависит от того, чего вы хотите достичь.

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

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

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

Answer 2

Кажется, что в C # стандартной практикой является использование свойств с аксессорами get / set.В упрощенной форме вы будете иметь:

public string Name { get; set; }

Но вы можете лучше контролировать уровень доступа, например:

public string Name { get; protected set; }

Здесь вы публично предоставляете метод get, нооставьте метод set только для производных классов.

Еще одно преимущество использования средств доступа вместо прямого доступа к элементу данных состоит в том, что вы можете поставить точку останова на метод get / set и посмотреть, кто выполнил метод.
Это, однако, невозможно с помощью трюка { get; set; }.Вам нужно будет написать полную расширенную форму свойства:

private string m_Name = string.Empty;
public string Name
{
    get { return m_Name; }  // Put a happy breakpoint here
    set { m_Name = value; } // or here.
}

Будет безопасно отразить ту же концепцию для Java.

Answer 3

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

Если член должен быть прочитан подклассами, но не записан, вы можете определить член как свойство, которое защищено, но с частным установщиком:

//as of C# 3.0 this can also be an auto-property
private string myValue;
protected string MyValue 
{
   get{return myValue;} 
   private set{myValue = value;}
}

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

В общем, как разработчик суперкласса, вы сами должны определить, как подклассы должны иметь возможность использовать то, что выпредоставлять.Если вы делаете что-то защищенное, предположите, что подклассы будут делать все, что позволяет им «защищенный».И в C #, и в Java есть методы, с помощью которых вы можете независимо контролировать видимость доступа для чтения и записи.

Answer 4

В Java я предпочитаю делать все свои поля приватными. Если мне действительно нужно что-то выставить, я создаю отдельный, защищенный геттер для поля. (Например, если реализуемый мной интерфейс требует более широкого типа возвращаемого значения, чем тот, который я хочу передать между различными уровнями реализаций.)

С инструментами, которые могут генерировать геттеры / сеттеры одним щелчком мыши, я никогда не чувствовал необходимости нарушать инкапсуляцию даже между родительскими / дочерними классами.

Answer 5

Проверьте два верхних ответа на этот вопрос:

Являются ли геттеры и сеттеры плохим дизайном?Наблюдаются противоречивые советы

Не очень хороший ответ на ваш вопрос, но вы, очевидно, заинтересованы в кодировании хорошего ОО, поэтому вам следует подумать над ними.

Answer 6

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

Мое личное предпочтение - использовать методы получения и установки, где абсолютнотребуется только и никогда не иметь общедоступных переменных.