Защищенное поле C# к частному, добавляет свойство - почему?

Если Вы смотрящий специально для в памяти JVM:

Runtime runtime = Runtime.getRuntime();

NumberFormat format = NumberFormat.getInstance();

StringBuilder sb = new StringBuilder();
long maxMemory = runtime.maxMemory();
long allocatedMemory = runtime.totalMemory();
long freeMemory = runtime.freeMemory();

sb.append("free memory: " + format.format(freeMemory / 1024) + "<br/>");
sb.append("allocated memory: " + format.format(allocatedMemory / 1024) + "<br/>");
sb.append("max memory: " + format.format(maxMemory / 1024) + "<br/>");
sb.append("total free memory: " + format.format((freeMemory + (maxMemory - allocatedMemory)) / 1024) + "<br/>");

Однако они должны быть взяты только оценка...

5
задан Sarah Vessels 9 November 2009 в 20:02
поделиться

8 ответов

Да, я думаю, вы правильно поняли - хотя в более поздних версиях C # есть более сжатый способ написать это:

public string Domain { get; set; }

Почему? Все дело в инкапсуляции. Если вы сделаете то, что предлагается, вы сможете позже изменить определение свойства Domain, не затрагивая вызывающий код, использующий это свойство.

13
ответ дан 18 December 2019 в 07:30
поделиться

В дополнение к другим ответам, упомянутым здесь, общедоступные / защищенные члены, начинающиеся с подчеркивания, не CLS-совместимы , поскольку нет требований для языков .NET. для поддержки членов с ведущими символами подчеркивания, поэтому кто-то, унаследовавший от вашего класса на другом языке .NET, может не иметь доступа к этому конкретному защищенному члену.

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

0
ответ дан 18 December 2019 в 07:30
поделиться

Ага. Это предложение. У вас не должно быть доступа выше private, представленного как прямые поля экземпляра.

Это один из основных принципов OOD - инкапсуляция, также называемая «сокрытием данных».

2
ответ дан 18 December 2019 в 07:30
поделиться

Ваш перевод правильный. Тот же аргумент, что и для использования «защищенных» свойств, может быть сделан для использования «общедоступных» свойств вместо непосредственного раскрытия переменных-членов.

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

protected string Domain { get; set; }
2
ответ дан 18 December 2019 в 07:30
поделиться
  1. Да, вы исправили код ошибки.
  2. Речь идет об инкапсуляции. _domain - это данные о вашем объекте. Вместо того, чтобы открывать его напрямую, чтобы любой клиент имел нефильтрованный доступ, вы должны предоставить им интерфейс для доступа к нему. На практике это может быть добавление проверки к сеттеру, чтобы он не мог быть установлен на какое-либо значение. Это может показаться глупым, если вы единственный, кто пишете код, потому что вы знаете, как работает ваш API. Но попробуйте подумать о вещах на уровне большого предприятия, лучше иметь API, чтобы ваш объект можно было рассматривать как коробку, которая выполняет задачу. Вы можете сказать, что у вас никогда не будет необходимости добавлять что-то вроде проверки к этому объекту, но все сделано таким образом, чтобы сохранить возможность этого, а также чтобы быть последовательным.
2
ответ дан 18 December 2019 в 07:30
поделиться

Отвечая на ваш вопрос ... да.

Однако я бы просто использовал синтаксис авто-свойств:

public abstract class Connection
{
    protected string Domain { get; set; }
}
0
ответ дан 18 December 2019 в 07:30
поделиться
  1. Да, вы исправили код проблемы.
  2. Речь идет об инкапсуляции. _domain - это данные о вашем объекте. Вместо того, чтобы открывать его напрямую, чтобы любой клиент имел нефильтрованный доступ, вы должны предоставить им интерфейс для доступа к нему. На практике это может быть добавление проверки к сеттеру, чтобы он не мог быть установлен на какое-либо значение. Это может показаться глупым, если вы единственный, кто пишете код, потому что вы знаете, как работает ваш API. Но попробуйте подумать о вещах на уровне большого предприятия, лучше иметь API, чтобы ваш объект можно было рассматривать как коробку, которая выполняет задачу. Вы можете сказать, что у вас никогда не будет необходимости добавлять что-то вроде проверки к этому объекту, но все сделано таким образом, чтобы сохранить возможность этого, а также чтобы быть последовательным.
2
ответ дан 18 December 2019 в 07:30
поделиться

В основном, свойства предоставляют больше, чем просто возврат или установку члена. Они позволяют добавлять логику, которая могла бы проверять правильный формат ввода, проверку диапазона и т. Д.

Выбранный ответ из ссылки лучше всего выражает это: «Свойства обеспечивают инкапсуляцию. Вы можете инкапсулировать любую необходимую проверку / форматирование / преобразование в коде. для свойства. Это было бы трудно сделать для полей "

http://social.msdn.microsoft.com/Forums/en-IE/netfxbcl/thread/985f4887-92ae-4ec2-b7ae-ec8cc6eb3a42

0
ответ дан 18 December 2019 в 07:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: