Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 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
2-1148704224
Ezorcist
2006-05-27 08:30
2006.06.11
Значение переменной "по-умолчанию"))))


15-1147545994
dimodim
2006-05-13 22:46
2006.06.11
Драйвер RAM disk a


2-1148583505
Benjamin
2006-05-25 22:58
2006.06.11
pleace help ME!!!!


15-1148126613
wirg
2006-05-20 16:03
2006.06.11
Нужна блок схема


2-1148671048
Std
2006-05-26 23:17
2006.06.11
Время выполнения процедуры





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский