È buona norma avvolgere un insieme correlato di proprietà nella propria struttura / classe?

Scrivere un oggetto utente in Swift, sebbene la mia domanda riguardi qualsiasi linguaggio fortemente tipizzato. Un utente può avere un sacco di collegamenti (FacebookProfile, InstagramProfile, ecc.). Qualche domanda in merito.

È buona norma avvolgere i collegamenti nel proprio oggetto?

    utente strutt {
       var firstName: string
       var lastName: string
       var email: stringa
       collegamenti var: collegamenti
    }

    Struct Links {
       var facebook: stringa
       var instagram: string
       var twitter: stringa 
    }

O dovrebbero essere sciolti? So che tecnicamente entrambi i modi vanno bene, ma mi chiedo se esiste un approccio raccomandato, in generale, soprattutto per la leggibilità.

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}

In uno scenario come questo, i collegamenti dovrebbero essere una raccolta / elenco? Ho pensato che non dovrebbe essere un elenco perché è disponibile un numero fisso di opzioni di collegamento e non un numero crescente. Il mio pensiero è giusto?
È buona norma posizionare i miei metodi di rete all'interno dell'oggetto Utente, come getUsers, getUser, updateUser?

So che potrebbero essere soggettivi, ma sto cercando di capire quale sia la migliore pratica in situazioni simili. Gradirei qualsiasi suggerimento.

— Prabhu
fonte

Risposte:

Ne avrai bisogno

zero di una cosa,
una cosa o
un numero arbitrario della cosa.

Sono scioccato dal fatto che il tuo progetto preveda che il numero di collegamenti necessari sarà sempre tre e che sai come si chiamano per sempre.

Quello che sto predicando si chiama la regola dell'infinito zero one . All'inizio potrebbe non essere ovvio, ma è ciò che mi dice che il tuo design non è tollerante per il futuro.

Mi sentirei diversamente se ci fosse qualcosa di speciale in questi link. Qualcosa di speciale che faccio diversamente quando accedo a un collegamento Facebook che non faccio per un collegamento Twitter. Ciò renderebbe loro cose diverse. Ma questo non è indicato in questo codice.

Ecco perché non sono infastidito dalla stringa di posta elettronica. So che viene utilizzato in modo diverso dai collegamenti.

Quindi, fino a quando non vedo un motivo per utilizzare questi collegamenti in modo diverso, sto dalla parte di una raccolta di collegamenti.

— candied_orange
fonte

FacebookProfile, InstagramProfile, ...Penso che OP abbia già risposto alla domanda. La sua lingua ci sta dicendo che gli utenti potrebbero non avere nessuno o più profili relativi ai social netowrks. Ma il programmatore al suo interno ha trasformato questo elemento in semplici collegamenti. Perché non una collezione di Profiles? Ho concordato con CandiedOrange. Stai pensando troppo al futuro. Potrebbero apparire nuovi social network. Quelli reali potrebbero scomparire. Gli utenti possono andare e venire da una rete all'altra.

— Laiv

Questa è una supposizione. Supponi di voler utilizzare questi profili per i login social. Avendo il profilo del componente, abbiamo da dove cominciare. Dove incapsulare le informazioni relative all'autenticazione e alla sessione corrente con questi profili. Questo potrebbe essere considerato YAGNI o over-engineering, ma non vale la pena pensarci, vedere se queste funzionalità potrebbero essere richieste o se potrebbero fornire valore alla nostra applicazione. In caso contrario, scartali.

— Laiv

@Prabhu dipende dal motivo per cui lo stai limitando. La mia ipotesi è che solo così tanti si adattano alla GUI. Va bene Ma non limitare la struttura dei dati a causa della GUI. Le GUI cambiano per capriccio. Le strutture di dati sono costose da cambiare. Vale davvero la pena farlo bene la prima volta.

— candied_orange,

Questo è il punto. Adotta semplicemente quelle strutture che renderanno possibili futuri cambiamenti meno dolorosi. Ne più ne meno. Noi, Candied e io lo diciamo perché noi (credo) abbiamo affrontato situazioni simili spesso e prevediamo possibili caratteristiche suscettibili di cambiamento o evoluzione. In definitiva, sei il più vicino al progetto e alle sue prospettive future.

— Laiv

