И ждал вызванного сантехника, который был вызван для ряда работ.
Думая о паттернах вообще, я сообоазил, что вызванный "специалист" - это
аналог класса-интерфейса. Для выполнения работ прибыл мужик - это аналог
объекта класса, реализующего абстрактный интерфейс "специалист".
Открывание двери - это аналог занесения указателя на интерфейс "специалист"
в объект обрабатываемого класса. Далее, производится акция "визит".
Т.е. прибывшему "специалисту" передаётся this квартиры.
(Для получения доступа к производству работ.)
this приводится к типу указателя "доступ_к_сантехнике".
Для которой и производятся работы.

Надо было писать и поддерживать программу подведения баланса
небольшой торговой точки за смену (неделя).
Для этого на видах/диалогах присутствует значительное колическтво
однострочных эдитов. Но в них надо фильтровать данные, чтобы случайно
не ошибиться с вводом символов. Берём библиотечный объект-эдит,
который пропускает всё. Ура, я умею писать наследников !
1. Делаем наследника, корорый позволяет вводить фио.
те фильтруем большие/маленькие русские буквы.
2. делаем наследника для ассортимента - кроме букв могут быть, цифры
и спец. символы.
Например, "Сок яблочный, 0.25 л"
Пирожное Картошка 100 гр.
итп итд
3. делаем наследника для цены - цифры, точка
4. приход/расход - цифры, точки, знаки
5. дата - целые цифры
6. что-то ещё было - не помню..

В это время лудил ещё прогу - понадобились 16-ричные цифры

Всё работает, всё в порядке, но не удобно - сам путаюсь кто какой объект.

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

В эдите вместо вызова виртуальной функции фильтра, вызовем
по указателю интерфейса "SomeRoutine" какую то его реализацию.
(Если указатель действителен).
Собственно, это всё.
В качестве реализации указанного интерфейса могут быть
использованы объекты, реализующие различные фильтры.
В том числе и те, которые мне пока не нужны.

При этом, поскольку объект-фильтр не является автоматом состояний,
один объект-фильтр может обслуживать любое количество эдитов.

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

1. в DbgView - чтобы сразу посмотреть в окошке
2. на UDP-сервер - у меня есть достаточно различных
программ - клиентов, хочется знать об их проблемах удалённо.
К тому же они на разных версиях Виндус, поэтому
вопрос актуален.
3. в файл конечно
4. В некоторых случаях в консоль (если приложение консольное)
5. В какое-то окно приложения
6. Никуда, если не нужно
7. Если ещё что-то потребуется, чтобы прямо сразу.

В программе я пишу что-то вроде:

AppTypeMessageF(_T("SomeProject %s %d случилось плохое, а именно ..."),_T(__FILE__),__LINE__,...);

Особенно интересно, если это используется в библиотечной
процедуре. Вывод будет определять конкретное приложение.

Это паттерн "наблюдатель", я почти сразу догадался.

1. Определим интерфейс вроде I_TypeMessage.
2. Если собираемся вообще выводить, проинициализируем указатель
на этот интерфейс реализацией. Это почти всё.

И как быть с желанием выводить сразу нескольким получателям ?
Это просто.
Делаем объект - контейнер адресов объектов-реализаций.
Созданные объекты-реализации вывода (например DbgView, Udp, Сonsol)
"подписываются на события" передавая контейнеру свой адрес.
Приведённый к типу интерфейса (ясное дело).
Как только произойдёт "событие" - попытка вывода " AppTypeMessageF(...); "
будет вызван метод контейнера, который сам выводить не должен.
Но зато он перечислит все занесённые адреса и переправит
выводимое каждому "подписавшемуся" объекту.

Это очень удобно работает.
Можно даже в процессе работы приложения менять получателей
информации.

Мне надо было подключить абонента по RS485 к компу.
я взял объект - COM-порт, унаcледовался от него и сделал объект-абонент.
и всё заработало. Роутины объекта COM-порта умеют принимать/передавать вообще,
а "абонент" формирует, что именно надо передавать и разбирается
в принятом.

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

Значит, каждому "абоненту" надо занести адрес объекта COM-порта.
(Или адрес интерфейса "I_ComPort", реализацией которого пользуемся.
В данном случае это не важно.)

Это паттерн "мост".
И без "моста" решить проблему вообще невозможно.

Теорема

Инспекторы ГИБДД святее Понтия Пилата.

Доказательство

Понтий Пилат, римский прокуратор Иудеи, вынес смертный приговор Иисусу Христу. При этом в деле отсутствовал даже намёк на:

• превышение скорости
• проезд на красный свет
• движение по встречной полосе
• непропуск пешехода
• езду без страховки

Таким образом, Пилат казнил человека, который не нарушал ПДД. Более того — он ещё и руки помыл, демонстрируя полное отсутствие ответственности.

Инспектор ГИБДД, напротив:

• никогда не прибивает человека к кресту
• максимум выписывает штраф или лишает прав
• делает это (по крайней мере, по закону) только при наличии состава нарушения ПДД

Следствие

Инспектор ГИБДД не казнит невиновных в дорожном смысле, не умывает рук и ограничивается административными мерами. Пилат же распял человека, который даже не превысил скорость.

Вывод

По сравнению с Понтием Пилатом инспекторы ГИБДД — настоящие святые. Они хотя бы ждут, пока вы нарушите правила, прежде чем начинать «крестный путь» в виде протокола.