Стиль программирования: Методы vs. Свойства
Эмм а то, что свойство может быть только на чтение, как бы нее?
Кажется опять глупость сказал :D. В общем от ситуации зависит.
Ну как сказать. Стиль как раз от ситуации не зависит. Он или препятствует возникновению ошибок - тогда это хороший стиль, или не препятствует - и тогда он уже не столь хорош.
Думаю, что от ситуации зависит, если нужно подчеркнуть, что происходит действие, то лучше метод.
А если важно само значение, а действия происходящие при чтении/записи должны быть скрыты в рамках логики класса, то свойство.
P.S. У меня тоже было дежа-вю :)
В других случаях стараюсь использовать методы. На этапе разработки иногда пользуюсь свойствами - так быстрее. Перед выпуском заменяю методами, для надежности.
У меня зависит от того на чем пишу. Если C#, использую свойства, т.к. это часть языка, если C++ - обхожусь методами, хотя иногда запись и длинее.
С точки зрения языка - без разницы. Просто если не использовать свойства, то, скорее всего, код не будет вписываться в концепцию взаимодействия, положенную в основу FCL, где почти исключительно через свойства реализуются:
- ассоциации между классами,
- агрегация,
- композиция,
открывая, тем самым, детали реализации взаимосвязей между объектами и их структуры. Вместо зависимости от одного объекта, получаем зависимость от двух и более. Согласно закону (или принципу, не помню уже) Деметра, такая архитектура влечёт за собой сложности определения мест, подверженных изменению при модификации какого-либо компонента решения. Некоторые признанные мэтры программирования утверждают, что подход FCL, ранее являвшийся подходом COM, узаимствованным, в свою очередь, со стандартных библиотек Java, выглядит практичным для решений малой сложности и объёма, но для крупного проекта может стать серьёзной ошибкой в ответе на вопрос о выборе механизма взаимодействия объектов. В классическом, продвигаемом товарищами Баддом, Беком, Рыловым и многими другими деятелями ООП (я называю его "черезжопном") подходе к дизайну ооп-решений, логика работы почти противоположна разумной. Например, если при "FCL-подходе" необходимо оформить заказ на некоторый товар, то выглядеть это будет так: ответственному за заказы предлагают новый заказ, он его рассматривает, проверяет доступность товара по каждому пункту, и если все указанные в заказе товары имеются в необходимом количестве, то проводит его по установленным "свыше" правилам. А при классическом подходе примерно так: заказ заставляет каждый из своих пунктов заставлять резервироваться ообозначенный в этом пункте товар. Заметьте, открытые свойства, при таком подходе, вообще не нужны (по крайней мере в этой части задачи). Я не являюсь сторонником ни того, ни другого стиля построения взаимодействия, больше предпочитая гибридные и комбинированные подходы, поэтому ни "за" своё ни "против" открытых свойств не скажу. Стиль будет хорошим в зависимости от того, насколько хорошо вы умеете в этом стиле работать.