@Prabhu: nota che hai posto una domanda sulle buone pratiche , non se si tratta dell'approccio più conciso per il tuo scenario specifico. Di solito sono dalla parte di evitare un eccesso di ingegneria, ma il costo della manutenzione futura (aggiunta / rimozione di collegamenti, aggiornamento delle definizioni delle classi di entità, ...) supera di gran lunga il costo dell'implementazione di una raccolta di collegamenti. Se hai chiamato le colonne link1, link2, link3, la necessità di una collezione sarebbe stato più evidente. Tuttavia, il fatto di aver assegnato alle colonne un nome più significativo non cambia il fatto che si tratta di una raccolta di dati ripetitivi.

— Flater

Sei sul punto di cadere nella trappola "Vedo una possibilità tecnica".

Solo perché vedi un tratto comune tra gli elementi non significa che abbia senso applicare un po 'di aggregazione su di essi. L'aggregazione dovrebbe significare qualcosa. Non a livello tecnico ma nel tuo dominio problematico.

Sono tutti buoni collegamenti, ma nel contesto di una classe utente, significa qualcosa? No. È altrettanto insignificante come sarebbe sottogruppo utilizzando le classi denominate "stringhe" e "numeri".

Il problema con questo tipo di cose è che sfoca il tuo modello. Obbliga il lettore di codice a separare i significati dagli insignificanti, prima di avere una piena comprensione del dominio.

Nessuno parla mai dei link di un utente. Sarebbe diverso se si chiamasse SocialNetworkIds di aggregazione. Poiché ciò significherebbe effettivamente qualcosa, sarebbe una vera proprietà dell'utente piuttosto che una raccolta tecnica arbitraria.

— Martin Maat
fonte

Esattamente quello che il mio dubbio era che mi ha spinto a porre questa domanda. L'unica relazione tra i diversi collegamenti è che potrebbero essere visualizzati insieme nell'interfaccia utente. Quindi, in questo caso, suggeriresti di NON inserirli in un oggetto separato, ma piuttosto di tenerli direttamente sotto l'oggetto Utente?

— Prabhu,

Non penso che sarebbe utile in questo caso. Non hai ancora un problema che giustifica l'aggiunta di un livello di complessità. Se avessi molte più proprietà, ci sarebbe stato un guadagno in uno sforzo di raggruppamento (con nomi apt per i gruppi). È difficile dire ciò che è appropriato senza contesto però. La linea di fondo è che dovrebbe rendere le cose più facili. Comprendere e / o procedere con qualunque sia il prossimo passo nel processo di sviluppo.

— Martin Maat,

Io generalmente come evitare over-engineering, ma mi chiedo: ti avrei detto la stessa cosa se OP aveva chiamato i suoi campi link1, link2, link3? Il design di una struttura di dati è indipendente dal nome dei campi, quindi il mio esempio è funzionalmente equivalente. È una questione di impermeabilità al futuro. YAGNI si applicherebbe generalmente, ma semmai i social media si sono dimostrati sensibili alla popolarità e ai cambiamenti virali. Evitare la riqualificazione di ogni nuovo popolare sito di social media sembra desiderabile. Altrimenti, rischi di cadere nel "cos'è un altro campo?" trappola, che può creare enormi debiti.

— Flater

In generale, penso che sarebbe ragionevole avere i collegamenti in proprio structse è probabile che si applichino operazioni simili a ciascuno di essi, in particolare se si eseguono sempre le stesse operazioni su tutti. Se sono per scopi non correlati nella tua domanda, li renderei separati. Ad esempio, se fossero la home page dell'utente, il sito Web del loro fornitore di assicurazione sanitaria e un collegamento al loro sito di notizie preferito, probabilmente non li raggrupperei perché sembrano non correlati. Ma per 3 siti di social media, sembra che verranno trattati in modo simile in un'app e, come tali, probabilmente dovrebbero essere raggruppati insieme. Vorrei usare un nome più descrittivo di quanto Linksperò. (Che tipo di link? A quale scopo nella tua app?)

Sono d'accordo con il tuo pensiero su # 2. Come accennato in precedenza, se il numero dovesse aumentare o diventare variabile, un elenco o un'altra raccolta sarebbe una buona scelta, ma non per lo scenario che hai descritto.

Non collocare metodi di rete all'interno degli oggetti che contengono i dati recuperati dalla rete. La provenienza dei dati e come ottenerli sono generalmente irrilevanti rispetto allo scopo principale di una classe. E se in futuro volessi ottenere alcuni dati dal disco? O vuoi che l'utente lo acceda? Vai abbastanza lontano lungo quella strada e una semplice Userclasse deve avere un codice per gestire ogni possibile metodo di immissione e recupero dei dati. Tieni semplicemente un Userblocco di classe e mantieni i dati mentre è in memoria. Tutto il resto può essere gestito da classi più appropriate.

— user1118321
fonte