В чем разница между описаниями свойства и просто переменной в ...

← →
vidiv © (2006-05-15 17:32) [0]

... классе.
Два класса:

TOne = class private FMyProperty:TType; public MyProperty: TType read FMyProperty write FMyProperty; end;

и

TTwo = class public MyProperty:TType; end;

Какая принципиальная разница между этими клссами?

← →
tesseract © (2006-05-15 17:36) [1]

первый вариант правильней с точки зрения ООП.
Хотя имеет смысл только для published свойств.

← →
Игорь Шевченко © (2006-05-15 17:38) [2]

> Какая принципиальная разница между этими клссами?

Ты можешь менять логику присвоения/получения значения свойству/свойства, не затрагивая при этом частей программы, использующих это свойство.

← →
API © (2006-05-15 19:29) [3]

Типа, инкапсуляция...

← →
TUser © (2006-05-15 20:18) [4]

> Ты можешь менять логику присвоения/получения значения свойству/свойства, не затрагивая при этом частей программы, использующих это свойство.

Аналогичные изменения можно ввести и в случае 2. Участок программы, где написано
a := Obj.MyProperty
Obj.MyProperty := b
по-прежнему корректен с точки зрения компилятора (после замены способов досутпа, прописанных в read и write).

Имхо, нет тут разницы.

← →
API © (2006-05-15 21:07) [5]

[4] TUser © (15.05.06 20:18)
Аналогичные изменения можно ввести и в случае 2

Ага. Переделав второй класс в первый. :-)

корректен с точки зрения компилятора<...>
Имхо, нет тут разницы.

А что по этому поводу говорит ООП?

vidiv © (15.05.06 17:32)
Какая принципиальная разница между этими клссами?

Никто не может запретить так писать (как в случае второго класса), и во многих случаях это будет безразлично.
Но, если возводить идеологию ООП в разряд догм, то второй класс нарушает одну из базовых концепций ООП - инкапсуляцию.
То есть, он не инкапсулирует поля данных.
А поля данных - они отображают внутреннее состояние экземпляра класса.
В случае второго класса, кто угодно может изменить внутреннее поле данных экземпляра класса, и экзепляр класса будет совершенно не в курсе этого. То есть, такие ситуации позволительны, но являются частными случаями.
Согласно идее ООП, изменять внутренние поля данных имеет право только сам класс. Раньше, в Turbo Pascal, свойств не было, и приходилось работать исключительно через методы. Однако, использование разноименных методов для манипуляции идеологически единым свойством объекта было неудобным. Свойства Delphi - введены для унификации.

Вот так как-то...

P.S. То есть, кому-то и ООП нафиг надо...

← →
вопрошающий (2006-05-15 23:18) [6]

Очень интересно.
А Вы можете объяснить, что лучше или может быть правильнее использовать.
unit Main; interface uses type Tfrm_Main = class(TForm) private { Private declarations } public { Public declarations } end; var frm_Main: Tfrm_Main; implementation var PictureDir: string;

PictureDir - лучше оставить так, как глобальную переменную или оформить ввиде свойства frm_Main

← →
Джо © (2006-05-15 23:32) [7]

> PictureDir - лучше оставить так, как глобальную переменную
> или оформить ввиде свойства frm_Main

Смотря для чего используется.

← →
вопрошающий (2006-05-15 23:44) [8]

А в каком случае надо, именно надо, оформлять ввиде свойства? В том случае, если вместе в переменной происходят другие действия?

← →
Джо © (2006-05-16 00:04) [9]

> [8] вопрошающий (15.05.06 23:44)
> А в каком случае надо, именно надо, оформлять ввиде свойства?
> В том случае, если вместе в переменной происходят другие
> действия?

Не обязательно. Смотреть нужно на то, какая область видимости подразумевается для PictureDir. То есть: если у каждой формы есть своя PictureDir, то делать ее глобальной для всех не имеет смысла (у вас, кстати, в примере, переменная вовсе не глобальна). И, обратно, если PictureDir — параметр, имеющий смысл для ВСЕЙ программы — то и делать его нужно глобальным (тем или иным образом) для всей программы, а не хранить, неизвестно почему, в классе первой попавшейся формы.
Ничего о предназначении этой переменной в вашем посте сказано не было, поэтому, повторю [7].

← →
API © (2006-05-16 00:19) [10]

А в каком случае надо, именно надо, оформлять ввиде свойства?

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

Если жe PictureDir является глобальным понятием, общим для всего проекта, то и оформлять его следует как глобальную переменную.

(Хотя, если подходить к этому вопросу критически, то, по хорошему, класс приложения каждого проекта (тот, который TApplication) должен быть разработан под нужды данного приложения. То есть, следовало бы в каждом новом проекте порождать класс от TApplication. Тогда PictureDir можно смело отправлять в класс этого приложения.)

