Trattare con ipotesi nei moduli che risultano in un lavoro duplicato

Question

Trattare con ipotesi nei moduli che risultano in un lavoro duplicato

#1 da (2 voti)
#2 da (0 voti)

1

Immagina un gioco che ha bisogno di segnare le parole. Una parola deve essere valutata immediatamente, in una lista di parole o anche in una lista di parole dalla lista dei giocatori.

Ho creato un modulo di punteggio che ha i seguenti metodi pubblici:

score_single_word(word) -> int
score_list_of_words(list) -> int
score_group_of_players(players) -> [int]

Ovviamente questi metodi procedono a cascata, quindi score_group_of_players esegue qualche calcolo e chiama score_list_of_words infine chiama score_single_word .

Sfortunatamente, ogni metodo richiede la pulizia, in modo tale che le parole siano minuscole, prive di spazio bianco e uniche. Altrimenti il loro compito di rispetto fallirebbe. Non ho visto un altro modo, ma ripulendolo più volte, poiché nessuno dei due metodi può essere sicuro che le sue ipotesi siano soddisfatte prima da uno dei metodi più avanzati.

Che cosa posso fare per rimuovere quegli inutili clean up assicurandoti che le ipotesi siano ancora corrette?

design assertions

posta Sven 27.01.2018 - 01:51

fonte

2 risposte

Leggi altre domande sui tag design assertions

Salva i dati non così dinamici in un database e recupera le modifiche in futuro Questa interfaccia di metodo è una buona risposta a questa domanda di intervista?

score 2 · Answer 1

Sospetto che non sia effettivamente necessario esporre tutte queste funzioni. Se, ad es. score_single_word è un metodo privato, si può presumere che sia chiamato con input valido. (Anche se, aggiungendo affermazioni per garantire questo è probabilmente utile.)

Se score_list_of_words non ha bisogno di essere pubblico, allora può anche presupporre che gli venga dato un input valido, sebbene io personalmente lo definirei in modo tale da prendere qualsiasi input e gestire la normalizzazione.

score_group_of_players , per quanto posso dire, non è necessario fare nulla se score_list_of_words prenderà input arbitrari. In alternativa, potresti avere una funzione normalize separata che eseguirà tutte le operazioni di "pulizia".

Se hai bisogno di esporre score_single_word , lo definirei in termini di score_list_of_words che normalizza il suo input. (Sarei comunque in grado di calcolare il codice "ripulisci" in una funzione normalize , anche se è privato e utilizzato solo da score_list_of_words per rendere score_list_of_words più pulito.) score_list_of_words può quindi chiamare un privato internal_score_single_word che non convalida l'input.

In ogni caso, in generale, fai ciò che fai normalmente: estrai la comunanza, trova una buona posizione per le barriere di astrazione. Ad esempio, un approccio alternativo è chiedere "perché l'input 'disordinato' è stato dato anche a una di queste funzioni?" Questo potrebbe portare a creare un tipo per "parole" e / o "elenchi di parole" che garantisce gli invarianti e presenta solo l'output "ripulito". Spesso questo è un approccio migliore, ma potrebbe essere eccessivo in questo caso.

score 0 · Answer 2

Hai bisogno di mostrare le parole all'utente? In caso contrario, pulirlo in input. Allo stesso modo con le liste - non inserire parole che la lista contiene già, o se stai aggiungendo più parole contemporaneamente, esegui immediatamente un passaggio di rimozione duplicato e poi passa solo in rassegna gli elenchi ripuliti.

Se hai bisogno di mantenere la stringa originale per mostrarla all'utente in un secondo momento, invece di passare le stringhe non elaborate, passa attorno a un oggetto (o struct , o qualunque sia la lingua supportata), che contiene la stringa originale e quello ripulito. Puoi ancora mantenere gli elenchi puliti prima di inviarli sempre con questo scenario, di nuovo, non inserendo duplicati o eseguendo un passaggio pulito subito dopo aver fatto qualche aggiunta.