Б>Зависимость должна идти в одну сторону
Б>Главная форма -> Презентер -> Контроллер
Б>В обратную сторону — только сообщения/события

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

А разве передача обратно сообщения\события — это не зависимость?
По сути это — вызов в обратную сторону — обращение к интерфейсу Объекта1 со стороны подчиненного Объекта2.

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

Б>Этот контроллер не делает ничего полезного, только передает сообщение следующему классу.
Б>Думаю, стоит объединить эти два класса в один класс — АсинхроннаяОбработкаКасс

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

E>>Класс БЛ "Операция с кассой" (базовый):
E>> — хранит Результат (в зависимости от операции есть дополнительные реквизиты у результата)
E>>Класс БЛ "Выгрузка в кассу" — наследник "Операция с кассой""
E>> — реализуют конкретную операцию — выгрузка (или загрузка)

Б>Лучше результат операции хранить отдельно от самой операции. Т.е. создать класс для хранения результата.
Б>Метод класса должен возвращать результат операции, а у тебя почему-то наследование от "результата операции".

У меня сделан отдельный класс для результата, просто я не стал это уточнять.
Класс "БЛ Операция с кассой" имеет ссылку на объект "Результат операции".
Наследники класса "Операция..." создают в конструкторе и содержат наследника от класса "Результат...".
От базового "Результата..." наследуются другие "Результаты...", эти наследники содержат более подробную информацию, соответствующую конкретной операции.
Но сам объект конкретного результата хранится в конкретной "Операции".

И мне кажется неудобно возвращать "Результат" через функцию.
Хранить то его все равно где-то надо.
А хранить где-то в другом месте, не связанном с "Операцией", — не логично.

А>Если протоколирование работы касс — важная часть проекта, то надо повысить его из диагностических/отладочных средств.
А>Ввести как компонент бизнес-логики со всеми соответствующими взаимодействиями с DAL.

А>Может быть, что в результате и различные аналитические отчеты будет проще строить.
А>Например, если все записи лога хранить в одной таблице РСУБД, то можно будет удобно строить выборки по одной кассе, нескольким, всем...
А>С несколькими лог-файлами было бы сложнее и реализовывать пришлось бы врукопашную.

Хорошая мысль, спасибо!
Подумаю об этом, надо "переварить".

E>>А модуль "Работа с файловой системой" вообще не должен знать ни о каких специальных классах вышестоящих модулей.
_>???

Вот, выше объяснил:
http://rsdn.org/forum/design/7452562.1

Автор: es3000
Дата: 24.05.19

E>>Как лучше сделать?
_>Закажите ПО на стороне

Как лучше сделать самому?

Q>>Мало ли библиотек, где в callback нет пользовательских параметров.
Pzz>Ну в общем-то мало, да. Потому что совершенно непонятно, как ими пользоваться, если в каллбеке невозможно понять, к чему этот каллбек относится.

callback — это же применяется чисто в функциональном программировании.
Аналог callback-а в ООП — это обработчик события?
Правильно я понимаю?

Pzz>Именно поэтому не надо так делать.

Там два способа перечислено.
Как не надо делать? Какой из них? И почему?

Здравствуйте, es3000, Вы писали:

E>Только в случае обмена с кассой здесь надо сделать журналирование и в системный журнал и в журнал, имеющий отношение к конкретной кассе.

Сделай CompositeJournal(IJournal), который будет писать сразу в два журнала MemoryJournal и SystemJournal.
Некоторые части приложения будут передавать в MyFileSystem журнал CompositeJournal, некоторые SystemJournal, некоторые MemoryJournal

Здравствуйте, es3000, Вы писали:

E>А разве передача обратно сообщения\события — это не зависимость?

С точки зрения легкости поддержки кода — нет, не зависимость.

E>По сути это — вызов в обратную сторону — обращение к интерфейсу Объекта1 со стороны подчиненного Объекта2.

Обращение не к интерфейсу Объекта1, а к интерфейсу обмена сообщениями (см. Observer).
Т.е. не идет прямая работа с Объектом1, вместо него может быть объект10 (абсолютно не совместимый с Объектом1).

Здравствуйте, es3000, Вы писали:

E>Как не надо делать? Какой из них? И почему?

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

Конкретных решений может быть множество в зависимости от постановки задачи.

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

Например, какая-то высокоуровневая функция бизнес-логики может завершится с успехом, несколькими не фатальными ошибками или с фатальной ошибкой (исключением).
Также функция формирует информационный протокол работы (наряду с не фатальными ошибками, регистрирует сообщения).
В случае исключения — все понятно, функция ничего не возвращает, исключение летит выше по стеку вызова.
Как возвращать полезный результат (payload), статус (полный успех или были не фатальные ошибки) и записи протокола?
Можно, к примеру, использовать какой-то tuple как возвращаемое значение функции.

Q>Например, какая-то высокоуровневая функция бизнес-логики может завершится с успехом, несколькими не фатальными ошибками или с фатальной ошибкой (исключением).
Q>Также функция формирует информационный протокол работы (наряду с не фатальными ошибками, регистрирует сообщения).
Q>В случае исключения — все понятно, функция ничего не возвращает, исключение летит выше по стеку вызова.
Q>Как возвращать полезный результат (payload), статус (полный успех или были не фатальные ошибки) и записи протокола?
Q>Можно, к примеру, использовать какой-то tuple как возвращаемое значение функции.

Что такое "tuple"?
Можно кратко объяснить на примере?

Здравствуйте, es3000, Вы писали:

E>Что такое "tuple"?
E>Можно кратко объяснить на примере?

Это такой объект, который хранит несколько значений (возможно разного типа)
К элементам можно обращаться по их номеру.

Например для хранения 2д-координат можно использовать тупл (int,int), например (5, 8) или (10, -1) — первое значение x, второе y
Для хранения информации о человеке (string, string, int), например ("Петров", "МУЖ", 25) — первое значение фамилия, второе пол, третье возраст

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

Здравствуйте, es3000, Вы писали:

E>callback — это же применяется чисто в функциональном программировании.
E>Аналог callback-а в ООП — это обработчик события?
E>Правильно я понимаю?

callback — это когда куда-нибудь передаешь функцию (указатель на функцию, если в терминах C/C++), и ее потом оттуда позовут. Применяется оно много где.

Pzz>>Именно поэтому не надо так делать.

E>Там два способа перечислено.
E>Как не надо делать? Какой из них? И почему?

Не надо превращать логгер в GOD-object

Здравствуйте, es3000, Вы писали:

E>Что такое "tuple"?
E>Можно кратко объяснить на примере?

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

В C++ нет встроенных tuple, но есть какая-то темплейтная эмуляция.