Программер, которому я не особо доверяю, сделал замечание, что согласно ООП надо вместо паблик переменных использовать паблик свойство. Верно ли это, если да, то почему?
И второе, я назвала паблик переменную _DefKeyField, он сказал, чтоб я убрала первый знак из названия, то есть "_". Существенно ли это? Если да, то почему?
Извините, может я не по теме данного форума, но это ж вопрос для начинающих.
Спасибо заранее!
Надя

> [0] Abcdef123   (10.11.08 03:32)


> что согласно ООП надо вместо паблик переменных использовать
> паблик свойство

да, только с поправочкой - в ООП, принятом в Делфи.

> И второе, я назвала паблик переменную _DefKeyField, он сказал,
> чтоб я убрала первый знак из названия, то есть "_". Существенно
> ли это?

правильно сказал. в Делфи это противоречит основным стандартам.
советую http://www.delphikingdom.com/asp/viewitem.asp?catalogid=802

> Верно ли это? [D6, XP]
>
> Abcdef123   (10.11.08 03:32)
>
> Программер, которому я не особо доверяю, сделал замечание,
>  что согласно ООП надо вместо паблик переменных использовать
> паблик свойство. Верно ли это, если да, то почему?
> И второе, я назвала паблик переменную _DefKeyField, он сказал,
>  чтоб я убрала первый знак из названия, то есть "_". Существенно
> ли это? Если да, то почему?
>

И то и другое  не верно в общем случае.

Скажем так, на исполнение программы в общем случае это не повлияет, но программер, которому ты "не особо доверяешь" прав. :)

Попроси аргументировать и начни доверять :)

да чувак просто жениться на ней не хочет.

> > что согласно ООП надо вместо паблик переменных использовать
>
> > паблик свойство
>
> да, только с поправочкой - в ООП, принятом в Делфи.

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

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

Поросенок Винни-Пух ©   (10.11.08 11:23) [7]
Это уже не имеет отношения к ООП, ООП начинается там, где кончается ссылка.
Но правила хранения общии, не выше необходимой видимости.

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

Можно выкрутиться. Без глобальных переменных можно обойтись. Вон в Java их вообще нет и ничего.

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

Это неверно.

Вон в Java их вообще нет и ничего.

Это в сидиезе их по настоящему нет и любая запятая это член класса.
А ява - это так. Полумеры.

> Поросенок Винни-Пух ©   (10.11.08 11:31) [11]
> Это в сидиезе их по настоящему нет и любая запятая это член класса.

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

во во.
Сначала говорят, будем святы и чисты и не будет у нас переменных. Изобретают чисто ооп язык.
а потом все заканчивается этим

public static class Globals {
...
}

:)

> вместо паблик переменных использовать паблик свойство. Верно
> ли это, если да, то почему?

Св-во можно менять с помощью метода +

> Ну если свойств нет, то надо работать через функции и процедуры
> - вот это будет уже по канонам. Не должно быть прямого доступа
> до полей класса.

Ну мало ли чего туда по ошибке запишут? А св-во автоматически вызовет метод(если он описан) для своего изменения, в котором можно проверять корректность значения.

... и при всем при этом почему-то decimal separator - это не поле с методом по записи.

А св-во автоматически вызовет метод(если он описан) для своего изменения, в котором можно проверять корректность значения.

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

> Поросенок Винни-Пух ©   (10.11.08 12:51) [16]

Не обязательно "я". Это может быть коллега, который не в курсе тонкостей. Так что защита не помешает.

> [16] Поросенок Винни-Пух ©   (10.11.08 12:51)
> И я создаю класс с полем и методом по записи, для того,
> что бы опять же я не испортил бы глобальное неправильным
> значением, путем проверки значения в методе, который написал
> я.

Ну да. Проверка в одном месте, присваивание во многих.

> Vlad Oshin  (10.11.2008 12:38:14)  [14]

Свойства для того и придумали, что бы скрыть методы доступа и кой что еще. Что бы это выглядело как переменная. В тех языках, где нет свойств это делается явно через функции, а само поле все равно скрыто в private.

