Quale modello di progettazione sarebbe meglio per questo caso?

3

Ho una classe, chiamata PolicyProvider, attualmente con la seguente interfaccia (abbreviata):

public interface IPolicyProvider
{
    List<Policy> GetRenewalPolicies(Client client, int financialYear);
}

Lo scopo è abbastanza ovvio: ogni anno l'assicurazione si rinnova per il cliente e riceveranno una serie di nuove politiche.

Il fatto è che le politiche cambiano di anno in anno. Pertanto, una implementazione concreta della classe deve essere cambiata ogni anno (o modificata con un sacco di brutti "se" che valutano l'anno finanziario). Posso vedere che nel tempo questo diventerà orrendo.

In questo caso, quale modello di progettazione è più appropriato?

    
posta Hanshan 09.05.2013 - 08:51
fonte

3 risposte

3

Seguendo il suggerimento di nulliusinverba , sto creando una risposta dal mio commento originale.

Lo vedo come uno scenario per un modello factory, con il core PolicyFactory (o provider) che crea le policy per ogni specifico client.

Potresti quindi avere una classe PolicyFactoryFactory , una fabbrica di fabbriche, cioè (non importa la denominazione scomoda), in grado di creare un PolicyFactory per un particolare anno (sia esso PolicyFactory2012 o PolicyFactory2013 ecc. .).

Ovviamente, questa metafora potrebbe ancora essere in grado di analizzare file esterni e creare policy dai loro contenuti (come suggerito da Florian).

    
risposta data 14.05.2013 - 14:05
fonte
2

Un approccio standard per evitare "if" è usare sottotipizzazione e associazione dinamica. Tutto quello che devi fare è creare politiche di sottotipo per ogni anno finanziario.

    
risposta data 09.05.2013 - 11:12
fonte
1

Dovresti utilizzare il modello di modello di dominio perché "criteri" (specialmente come hai li ha descritti) sono soggetti a frequenti cambiamenti e devi mantenerli sufficientemente isolati in modo da non confondere o interrompere il "normale" percorso di esecuzione.

Reasons to Use the Domain Model

In those cases where the behavior of the business is subject to a lot of change, having a domain model will decrease the total cost of those changes. Having all the behavior of the business that is likely to change encapsulated in a single part of our software decreases the amount of time we need to perform a change because it will all be performed in one place. By isolating that code as much as possible, we decrease the likelihood of changes in other places causing it to break, thus decreasing the time it takes to stabilize the system.

    
risposta data 15.05.2013 - 04:40
fonte

Leggi altre domande sui tag