А вот еще один холиварчик по поводу стиля кодинга

← →
@!!ex © (2010-06-15 10:15) [40]

Второе - пример плохого кода.
То, что видимость кнопки связана с режимом редактирования не значит что эту видимость можно использовать для определения текущего режима.
Логику от интерфейса надо отделять.

← →
Александр Иванов © (2010-06-15 10:15) [41]

Я стараюсь не делать свойсва, при изменении которых "что-то происходит". Т.е. если нужно вызвать действие - для этого служит процедура или функция.
Т.е. я бы сделал read-only свойство и процедуру, которая устанавливает значение.

← →
brother © (2010-06-15 10:18) [42]

> Я стараюсь не делать свойсва, при изменении которых "что-
> то происходит".

зря...

> Т.е. я бы сделал read-only свойство и процедуру, которая
> устанавливает значение.

а процедура вызываемая "автоматом" это не тоже?

← →
Александр Иванов © (2010-06-15 10:31) [43]

> а процедура вызываемая "автоматом" это не тоже?

Нет. По коду сразу видно устанавливается ли значение или происходит набор действий.

> зря...

Содержательно.
Я свои доводы сказал. Если есть другие - приведи.

← →
antonn © (2010-06-15 12:04) [44]

> Читал, читал ветку... Нет здесь никаких программистов. Настоящие
> программисты хранят такие значения в реестре, вындовс для
> того и придумано, чтобы за нашими значениями следить.

Да к тому же нас посетили "Писатели". Речь не о хранении значения вне программы, а об организации изменения этого значения.

← →
Virgo_Style © (2010-06-15 12:09) [45]

> Да к тому же нас посетили "Писатели".

Не устаю удивляться, каким чудом писатели-сатирики и ирония появились до возникновения смайликов.

← →
Суслик__ (2010-06-15 12:13) [46]

На мой взгляд все это не очень важно.

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

Поэтому предположение, что нужно защищаться от того, чтобы никто не поменял Visible у кнопки, на мой взгляд несостоятельно. Необходимость данной защиты находится целиком в области мнительности разработчика. Я бы не стал защищаться. Недобросовестная третья сторона может натворить немало бед и при скрытом от нее EditButton.

← →
Суслик__ (2010-06-15 12:15) [47]

> Александр Иванов © (15.06.10 10:15) [41]

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

← →
Virgo_Style © (2010-06-15 13:16) [48]

> его может изменить кто угодно, причем мы об этом и знать
> не будем

"Результатом автоматизации бардака всегда становится автоматизированный бардак" (c)

← →
Ega23 © (2010-06-15 13:20) [49]

Всегда делал по первому варианту. На крайняк - и геттер писал, но в качестве результата всё равно приват-поле возвращал, а не Control.Visibe

← →
_Юрий © (2010-06-15 19:09) [50]

Второй вариант концептуально неверен.
Мы принимаем решение о состоянии свойства по косвенным признакам.
Ни дай бог что-нибудь изменится в программе - и поехало.
А изменится обязательно.

← →
jack128_ (2010-06-15 23:23) [51]

> Суслик__ (15.06.10 12:13) [46]

дим, а private члены класса используешь?? Если да, то зачем??

← →
Медвежонок Пятачок © (2010-06-15 23:29) [52]

Вариант номер три. Самый православный

type
TMyForm = class(TForm)
...
private
FEditMode: boolean;
public
end;

function DoMyEdit(AReadOnly : boolean) : boolean;
begin
Result := False;
with TMyForm.Create(Application) do
try
FEditMode := AReadOnly;
InitТамЧто-то_где-то;
Result := ShowModal = mrOk;
finally
Free;
end;
end;

1. Снаружи не паримся, об имени класса формы.
2. Снаружи не паримся над свойствами класса.
3. Снаружи просто знаем, что если надо отредактировать некую сущность, то надо просто вызвать некую ordinal функцию и все.

← →
Медвежонок Пятачок © (2010-06-15 23:41) [53]

Здесь же вопрос выбора между прямым чтением из переменной и геттером.

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

Если же форму проектирует один, а другой ее использует, то оба варианта одинаково кривы.

Один разраб заставляет другого помнить имя класса и имя поля/свойства.
Второй навставлял в десяти местах вызовы формы (имеет право)
Первый по порефакторил класс (тоже имееет право) - поменял имена.
Второй меняет свои вызовы во всех десяти местах.

← →
Дмитрий Т (2010-06-16 01:01) [54]

> jack128_ (15.06.10 23:23) [51]
>
>
> > Суслик__ (15.06.10 12:13) [46]
>
> дим, а private члены класса используешь?? Если да, то зачем?
> ?

Плохой вопрос. В таком ключе можно задавать вопросы на любые темы ))

← →
_Юрий © (2010-06-16 19:48) [55]

>
> дим, а private члены класса используешь?? Если да, то зачем?
> ?

Следует отличать "защиту от дурака" от "зашиты от злоумышленника".
От второго невозможно защититься никак :-)

← →
KilkennyCat © (2010-06-16 19:52) [56]

от первого тоже

← →
KilkennyCat © (2010-06-16 19:53) [57]

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

← →
DiamondShark © (2010-06-18 11:31) [58]

> Внимание - предлагается тема для холиварчика: какой стиль
> Вы предпочитаете и почему?

Тот, что с приватным полем.
Почему? Ну, например, вполне возможно представить некий дурной контрол, у которого свойство Visible возвращает не последнее присвоенное значение, а чего-то другое. Например, даже после присваивания true возвращает false пока невидим родительский контейнер.

Да мало ли чего ещё. Свойства -- это, всё-таки, штуки с сайдэффектами.

> DiamondShark (18.06.2010 11:31:58) [58]

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

> Anatoly Podgoretsky © (18.06.10 12:29) [59]
> Свойства - это средства создания черного ящика. Никаких
> побочных эффектов там нет

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

> в отличии от параметров функций

Щито?

Я обычно предпочитаю отдельно вводить метод UpdateUI, которые проставляет Enabled и Visible всем элементам на форме в одном месте. Ну а разница между вариантами I и II для меня не очень принципиальна. Получается примерно так:

type TMyForm = class(TForm) ... private FEditMode: boolean; FUpdateMessageInQueue: Boolean; procedure SetEditMode(const Value: boolean); public property EditMode: boolean read FEditMode write SetEditMode; end; procedure TMyForm.SetEditMode(const Value: boolean); begin if FEditMode <> Value then begin FEditMode := Value; NeedUpateUI(); end end; procedure TMyForm.UpdateUI(); begin EditButton.Visible := EditMode; end;

где procedure TBaseForm.NeedUpdateUI(); begin if FUpdateMessageInQueue then Exit; PostMessage(Handle, MUM_UPDATE_UI, 0, 0); FUpdateMessageInQueue := True; end; procedure TBaseForm.MumUpdateUI(var Message: TMessage); {message MUM_UPDATE_UI } begin UpdateUI(); FUpdateMessageInQueue := False; end; procedure TBaseForm.UpdateUI(); begin end;

← →
jack128_ (2010-06-18 19:17) [64]

> jack128_ (18.06.10 19:17) [64]

Я, может, туплю, ибо давно с этим не сталкивался.
Но по-моему ведь Invalidate просто делает окно невалидным, а перерисуется оно, когда до WM_PAINT в очереди сообщений дело дойдет. Что, в общем, повторяет описанное Мистиком поведение. Нет?

А да, похоже туплю. Если речь не о перерисовке, а о каких-то логических изменениях, то вопросов нет.

А вот еще один холиварчик по поводу стиля кодинга Найти похожие ветки