Всем привет!
есть вот такой код:

внутри класса я почти некогда не обращаюсь к свойству, а обращаюсь напрямую к полю, чтобы не запускать механизм доступа к полям класса. Обращаюсь к свойству, только если в методах get/set производятся какие-то необходимые действия. Правильно ли я делаю?

А оно не важно  
Умный компилятор все равно преобразует обращение к свойству такого типа на обращение к полю.

P.S. Хотя я точно так же делаю

emmanuil, по-моему абсолютно правильно.. ) 
как еще внутри класса с полем работать? может тебе не нужно выполнять внутри класса те действия, которые выполняются при вызове свойства (ну допустим если бы у тебя они выполнялись 8)).

Правильно, если пишете программу для себя и модифицировать ее вам врядли придется (имхо, в таком случае вы пишете бесполезную программу), в любом противном случае неправильно.

Простое добавление проверки правильности изменения атрибута класса повлечет перенаправление всех внутренних вызовов на свойство (например если в вашем случае необходимо будет добавить проверку при установке ссылки на строку на то, что она не может быть нулевой ссылкой). Кроме того при анализе кода необходимо анализировать все точки обращения к атрибуту напрямую.

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

является преждевременной (в большинстве случаев бесполезной) оптимизацией.

да ну.. для того это и делается чтоб не были доступны извне класса эти поля(private) а доступ кним был только через акксессоры(они public) обращаться к видимому в классе обьекту через свойство ненужно..
+ на сет иногда ставится некоторая функциональность.. что на это при простом изменение значения тоже завязываться надо?  

Это сообщение отредактировал(а) _Dream - 27.4.2007, 11:56

Если не set метод ставиться некоторая функциональность, то это означает, что все данные, которые сохраняются во внутреннем поле, для которого создан этот set, должны быть некоторым образом обработаны (например, должны соответствовать некоторому формату). Полагать, что в процессе написания класса все данные, которые вы устанавливаете прямо в атрибут, посредством наличия доступа к private, соответствуют правилам, формализованным в set по меньшей мере безосновательно.

При наличии метода доступа (будь то get или set) в любом случае нужно использовать именно его. Иначе это ведет к ситуации, когда появление новых условий ведет к необходимости анализировать все внутренние обращения к атрибуту.

Если у меня появляется новое ограничение логики, например, что длина строки должна быть больше нуля, то я только изменяю set метод:

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


В первом случае я обнаружу ошибку сразу в процессе тестирования, а во втором она может проявиться значительно позже.

Кстати зачастую в классах используются приватные методы доступа (в частности, set), которые обеспечивают доступ к полям внутри самого класса, централизируя управление доступом.

Это сообщение отредактировал(а) adLucem - 27.4.2007, 13:35

то есть вы предлагаете на все поля классов заводить аксессоры и работать через них??

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

Использование внутренних функций доступа обуславливается следующими причинами:
1. Несмотря на то, что атрибут модифицируется только внутри класса, модификация требует некоторых дополнительных действий.
2. Был произведен рефакторинг с инкапсуляцией доступа к атрибуту.

 я может не так вас понял но где вы видите здесь дополнительные действия...
с другой стороны... где гарантия что они там не появятся завтра? потому  я и спрашиваю.. тогда получается что всегда доступ надо получать через аксессоры

Доступ к атрибутам, осуществляется через функции доступа всегда, когда такие функции имеются в наличии.

короче если есть функционал на сет то через поля а нет так и не надо..
я так делаю 

Тут, вопрос не в том, есть ли этот функционал, а в том, что если он появится, то ты получишь гемора на одно место.
Правда, если ты про это вспомнишь в момент изменения сетера, то ничего страшного, а вот если нет?

В общем, adLucem, зачет. Пересмотрел свою позицию   

adLucem, лови заслуженный плюс.

Аксессоры накладывают на значение свойства определённый контракт, соблюдение которого ставиться под угрозу прямым доступом к полю.

Хороший пример — механизм dependency properties в WPF: прямого доступа к данным нет, отдельно валидация, отдельно уведомления об изменении значения.

Всем спасибо! Особенно тебе adLucem!