È buona pratica racchiudere un insieme correlato di proprietà nella propria struttura / classe?

10

Scrivere un oggetto Utente in Swift, anche se la mia domanda si riferisce a qualsiasi lingua strongmente tipizzata. Un utente può avere molti collegamenti (FacebookProfile, InstagramProfile, ecc.). Alcune domande su questo.

  1. È buona pratica racchiudere i collegamenti nel proprio oggetto?
    struct User {
       var firstName: string
       var lastName: string
       var email: string
       var links: Links
    }
    struct Links {
       var facebook: string
       var instagram: string
       var twitter: string 
    }

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

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}
  1. In uno scenario come questo, i link dovrebbero essere una raccolta / lista? Ho pensato che non dovrebbe essere una lista perché c'è un numero fisso di opzioni di collegamento disponibili e non un numero crescente. Il mio pensiero è giusto?

  2. È buona pratica mettere i miei metodi di networking all'interno dell'oggetto User, come getUsers, getUser, updateUser?

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

    
posta Prabhu 05.02.2018 - 05:31
fonte

3 risposte

30

Avrai bisogno di

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

Sono scioccato dal fatto che il tuo progetto prevede che il numero di link necessari sarà sempre tre e che tu sai quali sono i loro nomi per sempre.

Quello che sto predicando è chiamato zero una regola infinity . All'inizio potrebbe non essere ovvio, ma è quello che mi dice che il tuo design non è tollerante per il futuro.

Mi sentirei diversamente se ci fosse qualcosa in questi collegamenti che era speciale per loro. Qualche cosa speciale che faccio di diverso quando accedo a un link di Facebook che non faccio per un link di 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 link.

Quindi finché non vedo un motivo per utilizzare questi collegamenti in modo diverso, sono sul lato di una raccolta di link.

    
risposta data 05.02.2018 - 05:47
fonte
6

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

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

Sono tutti collegamenti a posto, ma nel contesto di una classe utente, vuol dire qualcosa? No. È privo di significato come sarebbe per il sottogruppo usando classi chiamate "stringhe" e "numeri".

Il problema con questo tipo di cose è che offusca il tuo modello. Costringe il lettore di codice a separare il significativo dall'insignificante, prima di avere una piena comprensione del dominio.

Nessuno parla mai dei link di un utente. Sarebbe diverso se chiamassi la tua aggregazione SocialNetworkIds. Perché in realtà ciò significherebbe qualcosa, sarebbe una vera proprietà dell'Utente piuttosto che una raccolta tecnica arbitraria.

    
risposta data 05.02.2018 - 07:43
fonte
1

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

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

Non metterei i metodi di rete all'interno degli oggetti che contengono i dati recuperati dalla rete. Da dove provengono i dati, e come ottenerli sono in genere irrilevanti rispetto allo scopo principale di una classe. Cosa succede se in futuro si desidera ottenere alcuni dati dal disco? O vuoi che l'utente lo inserisca? Vai abbastanza lontano lungo quella strada e una semplice classe User deve avere il codice per gestire ogni possibile metodo di immissione e recupero dei dati. Crea una trattenuta di classe User e mantieni i dati mentre è in memoria. Tutto il resto può essere gestito da classi più appropriate.

    
risposta data 05.02.2018 - 06:03
fonte

Leggi altre domande sui tag