Проектирование логики работы ПО

[Человек_Борща]

Доброго времени!

Переписываю одну софтину, возникла ситуация:
Есть программная часть, скажем интерфейс IManager - создается всегда и существует от начала времен и до коллапса вселенной.
Есть пользовательская часть, визуальная, скажем IManagerUI - он есть, когда есть окно ManagerWindow.

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

но вот беда снова IManagerUI не в курсе новых данных в IManager (добавили элемент, изменили сущ. элемент, удалили), поступивших НЕ от ManagerWindow. Нужен какой-то сервер уведомлений... куда копать?

Или может надо как-то иначе посмотреть?

[waleri]

Добавить INotify с методами нужных уведомлений.
В IManager добавить Subscribe/Unsubscribe методы, с аргументом INotify который следует уведомлять о событиях.

Класс, который имплементирует IManagerUI имплементирует так же и INotify, подписывается на события, и т.д.

[Utkin]

Следовательно MnagerWindow реализует IManagerUI, которому передается

Почему это следовательно? IManagerUI должен создаваться программной частью IManager при возникновении ManagerWindow. Или вообще он должен существовать как часть IManager. Я бы делал так, но не зная специфики сложно что-то утверждать.

[Человек_Борща]

IManagerUI должен создаваться программной частью IManager при возникновении ManagerWindow.

Почему? Сейчас я пришел к выводу, что ManagerWindow реализует IManagerUI а тот подписывается на события IManager, а затем просто рисует в окне то, что говорят события.

Задача простая - переписать все на интерфейсы, отделить котлеты от мух, т.е. к коде Manager ни в коем случае не лезть в UI.
Было:

function TManager.add(sValue: string): integer; cdecl;
var
  i: integer;
begin
  Result := fLIst.Add(sValue);
  MainForm2000.ListBox12.add(sValue);

Стало:

function TManager.add(sValue: string): integer; cdecl;
var
  i: integer;
begin
  Result := fLIst.Add(sValue);
  log('IManager.add(sValue = "' + sValue + '") = ' + IntToStr(Result));
  for i := 0 to fSubscriptions.Count - 1 do
  begin
    if Assigned(fSubscriptions[i]) then
    begin
      fSubscriptions[i].NewItemNotify(EVENT_DIRECTION_AFTER, EVENT_MANAGER_ADD, Result, fList[Result]);
    end;
  end;
end;

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

[Utkin]

Почему? Сейчас я пришел к выводу, что ManagerWindow реализует IManagerUI а тот подписывается на события IManager, а затем просто рисует в окне то, что говорят события.

Потому что это усложняет процесс. Но это чисто мое мнение, решать Вам.

Задача простая - переписать все на интерфейсы, отделить котлеты от мух, т.е. к коде Manager ни в коем случае не лезть в UI.

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

MainForm2000.ListBox12.add(sValue);

в вызов:

AddListBox(Target: ListBox; sValue: String);

?
Просто сделайте обертку, скрывающие детали реализации. А уже конкретный Target передадите по обстоятельствам. Этот код будет работать например в Лазарусе и под линукс например. А если выделите все эти обертки типа AddListBox в отдельный юнит/модуль, то сможете оперативно менять его под разные платформы (например, под планшеты).

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

Тем более GUI тут не причем и эти базовые действия должны быть предусмотрены еще выше.

[Человек_Борща]

Потому что это усложняет процесс. Но это чисто мое мнение, решать Вам.

Именно этого я и добиваюсь. Механизм подписки поможет в случае когда слушателем будет C++ приложение к примеру и оно будет фиксировать данные у себя. Писать статические методы тут совсем не катит.
Код бажный не оптимизированный, потому что из демо-примера который пишу, чтобы понять как это работает.

Тем более GUI тут не причем и эти базовые действия должны быть предусмотрены еще выше.

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

[pu4koff]

Переписывайте на шарпе с использованием WPF, там уже есть биндинг, который это умеет
На делфях если всё еще VCL там, то подглядеть как они запилили это в TDBEdit и прочих контролах из той же вкладки.
В целом, зависит от задачи, но втихаря что-то там перерисовывать на экране - это не кошерно. Пользователь тыкал в одну строку таблицы, а там уже что-то обновилось и непонятно что выбралось, а нужная строка куда-то ускакала.

[Utkin]

Не вешать же таймер для перечитывания 100500 строк из базы и отрисовки?

Нужно отрисовывать только те строки, которые показываются юзерам, а не 100500. Задача вполне посильная. Если Вы в каждом месте где надо рисоваться будете обрабатывать сообщения, то программа все время только этим и будет заниматься.

[Vapaamies]

Сообщение от Человек_Борща

IManagerUI начинает управлять IManager. Добавили данные через UI - соотв. интерфейс IManagerUI прозрачно добавит данные в IManager и рисует их.

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

Либо, если в данной архитектуре IManager -- интерфейс манипуляций данными, механизм подписки должен быть реализован как-то отдельно. В DB-компонентах Delphi сделано именно так, за подписку отвечает TDataSource, если не ошибаюсь.

[Человек_Борща]

Переписывайте на шарпе с использованием WPF, там уже есть биндинг, который это умеет

Так и LiveBindings на delphi это умеет. Проблема в том что я отказался от Delphi. C# не вариант, ему нужна VM для исполнения.

В целом, зависит от задачи, но втихаря что-то там перерисовывать на экране - это не кошерно. Пользователь тыкал в одну строку таблицы, а там уже что-то обновилось и непонятно что выбралось, а нужная строка куда-то ускакала.

IManager - сервис на ПК. IManagerUI может быть GUI для сервиса, или же вообще расширением хрома.
Я имею ввиду ситуацию, когда есть GUI IManagerUI над IManager, одновременно с этим для IManager по HTTP приходит новый элемент для вставки в список и вот тут нужно как-то сообщить в IManagerUI о том что, что-то добавилось и надо бы это отрисовать если есть куда(эл-т будет в поле зрения).

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