> согласно ООП надо вместо паблик переменных использовать
> паблик свойство

если класс или структура используется только как контейнер для данных (н-р, в параметрах методов), то нафик там свойства?

> Eraser ©   (10.11.08 03:47) [1]
>
> > [0] Abcdef123   (10.11.08 03:32)
>
>
> > что согласно ООП надо вместо паблик переменных использовать
> > паблик свойство
>
> да, только с поправочкой - в ООП, принятом в Делфи.

В Шарпе тоже.

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

+1. В частности, при отсутствии свойств использование get'теров и set'теров весьма спорно.

Но "_" безусловно надо избегать в нормальных функциях, в методах - тем более, там просто нельзя.

> Поросенок Винни-Пух ©   (10.11.08 11:23) [7]

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

В поле класса TApplication.

--
Regards, LVT.

Abcdef123   (10.11.08 03:32)
Чем же этот программер незаслужил доверия? )))
В том что он посоветовал подвоха нет.

Ну уже ответили в [5]

В поле класса TApplication.

А чем заменить глобальную переменную TAplication?
Каким полем и в каком классе?

> Поросенок Винни-Пух  (11.11.2008 15:54:27)  [27]

Заменить функцией (конструктором), при том если по реализации системы, или встроеный в систему, или скрытой локальной переменной.

> Поросенок Винни-Пух ©   (11.11.08 15:54) [27]

> А чем заменить глобальную переменную TAplication?

Она уже есть, и пока заменить ее нечем.
Борланды пошли на компромисс, целясь в повторное использование
кода в GUI, консолях и dll. Короче говоря, отошли от ООП, а так бы было
что-то вроде:


Доступ к Application организовали б через прокси-объект, создаваемый
по мере надобности программистом, и снабженным нужными свойствами, например, тем же DecimalSeparator.

--
Regards, LVT.

> Leonid Troyanovsky  (11.11.2008 16:14:29)  [29]

Вроде и сейчас так же можно, вот только другие модули будут обращаться к другому экземпляру TApplication.
Борланд мог сделать функцию, которая бы возвращала ссылку на экземпляр, как бы не было сделано обращение к Application.

Какои смысл прописывать метод доступа, если он будет вида fField:=Value;
Либо это вообще свойство для чтения?

> Anatoly Podgoretsky ©   (11.11.08 16:49) [30]

> Вроде и сейчас так же можно

Можно обращаться к самой переменной Application,
а надо б было к промежуточному объекту, который бы
и управлял доступом к объекту {F}Application.
Ну, например, чтоб он не давал сделать Applcation.Free,
хотя, в данном случае, ничего предосудительного в оном нет.

> Борланд мог сделать функцию, которая бы возвращала ссылку
> на экземпляр, как бы не было сделано обращение к Application.

Вот здесь их подвело, IMHO, стремление к общности:
вдруг некто захочет пользовать Application из длл в чуждом процессе.

А, все равно, идея пригодилась лишь в package, т.е. при отказе
обслуживать чужих.

--
Regards, LVT.

насколько я знаю, никто пока в массовых объемах не убивал ни TApplication, ни DecimalSeparator ни другие глобальные переменные.
Так что все это пустое. Эстецво и сектанство.

> DesWind   (11.11.08 17:19) [31]

> Либо это вообще свойство для чтения?

В дельфи свойство для чтения легко становится таковым для записи,
если оно не релизовано геттером.

--
Regards, LVT.

> Поросенок Винни-Пух ©   (11.11.08 18:02) [33]

> Так что все это пустое. Эстецво и сектанство.

М.б.

Хочу лишь обратить внимание на разрыв между
двумя дельфийскими моделями: модульной и ООП.
А граница проходит по глобальным переменным и
секциям их инициализации/финализации.

Например, невозможность управлять инициализацией собс-ного
приложения раздражало, IMHO, не одно поколение программистов.

--
Regards, LVT.

> Поросенок Винни-Пух ©   (11.11.08 18:02) [33]

> насколько я знаю, никто пока в массовых объемах не убивал
> ни TApplication, ни DecimalSeparator

