La risposta, come spesso accade, è "dipende". Devi bilanciare i vantaggi reciproci in base alle tue esigenze.

Proprietà

• potenzialmente meno spazio di archiviazione richiesto. In teoria hai solo bisogno di un po ', ma in termini pratici probabilmente sarà più di quello.
• semplice da implementare e comprendere

List

• potenzialmente meno spazio di archiviazione richiesto. Se solo una piccola parte di persone si trova in questo set, hai bisogno di un po 'di dati per memorizzare l'elenco VIP.
• Se hai molte proprietà booleane da gestire che sono spesso raramente vere, puoi estendere questo approccio per coprire più oggetti di questo tipo. Se continui a doverli aggiungere, puoi farlo senza cambiare person ripetutamente.
• Non dovrai preoccuparti di qualcuno che ha il record di una persona aperto e che gestisce le strategie di blocco dei record durante l'aggiornamento dello stato VIP.

Ho detto che lo spazio potrebbe essere salvato da entrambi gli approcci. Dipende dalla frazione dei tuoi record person VIP.

"seldom used attributes should not be a property"

Questo suggerisce che il tuo collega potrebbe litigare sull'uso dello spazio. Sto indovinando (anche se con pochissime informazioni) che qualsiasi risparmio sarà piccolo o trascurabile. Potresti voler fare qualche analisi e determinare il reale risparmio di spazio. O scoprirai che sono significativi o che non lo sono e quindi puoi inquadrare la discussione sui fatti.

Un'altra cosa da considerare è che se il tuo collaboratore ha più esperienza di te nel contesto in cui stai costruendo questo sistema, potrebbero sapere che il blocco è un problema o un altro motivo per cui è preferibile mantenerlo separatamente. Dovresti chiedere chiarimenti sul ragionamento.

Ho più esperienza con i database di documenti ma molti degli stessi principi si applicano qui. Non si desidera memorizzare List<Person> quando si stanno già memorizzando i dati in un'altra posizione. Nel migliore dei casi, memorizzerai una lista di Referenze Personali.

In entrambi i casi ci sono dei compromessi. L'elenco può essere generato in qualsiasi momento se le informazioni sono state memorizzate come attributo. Ma devo chiedermi se è così dogmatico riguardo agli attributi che non sono semplici valori booleani? Cosa faresti se lo stato della persona fosse memorizzato con una enumerazione di rango?

public enum Rank {
    VIP,
    Preferred,
    Normal,
    Economy
}

In questo caso dovresti avere una lista per valore enum o memorizzarla come dizionario tra il riferimento della persona e il rango assegnato. In entrambi i casi, aggiunge un livello di complessità che ha sempre meno senso.

Puoi sempre facilmente interrogare l'oggetto o il database del documento per ottenere tutto Person s con un attributo di person.isVIP == true o person.rank = Rank.VIP . Se l'elenco viene utilizzato spesso, puoi memorizzarlo nella cache per l'ottimizzazione delle prestazioni.

Detto questo, il tuo argomento è uno di prevedibilità e complessità . Come compagni di squadra, devi determinare quale approccio avrà la massima prevedibilità e la complessità minima generale . Ciò significa che devi prendere in considerazione il modo in cui le informazioni vengono utilizzate nell'elaborazione downstream quando prendi la decisione.