Форум: "Прочее";
Текущий архив: 2006.06.11;
Скачать: [xml.tar.bz2];
ВнизВ чем разница между описаниями свойства и просто переменной в ... Найти похожие ветки
← →
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-полями.
Что?
← →
Lamer@fools.ua © (2006-05-16 15:04) [16]>>TUser © (15.05.06 20:18) [4]
>Имхо, нет тут разницы.
Свойство нельзя по ссылке передавать.
← →
DiamondShark © (2006-05-16 16:08) [17]
> До Delphi 7 всё не VCL пестрело public-полями.
А что произошло в дельфи 7?
Паблик поля отменили?
← →
tesseract © (2006-05-16 16:10) [18]
> А что произошло в дельфи 7?Паблик поля отменили?
нет поля их заменили свойствами /методами :-)
← →
Algol (2006-05-16 17:24) [19]
> Я сознатально в примере поместил PictureDir в implementation
> дабы показать, что именно меня интересует. Ведь в этом случае
> будь PictureDir var"ом или свойством получается один функцианал
> - переменная доступная внутри frm_Main.
> Я правильно рассуждаю?
Рекомендуется объявлять методы, свойства и поля нужно в минимально допустимой области видимости.
← →
Игорь Шевченко © (2006-05-16 17:26) [20]Algol (16.05.06 17:24) [19]
> Рекомендуется объявлять методы, свойства и поля нужно в
> минимально допустимой области видимости
Переведи.
← →
Algol (2006-05-16 17:45) [21]
> Переведи.
Что непонятного? Область видимости свойства/метода должна быть минимальна. Т.е. сначала объявляем как private, если оказывается, что это не катит, объявляем protected и т.д. вплоть до глобальных переменных...
← →
API © (2006-05-16 21:50) [22]причём здесь инкапсуляция??????
Предлагаете и мне, для пущей убедительности, в ответах ставить соответствующее количество восклицательных знаков?
Отделение полей свойствами носит рекомендательный характер по ООП.
До Delphi 7 всё не VCL пестрело public-полями.
Расшифруйте, плиз...
нет поля их заменили свойствами /методами
А тут запятые поставили бы, а?
"Казнить нельзя помиловать"...
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2006.06.11;
Скачать: [xml.tar.bz2];
Память: 0.52 MB
Время: 0.011 c