Пытаюсь глубже понять объектную модель DELPHI. Для чего вводиться property? Для того чтобы только упростить запись вызова метода доступа к закрытым данным или есть ещё какие преимущества? 

+
есть возможность сделать с этими данными все что угодно от проверки на валидность до ...

  Концепция ООП не разрешает менять напрямую состояние объекта, а только действуя на него через методы, свойства фактически вызывают методы, при этом сохраняется привычная семантика как с полями данных. На самом деле свойству может и не соответствовать поле объекта. Меня свойство можно фактически не изменить состояние объекта или изменить его совсем не тривиальным образом. Когда читают свойство, аналогично, может не быть поля, в момент запроса данных может производиться вычисления или получение данных из внешнего устройства, например из файла. 
  Свойство скрывает данные от объекта получателя. Свойством можно ограничить доступ к полю данных, сделав его readonly. Или запретить чтение, а разрешить лишь запись, можно организовать потокобезопасное изменение данных. При этом код остается описательным и наглядным. 

Спасибо за ответ! Решил сегодня начать читать Марко Кэнту. На мой взгляд у него всё чётко разложено для понимания внутренних механизмов Delphi.

Вот это чушь полная. Наоборот. Конструкции без использования свойств (явный вызов методов get()/set()) хоть и более громоздки, но не скрывают факт, что в месте их вызова управление переходит к подпрограмме, которая, возможно, обладает side effects. А вот при обращение к свойству это скрывается. К тому же, по тексту программы невозможно определить, к чему мы обращаемся: к свойству или напрямую к полю.*


А в методах это сделать нельзя что-ли?

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

*

Только в Delphi она не реализована. public поля есть.

Это сообщение отредактировал(а) kemiisto - 11.8.2009, 22:26

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

  Почему же скрывается, ты же видишь что это свойство, значит это не просто поле, а поле которое меняется функциями. При правильном проектировании ты не должен углубляться в структуру класса, ты видишь подходящее название, а остальное должен делать объект сам. Для тебя достаточно того что оно работает.
  Функция хороша, когда ты явно хочешь произвести действие, запустить процесс выполнения, начать операцию, например StartTransaction. Свойство работает когда ты хочешь корректно изменить состояние или узнать его при этом тебя мало волнуют какие будут произведены действия, например Width := 500.

Добавлено через 5 минут и 30 секунд
  Проблема в том что функция может и не произвести правильного перевода состояния, потому что она означает действие, а для перевода в новое состояние может потребоваться несколько действий, попросту говоря можно вызвать функции не в той последовательности или не те действия. Что же касается функций предназначенных сугубо для смены состояния, так это просто недоделанные свойства загромождающие интерфейс.

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

нужно заглянуть в интерфейс класса. А если это свойство, то нужно увидеть исходный код неявно вызываемой функции, которая write. Если хочешь убедиться в отсутствии side effects.

  Это уже говорит о непродуманном проектировании. Объект это черный ящик. Если его писал другой человек, то он должен оставлять лишних хвостов в интерфейсе, а оставить лишь то что должен видеть другой человек. Минимально необходимый набор свойств для изменения состояния и минимально необходимый набор методов для управления процессами.

  Приведу аналогию. Анекдот. Приходит мужик в магазин и говорит мне нужна пила, ему показывают бензопилу, он покупает уходит довольный, через неделю возвращается и говорит, вот у вас тут написано что я могу за день 4 куба леса заготовить, а у меня больше куба не выходит. Продавец говорит ну давайте посмотрим, берет пилу, заводит. Клиент выпучив глаза смотрит на продавца   - "Ух ты она еще и жужжит!!!"
  Собственно если бензопилу не заводить, то соглашусь, что ей пилить не так удобно, как ручной пилой.  

Даже если смотреть с этой точки зрения, то зачем добавлять в язык лишнюю возможность непродуманного проектирования? Зачем добавлять ещё одну степень свободы?

Вот известная цитата Кернигана

То, что он говорит про С, не меняет сути дела.

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

Образцов "продуманного" проектирования практически не встречал. 

   Язык должен удовлетворять как новичком так и опытных. Например, в С++ можно писать шибко универсальный и гибкий код при помощи шаблонов всяких, получать доступ к данным итераторами согласовывать все шаблонными адаптерами. Но мой моск этого не осиливает  . Я же не говорю "вот козлы напридумали тут"   . Пишу так как мне понятно, совсем без шаблонов, пусть не универсально, пусть нифига не гибко и местами приходиться копипастить и переделывать, зато пишу как мне понятно. 


  Уже много лет обращаюсь к исходникам VCL и черпаю оттуда великолепные примеры грамотных реализаций. Скажем нужно что-то написать, вспоминаю аналоги, которые присутствуют в VCL, открываю код - вот вам и решение на каждый день.

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

имхо это надо только для работе в группе или для кода который через н-ное кол-во лет надо переделывать ,
в остальных случаях простых комментов хватает с головой

Alexeis, поддерживаю. я за использование возможностей языка (в частности касательно свойств-пропертей). зачем не использовать для удобства предоставляемые возможности? это все равно, например, что купить машину, поставить под окном любоваться, и всем говорить - какая у меня клевая машине, но пешком привычнее и понятнее, а нажатие на педаль газа обладает side effects, ибо хз что там конструктора напридумывали.

Это сообщение отредактировал(а) MetalFan - 12.8.2009, 20:42

А меня никто не поддерживает...  


Машины бывают разные...

данубросьты) тебе вообще не положено счас тут сидеть, а положено  
ну да... на некоторых действительно лучше не ездить)