Это хорошая практика, чтобы обернуть связанный набор свойств в свою собственную структуру / класс?

Написание объекта User в Swift, хотя мой вопрос касается любого строго типизированного языка. Пользователь может иметь несколько ссылок (FacebookProfile, InstagramProfile и т. Д.). Несколько вопросов по этому поводу.

1. Это хорошая практика, чтобы обернуть ссылки в свой собственный объект?

    struct User {
       var firstName: строка
       var lastName: строка
       var email: string
       Вар ссылки: Ссылки
    }

    struct Links {
       var facebook: строка
       var instagram: строка
       var twitter: string 
    }

Или они должны быть свободными? Я знаю, что технически оба способа хороши, но интересно, есть ли рекомендуемый подход, в целом - особенно для удобства чтения.

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

2. В таком случае ссылки должны быть коллекцией / списком? Я полагал, что это не должен быть список, потому что есть фиксированное количество доступных вариантов ссылок, а не растущее число. Правильно ли мое мышление?

3. Является ли хорошей практикой размещать мои сетевые методы внутри объекта User, такие как getUsers, getUser, updateUser?

Я знаю, что это может быть субъективно, но я пытаюсь понять, как лучше всего справляться с подобными ситуациями. Был бы признателен за любые указатели.

Вам либо понадобится

• ноль вещей,
• одно, или
• произвольный номер вещи.

Я шокирован тем, что ваш дизайн предсказывает, что количество необходимых ссылок всегда будет равным трем, и что вы всегда будете знать, как их зовут.

То, что я проповедую, называется правилом нулевой бесконечности . Поначалу это может быть неочевидно, но это говорит о том, что ваш дизайн не терпит будущего.

Я бы чувствовал себя по-другому, если бы в этих ссылках было что-то особенное для них. Что-то особенное, что я делаю по-другому при доступе к ссылке на Facebook, но я не делаю это для ссылки в твиттере. Это сделало бы их разными. Но это не указано в этом коде.

Вот почему меня не беспокоит строка электронного письма. Я знаю, что используется по-другому, чем ссылки.

Так что, пока я не вижу причины использовать эти ссылки по-другому, я на стороне коллекции ссылок.

Вы находитесь на грани попадания в ловушку "Я вижу техническую возможность".

То, что вы видите общую черту среди предметов, не означает, что имеет смысл применять к ним некоторую агрегацию. Агрегация должна что-то значить. Не на техническом уровне, а в вашей проблемной области.

Все они в порядке, но в контексте пользовательского класса это что-нибудь значит? Нет. Это так же бессмысленно, как и подгруппа, использующая классы с именами «строки» и «числа».

Проблема с такими вещами в том, что это размывает вашу модель. Это заставляет читателя кода отделить значимое от бессмысленного, прежде чем он получит полное понимание предметной области.

Никто никогда не говорит о ссылках пользователя. Было бы иначе, если бы вы назвали свой агрегат SocialNetworkIds. Поскольку это действительно что-то значит, это будет истинное свойство пользователя, а не произвольная техническая коллекция.

В целом, я думаю, было бы разумно, чтобы ссылки были самостоятельными, structесли вы, вероятно, будете применять аналогичные операции к каждой из них, особенно если вы всегда выполняете одинаковые операции для всех из них. Если они предназначены для не связанных целей в вашем приложении, то я бы выделил их. Например, если бы они были домашней страницей пользователя, веб-сайтом их поставщика медицинского страхования и ссылкой на их любимый новостной сайт, я бы, вероятно, не сгруппировал их вместе, поскольку они кажутся несвязанными. Но для 3 сайтов социальных сетей кажется, что они будут обрабатываться одинаково в приложении, и поэтому их, вероятно, следует сгруппировать. Я бы использовал более описательное имя, чем Linksхотя бы. (Какой тип ссылок? Для каких целей в вашем приложении?)

Я согласен с вашим мнением о # 2. Как упоминалось выше, если число будет расти или становиться переменным, список или другая коллекция будет хорошим выбором, но не для сценария, который вы описали.

Я не стал бы размещать сетевые методы внутри объектов, которые содержат данные, полученные сетью. Откуда поступили данные и как их получить, обычно не имеет отношения к основной цели класса. Что, если в будущем вы захотите получить данные с диска? Или хотите, чтобы пользователь ввел его? Пройдите достаточно далеко по этому пути, и простой Userкласс должен иметь код для обработки всех возможных методов ввода и извлечения данных. Просто Userдержите класс и сохраняйте данные, пока они находятся в памяти. Все остальное может быть обработано более подходящими классами.