Separazione delle preoccupazioni: di chi è questa preoccupazione?

Question

Separazione delle preoccupazioni: di chi è questa preoccupazione?

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Il mio collega senior reviewer vuole che io faccia quanto segue.

Abbiamo (su iOS, iPhone) una gerarchia di visualizzazioni in uno dei nostri schermi. C'è un semplice rettangolo che rappresenta un biglietto da visita di una persona (visivamente corrisponde allo stile dei biglietti da visita).

Poiché questa scheda viene riutilizzata molte volte in molte schermate, ho scritto una classe personalizzata chiamata PFXBusinessCard che ha quattro etichette, ciascuna etichetta che rappresenta i dati di una persona come Nome, Numero di telefono, account ed e-mail. Queste quattro etichette sono esposte come proprietà di quella classe personalizzata.

Nel mio controller, sto passando i dati per una particolare etichetta in un modo seguente. Ottengo la persona, leggo il valore particolare per una proprietà e imposto questa proprietà in un controller. Cioè, sto impostando il nome, il numero di telefono ecc.

Ma il mio collega dice che dovrei invece gestirlo all'interno della classe PFXBusinessCard . Dovrei creare un metodo populateWithPersonsData nella classe e passarei una persona alla scheda nel mio controller. La carta quindi popolerebbe le sue etichette.

Questo approccio è ok? Perché la carta dovrebbe sapere della persona? L'oggetto UI non dovrebbe sapere nulla sui dati. Dovrebbe?

ios separation-of-concerns

posta Earl Grey 24.04.2013 - 09:19

fonte

3 risposte

1

Che cosa succede se crei la categoria

@interface PFXBusinessCard (PersonData)
- (void)populateWithPersonsData:(PersonData *)personData
@end

quindi la classe View non è a conoscenza della classe Model, ma tutta questa logica è ancora incapsulata e la si mantiene ASCIUTTA. È soggetto a discussione.

risposta data 24.04.2013 - 15:18

fonte

1

La carta dovrebbe conoscere la persona se visualizzare i dati personali è una cosa che farà. Il tuo collega ha ragione IMHO, perché ci deve essere una logica per visualizzare PersonData da qualche parte nell'intero codice base. Se il controller non lo fa, quindi appartiene al consumatore del chiamante per mappare tutte le proprietà di PersonData al controller e questa logica sarà dispersa nella base di codice. Qualsiasi progetto di OOP dovrebbe portare più qualità alla base di codice generale, non a ridurla.

risposta data 24.04.2013 - 16:55

fonte

Leggi altre domande sui tag ios separation-of-concerns

Esistono algoritmi per l'ottimizzazione del polling? genera ID sequenziali unici nell'architettura dei microservizi

score 5 · Accepted Answer

Questo è un problema che può essere discusso per sempre e, alla fine, entrambe le parti potrebbero avere ragione.

Ci sono due scuole di pensiero nell'applicazione del pattern MVC, che è ciò a cui la tua domanda si riduce. Li chiamerei le scuole della stupida Vista e la vista intelligente.

Nella vista stupida, la vista dovrebbe riguardare solo le questioni relative all'interfaccia utente e non dovrebbe contenere alcuna logica (con la possibile eccezione di iterare su una raccolta di valori che deve mostrare). Il controller è responsabile della consegna dei dati in blocchi di dimensioni ridotte alla vista.

Nella vista intelligente, la vista è autorizzata ad avere una quantità limitata di logica al suo interno. In particolare, la logica per convertire oggetti dal modello in valori visualizzabili.

A mio parere, la vista intelligente assomiglia più strettamente alla formulazione del pattern MVC e dovrebbe essere preferita. Mi sembra che il muto View sia nato perché per alcuni era troppo allettante mettere la business logic nella View (che non ci appartiene) e perché sembrava che il Controller stesse perdendo la sua funzione.