Как правильно писать программы?

← →
Nucer (2007-10-09 15:51) [0]

Есть сетевое приложение с интерфейсом. Оно постоянно обменивается информацией с сервером и часто изменяет состояние элементов окна. Когда начал писать программу - старался как можно правильнее и удобнее разбить программу на логические модули.
Основные модули:
uMain - функции обработки событий формы (нажатие кнопок и прочее)
uParse - экспортирует функцию ViewPacket, в которой и происходит разбор пакетов от сервера. Функция вызывается из модуля uMain (при событии OnRead TClientSocket).
uData - функции работы с данными, объявления переменных, массивов и прочее.

В самом начале было довольно удобно работать с такой структурой, но теперь возникает все больше и больше путаницы. В модуле uParse постоянно приходится обращаться к элементам формы как frmMain.XXX, изменять состояние этих элементов. В модуле uMain приходится формировать пакеты и отправлять их на сервер (используя функции из uParse). В итоге во многих местах код практически дублируется. Пытаюсь выносить общие места в процедуры - но не всегда получается (а иногда даже вносит еще большую путаницу).
Как пример: допустим какой-то элемент формы должен отображать значение определенной переменной. Эта переменная может изменяться во многих местах программы (во всех модулях). Получается во все эти места приходиться вставлять код frmMain.Label.Caption:=XXX, но правильно ли это? Другой вариант - ставить таймер, который с определенным интервалом будет изменять состояние формы в зависимости от значений переменных.

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

← →
Игорь Шевченко © (2007-10-09 15:52) [1]

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

Тоже неплохо

← →
Eraser © (2007-10-09 15:56) [2]

> Nucer (09.10.07 15:51)

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

← →
Ins © (2007-10-09 15:59) [3]

> Как пример...

1. Завести класс, у класса - свойство (вместо переменной).
2. Для свойства сделать Set-метод
3. В этом Set-методе вызывать обработчик события, типа OnParamChanged.
4. Написать этот обработчик и в нем производить необходимые изменение над компонентами формы.

Вообще кошмар, модульности у вас считайте никакой...

← →
clickmaker © (2007-10-09 16:05) [4]

> Эта переменная может изменяться во многих местах программы
> (во всех модулях). Получается во все эти места приходиться
> вставлять код frmMain.Label.Caption:=XXX

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

Component1.OnChange := Comp1Change;
...
ComponentN.OnChange := Comp1Change;

procedure TForm1.Comp1Change(Sender: TObject);
begin
Label.Caption:=XXX
end;

← →
Сергей М. © (2007-10-09 16:08) [5]

procedure SetSomeVariable(Value: SomeType);
begin
if SomeVariable <> Value then
begin
SomeVariable := Value;
PostMessage(SomeForm.Handle, WM_SOMEVARIABLE_CHANGED, ...);
end;
end;

Форма SomeForm, окну которой адресовано сообщение WM_SOMEVARIABLE_CHANGED, получив оное тут же визуализирует новое значение переменной SomeVariable.

Такой подход решает проблему с минимальными затратами на переделку проекта в целом и достаточен с т.з. потокобезопасности для однопоточного приложения.

← →
Сергей М. © (2007-10-09 16:11) [6]

А чтобы не пропустить ни одно изменение переменной, можно вместо PostMessage использовать SendMessage

← →
bobby (2007-10-09 18:38) [7]

Сокеты и форму надо изолировать
Сокеты в поток
Форма пользователю
Общие данные (поток- форма) пакуй в свои структуры(в этом месте не надо лениться)
Механизмов обмена между формой и потоком в обе стороны валом
Представь себе, что из потока, ты можешь не только в GUI информацию
кидать, но и писать в БД(например)
Все станет на свои места

← →
KSergey © (2007-10-09 18:45) [8]

> Сергей М. © (09.10.07 16:11) [6]
> А чтобы не пропустить ни одно изменение переменной, можно
> вместо PostMessage использовать SendMessage

Не понял. Можно поразвернутее о причинах пропуска?

> Игорь Шевченко © (09.10.07 15:52) [1]
>
>
> > Другой вариант - ставить таймер, который с определенным
> > интервалом будет изменять состояние формы в зависимости
> > от значений переменных.
>
> Тоже неплохо

Отвратительно.
Можно нарваться на некосистентность группы связанных между собой свойств в определённый момент времени — полная потеря атомарности состояния.

Решение проблемы надо начать с сужения области видимости модулей друг друга. После этого, конечно, выяснится, что программа на самом деле не модульная — это только видимость использования зарезервированного слова Unit в заголовках файлов. :))

>iZEN © (09.10.07 20:27) [9]
>Решение проблемы надо начать с сужения области видимости модулей друг
>друга. После этого, конечно, выяснится, что программа на самом деле не
>модульная — это только видимость использования зарезервированного
>слова Unit в заголовках файлов. :))

Согласен. Особой модульностью здесь не пахнет. Есть одна форма и обслуживающий ее функционал.

> KSergey © (09.10.07 18:45) [8]
> Можно поразвернутее о причинах пропуска?

Пусть процедура SetSomeVariable была вызвана последовательно дважды с различными параметрами, например, 1 и 2.

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

Как правильно писать программы? Найти похожие ветки