Если Вы смотрящий специально для в памяти 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/>");
Однако они должны быть взяты только оценка...
Да, я думаю, вы правильно поняли - хотя в более поздних версиях C # есть более сжатый способ написать это:
public string Domain { get; set; }
Почему? Все дело в инкапсуляции. Если вы сделаете то, что предлагается, вы сможете позже изменить определение свойства Domain, не затрагивая вызывающий код, использующий это свойство.
В дополнение к другим ответам, упомянутым здесь, общедоступные / защищенные члены, начинающиеся с подчеркивания, не CLS-совместимы , поскольку нет требований для языков .NET. для поддержки членов с ведущими символами подчеркивания, поэтому кто-то, унаследовавший от вашего класса на другом языке .NET, может не иметь доступа к этому конкретному защищенному члену.
Я знаю, это, вероятно, не относится к вам, но может быть причины предупреждения анализа кода.
Ага. Это предложение. У вас не должно быть доступа выше private, представленного как прямые поля экземпляра.
Это один из основных принципов OOD - инкапсуляция, также называемая «сокрытием данных».
Ваш перевод правильный. Тот же аргумент, что и для использования «защищенных» свойств, может быть сделан для использования «общедоступных» свойств вместо непосредственного раскрытия переменных-членов.
Если это приведет к быстрому увеличению числа простых геттеров и сеттеров, то я думаю, что ущерб удобочитаемость кода перевешивает преимущества возможности изменить код в будущем. С развитием свойств, генерируемых компилятором на C #, это не так уж и плохо, просто используйте:
protected string Domain { get; set; }
_domain
- это данные о вашем объекте. Вместо того, чтобы открывать его напрямую, чтобы любой клиент имел нефильтрованный доступ, вы должны предоставить им интерфейс для доступа к нему. На практике это может быть добавление проверки к сеттеру, чтобы он не мог быть установлен на какое-либо значение. Это может показаться глупым, если вы единственный, кто пишете код, потому что вы знаете, как работает ваш API. Но попробуйте подумать о вещах на уровне большого предприятия, лучше иметь API, чтобы ваш объект можно было рассматривать как коробку, которая выполняет задачу. Вы можете сказать, что у вас никогда не будет необходимости добавлять что-то вроде проверки к этому объекту, но все сделано таким образом, чтобы сохранить возможность этого, а также чтобы быть последовательным. Отвечая на ваш вопрос ... да.
Однако я бы просто использовал синтаксис авто-свойств:
public abstract class Connection
{
protected string Domain { get; set; }
}
_domain
- это данные о вашем объекте. Вместо того, чтобы открывать его напрямую, чтобы любой клиент имел нефильтрованный доступ, вы должны предоставить им интерфейс для доступа к нему. На практике это может быть добавление проверки к сеттеру, чтобы он не мог быть установлен на какое-либо значение. Это может показаться глупым, если вы единственный, кто пишете код, потому что вы знаете, как работает ваш API. Но попробуйте подумать о вещах на уровне большого предприятия, лучше иметь API, чтобы ваш объект можно было рассматривать как коробку, которая выполняет задачу. Вы можете сказать, что у вас никогда не будет необходимости добавлять что-то вроде проверки к этому объекту, но все сделано таким образом, чтобы сохранить возможность этого, а также чтобы быть последовательным. В основном, свойства предоставляют больше, чем просто возврат или установку члена. Они позволяют добавлять логику, которая могла бы проверять правильный формат ввода, проверку диапазона и т. Д.
Выбранный ответ из ссылки лучше всего выражает это: «Свойства обеспечивают инкапсуляцию. Вы можете инкапсулировать любую необходимую проверку / форматирование / преобразование в коде. для свойства. Это было бы трудно сделать для полей "
http://social.msdn.microsoft.com/Forums/en-IE/netfxbcl/thread/985f4887-92ae-4ec2-b7ae-ec8cc6eb3a42