Как спроектировать мои классы так, чтобы они были эффективными и расширяемыми?

Question

В моем приложении c ++ SOA есть концепция "сеанса", которая используется для обмена данными между сервисами. Например, он используется для проверки законности некоторых операций службы A перед выполнением сеанса B, который фиксирует или откатывает изменения. Безотносительно.

У меня есть 2 типа сеансов: нормальный и что-если. Если пойти дальше, у меня есть другой сеанс, сеанс для законности, сеанс для назначения, сеанс для принятия и т. Д. Это главная проблема. Сеанс легальности может быть «что-если» или реальным и т. Д.

Как это исправить и избежать дублирования кода?

Я могу сделать интерфейс ISessionFactory и иметь WhatIfFactory и RealFactory для его реализации. Тогда я мог бы сделать ILegalitySession и заставить WhatIfLegalitySession и RealLegalitySession реализовать его. Тогда мои фабрики будут возвращать соответствующие объекты.

У него 2 основные проблемы. Что делать, если придет новый режим? Мне нужно будет реализовать новую фабрику и новые классы для всех сессий! Что делать, если приходит новый тип сеанса? Я должен поменять обе фабрики ...

Возможно, уйти в отставку из 2-х иерархий и иметь, что, если сессии "украшают" реальную сессию? Как я могу локализовать изменения?

Answer 1

Попробуйте реализовать свой WhatIf с помощью декораторов. Или извлеките некоторые специфические части «что если» в стратегию.

Другой вариант - использование шаблона State. Состояние «WhatIf» и «Реальное».

Answer 2

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