Тривиальные свойства когда-либо убирались подобру-поздорову?
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
10 ответов
Может быть трудно заставить код работать в неопределенном будущем, но это не оправдание быть ленивым. Кодирование свойства по полю является конвенцией, и это прагматично. Назовите это безопасным программированием.
Другие люди будут также жаловаться, что существует проблема скорости, но JIT'er достаточно умен для создания ее примерно с такой скоростью, как представление общедоступного поля. Достаточно быстро то, что я никогда не буду замечать.
Некоторые нетривиальные вещи, которые приходят на ум
- поле общественности А, полностью общедоступны, Вы не можете наложить семантику только для записи или только для чтения
- , свойство А может иметь, имеют отличающийся
getпо сравнению сsetдоступность (например, общественность добираются, внутренний набор) - , Вы не можете переопределить поле, но у Вас могут быть виртуальные свойства.
- Ваш класс не имеет никакого контроля над общедоступным полем
- , Ваш класс может управлять свойством. Это может ограничить установку на допустимый диапазон значений, флаг, что состояние было изменено, и даже ленивая загрузка значение.
- Отражательная семантика отличаются. Общедоступное поле не является свойством.
- Никакая привязка данных, как другие указывают. (Это - только ошибка Вам. - Я могу понять, Почему разработчики платформы .NET не поддерживают шаблоны, которые они не выступают за.)
- Вы не можете поместить поле на интерфейс, но можно поместить свойство на интерфейс.
- Ваше свойство не должно даже хранить данные. Можно создать фасад и отправить содержащему в нем объекту.
Вы только вводите дополнительные 13 символы для правильности. Это едва походит на спекулятивную общность. Существует семантическое различие, и если ничто иное, свойство имеет другое семантическое значение и намного более гибко, чем общедоступное поле.
public string Name { get; set; }
public string name;
я действительно вспоминаю одно время, когда первое использование .net I кодировало несколько классов так же просто поля, и затем у меня должны были быть они как свойства по некоторым причинам, и это была полная пустая трата времени, когда я, возможно, просто сделал это, исправляются в первый раз.
Поэтому, какие причины Вы имеете для не в соответствии с конвенцией? Почему Вы чувствуете потребность плавать в восходящем направлении? Что это сохранило Вас, не делая это?
Часть идеи - то, что те свойства не могут быть тривиальными в будущем - если бы Вы связали внешний код с полем и позже хотели перенести это в свойство, то весь зависимый код должен будет измениться, и Вы не можете делать это, особенно в случае, где Вы - разработчик управления или имеете библиотеки, которыми Вы не можете управлять, и т.д.
Не говоря уже о существуют определенные методы.NET, которые не позволят Вам использовать поле - связывающий с данными особенно.
я уверен, что также существуют другие серьезные основания. Почему это имеет значение для Вас? Используйте автоматическое свойство и будьте сделаны с ним. Походит на что-то, которое не стоит быть затронутым собирающийся меня...
Я раньше думал то же самое, Jay. Почему используют свойство, если это только там для обеспечения прямой доступ к члену парламента, не занимающему официального поста? Если можно описать это как автосвойство, имея свойство вообще, а не поле казалось довольно глупым. Даже если когда-нибудь необходимо изменять реализацию, Вы могли бы всегда просто осуществить рефакторинг в недвижимость позже, и какой-либо зависимый код будет все еще работать, правильно?. Ну, возможно, нет.
Вы видите, я недавно видел свет на тривиальных свойствах, поэтому возможно, теперь я могу помочь Вам сделать то же.
то, Что наконец убедило меня, было довольно очевидным фактом (ретроспективно), что свойства в .NET являются просто синтаксическим сахаром для методов получателя и методов установщика, и те методы имеют другое имя от самого свойства. Код в том же блоке будет все еще работать, потому что необходимо перекомпилировать его одновременно так или иначе. Но любой код в другом блоке, который связывает с Вашим желание сбой , если Вы осуществляете рефакторинг поле к свойству, если это не перекомпилировано против Вашей новой версии одновременно. Если это - свойство с самого начала, все все еще хорошо.
У меня было тривиальное свойство, сохраняют меня пару раз при отладке. .NET не поддерживает понятие точки прерывания по данным (читайте или запишите). Иногда при отладке очень сложного сценария было важно отследить чтение-записи к особому свойству. Это легко со свойством, но невозможно с полем.
, Если Вы не работаете в продуктивной среде, просто осуществить рефакторинг поле-> свойство в целях отладки. Иногда, хотя Вы поражаете ошибки, которые только воспроизводят в продуктивной среде, которую трудно исправить с новым двоичным файлом. Свойство может сохранить Вас здесь.
Это - довольно ограниченный сценарий все же.
Намного легче отладить проблему, включающую поле, если это перенесено средством доступа свойства. Размещение точек останова в средстве доступа может вполне быстро помочь с нахождением повторной входимости и других проблем, которые иначе не могли бы быть пойманы. Путем маршалинга всего доступа к полю через средство доступа можно установить точно, кто изменяется какой и когда.
В.NET, от моего понимания, Вы не можете связать с данными к общедоступным полям; но только к свойствам. Таким образом, если Вы хотите сделать привязку данных, у Вас нет выбора.
Я отвечу на Ваш вопрос с другим: Вы когда-либо действительно извлекали выгоду из того, чтобы не обнародовать все Ваши типы и участников? Я подозреваю, что непосредственно не предотвратил ошибок путем выполнения так. Однако я инкапсулировал свои типы правильно, только выставляя то, что предназначено, чтобы быть выставленным. Свойства подобны - хороший дизайн больше, чем что-либо еще. Я думаю о свойствах как концептуально отличающийся от полей; они - часть контракта вместо того, чтобы быть существенно частью реализации. Размышление о них как свойства, а не поля помогает мне думать более ясно о своем дизайне, ведя к лучшему коду.
, О, и я иногда извлекал выгоду из не повреждающейся исходной совместимости, способность установить точки останова, доступ журнала и т.д.
У меня когда-то были поля, которые я хотел выставить от окна из проекта, который позволил статистику для программы (TotalItems и SuccessfulItems).
Позже я решил отобразить статистику на форме и смог добавить вызов в методе set, который обновил дисплей когда измененное свойство.
По моему скромному мнению, нет такой вещи как тривиальное свойство, как люди называли их. Через путь вещи, такие как привязка данных работы, Microsoft подразумевала, что любой бит данных, которые являются частью открытого интерфейса объекта, должен быть свойством. Я не думаю, что они означали, что это просто, чтобы быть конвенцией как он находится на некоторых других языках, где синтаксис свойства больше о конвенции и удобстве.
А более интересный вопрос может быть: "Когда я должен использовать общедоступное поле вместо свойства", или, "Когда общедоступное поле вместо общественной собственности убралось подобру-поздорову?"
Очевидно, если Вы не создадите общую библиотеку классов, и Вы не используете DataBinding, то затем использование поля вызовет Вас никакие проблемы вообще.
, Но если бы Вы создаете общую библиотеку классов, Вы были бы глупы, по моему скромному мнению, сделать иначе, чем следуют инструкциям, по обычным трем причинам:
-
потребители Вашей общей библиотеки классов могут хотеть использовать DataBinding.
-
потребители Вашего общего класса могли бы хотеть совместимость на уровне двоичных кодов, которая не возможна, если Вы переключаетесь от поля до свойства.
-
принципал наименьшего количества удивления подразумевает, что необходимо согласовываться с другими общими библиотеками классов включая саму Платформу.NET.