É uma boa prática agrupar um conjunto de propriedades relacionado em sua própria estrutura / classe?

Escrevendo um objeto User em Swift, embora minha pergunta esteja relacionada a qualquer linguagem fortemente tipada. Um usuário pode ter vários links (perfil do Facebook, perfil do Instagram etc.). Algumas perguntas sobre isso.

1. É uma boa prática agrupar links em seu próprio objeto?

    struct Usuário {
       var firstName: string
       var lastName: string
       var email: string
       links var: Links
    }

    Links de estrutura {
       var facebook: string
       var instagram: string
       var twitter: string 
    }

Ou eles devem estar soltos? Eu sei que tecnicamente as duas maneiras são boas, mas me pergunto se existe uma abordagem recomendada, em geral - especialmente para facilitar a leitura.

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

2. Em um cenário como esse, os links devem ser uma coleção / lista? Achei que não deveria ser uma lista, porque há um número fixo de opções de links disponíveis, e não um número crescente. Meu pensamento está certo?

3. É uma boa prática colocar meus métodos de rede dentro do objeto Usuário, como getUsers, getUser, updateUser?

Sei que isso pode ser subjetivo, mas estou tentando entender qual é a melhor prática em situações semelhantes. Gostaria de receber qualquer indicação.

Você quer

• zero de uma coisa,
• uma coisa, ou
• um número arbitrário da coisa.

Estou chocado que seu design preveja que o número de links necessários sempre será três e que você saiba quais são os nomes deles para sempre.

O que estou pregando é chamado de regra do infinito zero . Pode não ser óbvio a princípio, mas é o que me diz que seu design não é tolerante ao futuro.

Eu me sentiria diferente se houvesse algo sobre esses links que fosse especial para eles. Alguma coisa especial que eu faço diferente ao acessar um link do facebook que não faço para um link do twitter. Isso os tornaria coisas diferentes. Mas isso não é indicado neste código.

É por isso que não me incomodo com a sequência de emails. Eu sei que é usado de uma maneira diferente dos links.

Então, até que eu veja um motivo para usar esses links de maneira diferente, estou do lado de uma coleção de links.

Você está prestes a cair na armadilha "Eu vejo uma possibilidade técnica".

Só porque você vê uma característica comum entre os itens não significa que faz sentido aplicar alguma agregação neles. A agregação deve significar algo. Não no nível técnico, mas no domínio do seu problema.

Todos eles são bons, mas no contexto de uma classe de usuário, isso significa alguma coisa? Não. É tão sem sentido quanto seria subgrupos usando classes denominadas "strings" e "numbers".

O problema com esse tipo de coisa é que borra o seu modelo. Isso força o leitor de código a separar o significativo do sem sentido, antes de ter uma compreensão completa do domínio.

Ninguém nunca fala sobre os links de um usuário. Seria diferente se você chamasse sua agregação SocialNetworkIds. Como isso realmente significaria algo, seria uma propriedade verdadeira do Usuário e não uma coleção técnica arbitrária.

Em geral, acho que seria razoável ter os links por conta própria, structse é provável que você aplique operações semelhantes a cada um deles, e principalmente se você sempre executa as mesmas operações em todos eles. Se eles são para fins não relacionados em seu aplicativo, eu os separaria. Por exemplo, se eles fossem a página inicial do usuário, o site do provedor de seguro de saúde e um link para o site de notícias favorito, provavelmente não os agruparia, pois eles parecem não relacionados. Mas para três sites de mídia social, parece que eles serão tratados da mesma forma em um aplicativo e, como tal, provavelmente devem ser agrupados. Eu usaria um nome mais descritivo do que no Linksentanto. (Que tipo de links? Com ​​que finalidade no seu aplicativo?)

Eu concordo com o seu pensamento no # 2. Como mencionado acima, se o número crescer ou se tornar variável, uma lista ou outra coleção seria uma boa escolha, mas não para o cenário que você descreveu.

Eu não colocaria métodos de rede dentro dos objetos que retêm os dados recuperados pela rede. De onde os dados vieram e como obtê-los geralmente são irrelevantes para o principal objetivo de uma classe. E se, no futuro, você desejar obter alguns dados do disco? Ou deseja que o usuário o insira? Vá longe o suficiente nessa estrada e uma Userclasse simples precisa ter código para lidar com todos os métodos possíveis de entrada e recuperação de dados. Apenas faça uma Userclasse reter e manter os dados enquanto estiverem na memória. Tudo o resto pode ser tratado por classes mais apropriadas.