(Borland разрабатывала Delphi, исходя из потребностей широкого круга программистов разных уровней. Поэтому они, видимо, и "запрятали" класс TApplication подальше. Я как-то не раздумывал над этим вопросом, правильно ли они поступили, или не совсем, но я доверяю Borland. И идея запрятать TApplication подальше, не акцентируя особо на нем внимание рядовых разработчиков - скорее всего, лучшее решение. (Но, на практике, все же, порой приходится наследовать от класса TApplication.))

Вон, в SmallTalk, простые типы данных (целые, вещественные чила и пр.) - и те - классы. То есть, все зависит от степени абстрагирования.

Оптимальное решение, как обычно - где-то посредине.

(Как-то сумбурно получилось, но вопрос на самом деле очень глобальный, чтобы излагать все "за" и "простив" на форуме.)

В том случае, если вместе в переменной происходят другие действия?

Если Вам необходимо обрабатывать событие изменения переменной, но ни к какому классу ее отнести нельзя (чтобы сделать свойством), то можно воспользоваться вот таким решением:

unit SomeUnit; interface function PictureDir: string; procedure SetPictureDir(APictureDir: string); implementation var _PictureDir: string; function PictureDir: string; begin Result := _PictureDir; end; procedure SetPictureDir(APictureDir: string); begin if (APictureDir <> _PictureDir) then begin <...> _PictureDir := APictureDir; <...> end; end; end.

← →
вопрошающий (2006-05-16 01:12) [11]

API © (16.05.06 00:19) [10]
Спасибо, интересно и понятно. И не лень Вам столько писать =)
Зато мне интересно читать ;)

Джо © (16.05.06 00:04) [9]
Я сознатально в примере поместил PictureDir в implementation дабы показать, что именно меня интересует. Ведь в этом случае будь PictureDir var"ом или свойством получается один функцианал - переменная доступная внутри frm_Main.
Я правильно рассуждаю?

← →
Джо © (2006-05-16 01:16) [12]

> переменная доступная внутри frm_Main

Не только "внутри", отчего же? Она может быть и public.
Если она будет свойством или полем — она будет принадлежать конкретному экземпляру класса формы. А этих экземпляров может быть несколько. Мне ничего неизвестно о задаче. Поэтому, мои соображения пока не выходят за рамки [9] и [10]. Эти два поста, ИМХО, говорят, в большей части об одном и том же :)

← →
Плохиш © (2006-05-16 13:10) [13]

> (Хотя, если подходить к этому вопросу критически, то, по
> хорошему, класс приложения каждого проекта (тот, который
> TApplication) должен быть разработан под нужды данного приложения.
> То есть, следовало бы в каждом новом проекте порождать
> класс от TApplication. Тогда PictureDir можно смело отправлять
> в класс этого приложения.)

TApplication включает в себя глобальную сущность приложения определённого типа, а для всяких мелких расширений имеются понятия MainForm и DataModul.

← →
tesseract © (2006-05-16 14:31) [14]

> Но, если возводить идеологию ООП в разряд догм, то второй
> класс нарушает одну из базовых концепций ООП - инкапсуляцию.
>

причём здесь инкапсуляция??????

Отделение полей свойствами носит рекомендательный характер по ООП.
До Delphi 7 всё не VCL пестрело public-полями.

← →
Gero © (2006-05-16 14:38) [15]

> До Delphi 7 всё не VCL пестрело public-полями.

Что?

> До Delphi 7 всё не VCL пестрело public-полями.

А что произошло в дельфи 7?
Паблик поля отменили?

> А что произошло в дельфи 7?Паблик поля отменили?

нет поля их заменили свойствами /методами :-)

← →
Algol (2006-05-16 17:24) [19]

> Я сознатально в примере поместил PictureDir в implementation
> дабы показать, что именно меня интересует. Ведь в этом случае
> будь PictureDir var"ом или свойством получается один функцианал
> - переменная доступная внутри frm_Main.
> Я правильно рассуждаю?

Рекомендуется объявлять методы, свойства и поля нужно в минимально допустимой области видимости.

Algol (16.05.06 17:24) [19]

> Рекомендуется объявлять методы, свойства и поля нужно в
> минимально допустимой области видимости

Переведи.

← →
Algol (2006-05-16 17:45) [21]

> Переведи.

Что непонятного? Область видимости свойства/метода должна быть минимальна. Т.е. сначала объявляем как private, если оказывается, что это не катит, объявляем protected и т.д. вплоть до глобальных переменных...

причём здесь инкапсуляция??????

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

Отделение полей свойствами носит рекомендательный характер по ООП.
До Delphi 7 всё не VCL пестрело public-полями.

Расшифруйте, плиз...

нет поля их заменили свойствами /методами

А тут запятые поставили бы, а?
"Казнить нельзя помиловать"...

В чем разница между описаниями свойства и просто переменной в ... Найти похожие ветки