Во-первых, где границы твоих знаний?
Во-вторых, использование глобальных переменных вопреки
требованиям ООП (а дельфи позиционируется как ООП ЯВУ)
должны чем-то быть оправданы?

А где оные бонусы?
В консольных приложениях, где никто и не предполагает
использовать Application?
Или в длл (свят-свят)?

--
Regards, LVT.

> Какои смысл прописывать метод доступа, если он будет вида
> fField:=Value;

Сегодня так, а завтра SetfField(Value);

Основная идея скрыть прямой доступ до переменной, абстрагироваться от хранения, типа, прочего, но чтобы выглядело как переменная. Всю необходимую работу выполнит компилятор, где подменит на прямое присвоение, где будет вызван метод с контролем, а где то даже и поля не будет, а будет вызвана функция, которая например обратится к ФСБ с докладом, мол тут Вася Пупкин делает что-то.

Свойство это великая вещь.

> Leonid Troyanovsky  (11.11.2008 17:57:32)  [32]

Applcation.Free, равносилен закрытию приложения, почему бы и нет?
Мы же можем работать разными методами с динамическими массивами.

> Leonid Troyanovsky  (11.11.2008 18:10:35)  [35]

Зато оно сейчас не дает покоя остальным программистам.

А для чего скрывать public-переменные? Из принципа?
Вот я предоставляю (как было выше сказано) поле как контейнер для хранения данных, даю программисту возможность обрабатывать его как методами моего класса, так и доступом напрямую, например к некоторой структуре. Причём надо учитывать, что никаких проверок не нужно.
И что же в этом плохого? Зачем делать дополнительные вызовы, нагружать класс ненужными свойствами и методами?

То, что однажды (через пару десятков лет) вдруг кто-то решит использовать мой класс в качестве родителя?
Да ради бога.

>
> правильно сказал. в Делфи это противоречит основным стандартам.
>
> советую http://www.delphikingdom.com/asp/viewitem.asp?catalogid=802


Э-э... догматизм в действии?

В статье очень много полезного, но вот эта фраза - Данные всегда должны располагаться только в приватной секции

несёт элемент бреда.

> Тын-Дын  (11.11.2008 22:41:40)  [40]

От себя самого скрывать.
Какую дополнительную нагрузку ты видишь, для свойства read F write F
И тебе что строчек жалко в файле, так не 80 годы, когда носитель была дискета 180/360 кб, а теперь уже террабайтные винчестеры норма.
Зато ради этой фиктивной экономии идешь на снижения надежности.

> Тын-Дын  (11.11.2008 22:44:41)  [41]

Для кого то бред, а для кого то основа надежных программ.

> [29] Leonid Troyanovsky ©   (11.11.08 16:14)

по-сути Application - это синглтон. всякие прокси-объекты только путать будут. если уж делать строго синглтоном, то как в примере из википедии http://ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)

Во-первых, где границы твоих знаний?

unit Unit1;

interface

uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 Dialogs;

type
 TForm1 = class(TForm)
 private
   { Private declarations }
 public
   { Public declarations }
 end;

var
 Form1: TForm1;
implementation

{$R *.dfm}

end.

> Поросенок Винни-Пух ©   (12.11.08 13:36) [45]

> var
>  Form1: TForm1;

Тяжелое наследие попыток борландов
переманить пользователей VB.

var Form1: TForm1 - безусловно правильное решение. Проблем не вызывает, а удобства много.

Приходит на ум 1 плюс создания property для полей - что сразу можно писать FValue, где-то Value и не надо будет потом заменять Value на FValue, если там надо будет добавить set'тер или get'тер какую-то работу со значением.

В статье есть несколько ерундов:
ИМХО, уродливо оформляется if-then-else и case, слишком много разделительных
(после каждой функции) и одна явная глупость - совет далать так:

(вместо того чтобы явно написать = nil без комментария, раз уж нужно показать, что инициализируется нулем)

> GrayFace ©   (18.11.08 13:04) [47]
> var Form1: TForm1 - безусловно правильное решение. Проблем
> не вызывает, а удобства много.

Это, да. По вопросам в "Начинающим" видно, сколько удобств...