工場を活用して拡張可能にするためにクラスを設計する方法は？

Question

私のc ++ SOAアプリには「セッション」という概念があります。サービス間でデータを交換するために使用されます。たとえば、変更をコミットまたはロールバックするセッションBを実行する前に、一部のサービスA操作の合法性をチェックするために使用されます。なんでも。

セッションモードには、通常とwhat-ifの2種類があります。さらに進むと、別のセッション、合法性のセッション、割り当てのセッション、コミットのセッションなどがあります。これは主な問題です。合法セッションは、what-ifまたは本物などです。

それを修正してコードの重複を避ける方法

ISessionFactory インターフェースを作成し、 WhatIfFactory および RealFactory に実装させることができます。次に、 ILegalitySession を作成し、 WhatIfLegalitySession および RealLegalitySession を実装します。その後、私の工場は適切なオブジェクトを返します。

2つの大きな問題があります。新しいモードが来るとどうなりますか？すべてのセッションに新しいファクトリと新しいクラスを実装する必要があります！新しいセッションタイプが来たらどうなりますか？両方の工場を変更する必要があります...

おそらく2つの階層から辞任し、whatIfセッションを「装飾」します。実際のセッション？ 変更をローカライズするにはどうすればよいですか

Answer 1

デコレータを使用してWhatIfを実装してみてください。または、「what if」の特定の部分を戦略の種類に合わせて抽出します。

別のオプションは、Stateパターンの使用です。 「WhatIf」状態および「Real」状態。

Answer 2

装飾パターンはここで意味があると思います。 戦略パターンとそのコンパイル時の従兄弟であるポリシーベースの設計。これ以上の情報がなければ、どちらが最適かを判断するのは困難です。デコレータは、動作を追加するのに最適で、他の2つは既存の動作を変更するのに最適です。