Strategia di progettazione software per una funzionalità che dipende da una situazione temporale

Question

Strategia di progettazione software per una funzionalità che dipende da una situazione temporale

#1 da (7 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

4

Prima di tutto scusa i miei errori in inglese; non è la mia lingua madre. In secondo luogo, non sono riuscito a trovare un titolo migliore per riassumere la mia richiesta, quindi lascia che ti spieghi di seguito:

Diciamo che abbiamo un software che fattura alcuni prodotti. Il processo di fatturazione dipende in larga misura dalla legislazione vigente. Ad esempio, la legge attuale potrebbe richiedere che quando si crea una fattura per un cliente, è obbligatorio avere l'indirizzo del cliente pieno. Tuttavia, la legge dovrebbe cambiare, così che dopo il 01-01-2018, quando fatturate un prodotto, dovete riempire le informazioni di altri clienti. Questo cambiamento potrebbe essere valido fino a quando, diciamo, 05-05-2018. Dopo questa data, la legge cambierà di nuovo. Tuttavia, il software deve essere compatibile con le versioni precedenti, il che significa che dopo il 05-05-2018 dovresti essere ancora in grado di creare fatture basate sui requisiti di legge dal 2017 e così via.

Ovviamente, non posso aggiungere una pila di istruzioni if-elseif-else in base alla data corrente perché ciò non rispetterà il "Principio Open-Close". Quale potrebbe essere una corretta progettazione tale che l'applicazione sarà aperta per essere estesa, ma chiusa per le modifiche?

object-oriented design-patterns solid

posta TeoMor 01.02.2018 - 13:46

fonte

4 risposte

Leggi altre domande sui tag object-oriented design-patterns solid

Solo il concetto di funzioni matematiche giustifica il motivo per cui i metodi devono solo restituire un valore Sviluppo per un'ampia varietà di desktop Linux

score 7 · Answer 1

7

Potresti usare qualcosa come il Pattern di strategia per tutti i casi in cui il comportamento può cambiare nel tempo. Avresti un componente che seleziona le strategie in base al calendario e probabilmente ad altri fattori.

risposta data 01.02.2018 - 15:28

fonte

score 1 · Answer 2

Un'altra opzione è usare i file di configurazione per guidare i tuoi rapporti. Ad esempio, potresti avere file di configurazione che specificano quali campi del tuo database sono stampati in quali posizioni sulla fattura. Il file di configurazione che scegli potrebbe essere basato sulla data di stampa della fattura, o sulla data della vendita o su qualsiasi cosa sia appropriata.

Un modo semplice per implementare questo potrebbe essere quello di avere una cartella specifica in cui i file di configurazione vivono e farli nominare entro la data in cui hanno effetto. (O forse la data sarebbe un campo all'interno del file, se funziona meglio.) Quindi, quando si crea la fattura, basta scegliere quella per la data appropriata. Nuove leggi? Basta aggiungere altri file con la data in cui entrano in vigore.

score 0 · Answer 3

La soluzione potrebbe dipendere da quanto cambiano le regole.

Se i diversi approcci possono essere facilmente descritti utilizzando alcuni parametri (include_address: true / false, taxRatePercent: BigDecimal, ecc.), puoi trattarli come parametri di configurazione. In un database (o nel file di configurazione se questo offre sufficiente flessibilità), memorizzare i record contenenti i parametri sopra menzionati e una data di inizio quando una particolare configurazione diventa effettiva. Ogni volta che sai che le regole cambieranno, aggiungi un record con la nuova configurazione e la data di inizio appropriata (che potrebbe essere in futuro). Trovare la configurazione efficace per la data corrente è abbastanza semplice.

Assicurati di utilizzare un'interfaccia provider data / ora piuttosto che utilizzare direttamente l'orologio di sistema poiché ciò ti consentirà di testare facilmente l'algoritmo per una selezione efficace della configurazione.

Se le regole cambiano in modo profondo, richiedendo un nuovo codice per ogni set di regole, è possibile fare riferimento al codice nella configurazione. I gestori delle regole potrebbero essere registrati utilizzando alcuni nomi leggibili dall'uomo e questi nomi potrebbero essere indicati nei record di configurazione con date di inizio. Questo sarebbe effettivamente un modello di strategia, ma in una certa misura configurabile in file di proprietà / database piuttosto che hard-coded.

score 0 · Answer 4

La soluzione a questo enigma è evitare di combinare due concetti indipendenti:

La data della fattura
Il set di regole che governano il contenuto

La maggior parte delle volte il set di regole è determinato dalla data della fattura, ma non sempre: il tuo desiderio di generare a volte una fattura oggi usando le regole dello scorso anno. La soluzione è anche rendere entrambe queste idee esplicite nel tuo modello in qualche modo. Quindi la tua funzione per creare una fattura ha bisogno sia di una data di fatturazione sia di qualcosa che descrive quale set di regole usare, che potresti anche rappresentare come una data. Mentre la maggior parte delle volte la data delle regole e la data della fattura sono le stesse, hai comunque la flessibilità di farle differire quando necessario.