Чи є хорошою практикою вбудувати пов'язаний набір властивостей у власну структуру / клас?


10

Написання об’єкта User у Swift, хоча моє запитання стосується будь-якої сильно набраної мови. Користувач може мати купу посилань (FacebookProfile, InstagramProfile тощо). Кілька питань навколо цього.

  1. Чи корисна практика загортати посилання у власному об’єкті?
    User {
       var firstName: рядок
       var lastName: рядок
       var email: рядок
       var посилання: Посилання
    }
    Структурні посилання {
       var facebook: string
       var instagram: string
       var twitter: рядок 
    }

Або вони повинні бути пухкими? Я технічно знаю, що обидва способи - це добре, але цікаво, чи є рекомендований підхід, взагалі - особливо для читабельності.

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}
  1. У такому сценарії, чи повинні посилання бути колекцією / списком? Я вважав, що це не повинен бути список, оскільки є фіксована кількість варіантів посилань, а не зростаюча кількість. Чи правильно моє мислення?

  2. Чи є гарною практикою розміщення моїх мережевих методів всередині об'єкта User, наприклад getUsers, getUser, updateUser?

Я знаю, що це може бути суб'єктивним, але я намагаюся зрозуміти, яка найкраща практика в подібних ситуаціях. Буду вдячний за будь-які покажчики.

Відповіді:


30

Вам або знадобиться

  • нуль речі,
  • одна річ, або
  • довільна кількість речі.

Я вражений тим, що ваш дизайн передбачає, що кількість потрібних посилань завжди буде три і що ви знаєте, які їх імена назавжди.

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

Я б почувався інакше, якби щось про ці посилання було особливим для них. Якась особлива річ, яку я роблю різною, коли отримую посилання на facebook, що я не роблю для посилання на Twitter. Це зробило б їх різними речами. Але це не вказано в цьому коді.

Ось чому мене не турбує рядок електронної пошти. Я знаю, що використовується по-іншому, ніж посилання.

Тому, поки я не побачу причини використовувати ці посилання по-іншому, я перебуваю на стороні колекції посилань.


4
FacebookProfile, InstagramProfile, ...Я думаю, що ОП вже відповів на питання. Його мова говорить про те, що у користувачів може бути жоден або кілька профілів, пов’язаних із соціальними мережами. Але програміст всередині нього перетворив цей елемент на прості зв'язки. Чому б не колекцію Profiles? Я погодився з CandiedOrange. Ви занадто багато припускаєте про майбутнє. Можуть з’явитися нові соціальні мережі. Фактичні можуть зникнути. Користувачі можуть переходити з однієї мережі в іншу.
Laiv

Це здогадки. Скажіть, ви хочете використовувати ці профілі для соціальних логінів. Маючи профіль компонента, ми маємо з чого почати. Де інкапсулювати інформацію щодо аутентифікації та поточного сеансу за допомогою цих профілів. Це може вважатися YAGNI або надмірно інженерним, але нічого про це не варто думати, подивіться, чи можуть ці функції запитуватися чи вони можуть надати цінність нашій програмі. Якщо ні, просто відмовтеся від них.
Laiv

1
@ Прабху залежить від того, чому ви її обмежуєте. Моя здогадка, тільки стільки вписується в графічний інтерфейс. Що добре. Але не обмежуйте структуру даних через GUI. GUI змінюються на примху. Структури даних дорого змінювати. Це дійсно платить, щоб отримати їх правильно з першого разу.
candied_orange

2
В тім-то й річ. Просто прийняти ті структури, які зроблять можливі зміни в майбутньому менш болючими. Ні більше, ні менше. Ми, Кандід і я говоримо це тому, що ми (я вірю) часто стикаємося з подібними ситуаціями, і ми передбачаємо можливі риси, сприйнятливі до змін або розвитку. Зрештою, ви ближче до проекту та його майбутньої перспективи.
Лаїв

1
@Prabhu: Зауважте, що ви задали питання про добру практику , а не про те, чи це найбільш стислий підхід для вашого конкретного сценарію. Я, як правило, на стороні уникнення надмірної інженерії, але вартість майбутнього технічного обслуговування (додавання / видалення посилань, оновлення визначень класів сутності, ...) значно перевищує вартість впровадження колекції посилань. Якщо ви назвали стовпці link1, link2, link3, потреба в колекції була б більш очевидною. Однак той факт, що ви дали стовпцям більш змістовну назву, не змінює факту, що це збір повторюваних даних.
Flater

6

Ви на порозі потрапляння в пастку "Я бачу технічну можливість".

Тільки те, що ви бачите загальну ознаку серед предметів, не означає, що має сенс застосувати до них деяку сукупність. Сукупність має щось означати. Не на технічному рівні, а в проблемній області.

Всі вони добре, але в контексті класу користувача це щось означає? Ні. Це так само безглуздо, як і підгрупа, використовуючи класи під назвою "рядки" та "числа".

Проблема з подібними речами полягає в тому, що вона розмиває вашу модель. Це змушує зчитувач кодів відірвати змістовне від безглуздого, перш ніж мати повне розуміння домену.

Ніхто ніколи не говорить про посилання користувача. Було б інакше, якби ви назвали свою агрегацію SocialNetworkIds. Оскільки це насправді щось означатиме, це буде справжньою властивістю Користувача, а не довільною технічною колекцією.


Саме те, в чому мої сумніви, змусило мене задати це питання. Єдине співвідношення між різними посиланнями полягає в тому, що вони, можливо, відображатимуться разом в інтерфейсі користувача. Отже, у цьому випадку ви б запропонували НЕ ставити їх в окремий об’єкт право, а скоріше тримати їх безпосередньо під об’єктом Користувача?
Прабху

1
Я не думаю, що це було б корисно в цьому випадку. У вас ще немає проблеми, яка виправдовує додавання шару складності. Якщо у вас було набагато більше властивостей, можливо, в результаті групування зусилля (з влучними назвами для груп), можливо, виграли б. Важко сказати, що підходить без контексту. Суть полягає в тому, що вона повинна полегшити справи. Щоб зрозуміти та / або продовжити будь-який наступний крок у процесі розробки.
Мартін Мейт

Я взагалі , як уникнути надмірної техніки, але я задаюся питанням : ти б сказав те ж саме , якщо ОП назвав свої поля link1, link2, link3? Конструкція структури даних не залежить від назви полів, тому мій приклад функціонально еквівалентний. Це питання майбутньої ізоляції. YAGNI, як правило, застосовується, але якщо не що, соціальні медіа зарекомендували себе як сприйнятливі до вірусної популярності та змін. Уникати перепланування кожного нового популярного веб-сайту соціальних медіа видається бажаним. В іншому випадку ви ризикуєте потрапити в "що ще одне поле?" пастка, яка може створити величезну заборгованість.
Flater

1

Взагалі, я думаю, що було б доцільно, щоб посилання були власними, structякщо ви, ймовірно, застосовуєте подібні операції до кожної з них, особливо, якщо ви завжди виконуєте однакові операції на всіх. Якщо вони є у вашій заяві для непов'язаних цілей, то я б зробив їх окремими. Наприклад, якби вони були домашньою сторінкою користувача, веб-сайтом їх медичного страхування та посиланням на їх улюблений сайт новин, я, мабуть, не згрупував би їх разом, оскільки вони здаються не пов'язаними. Але для 3-х сайтів соціальних медіа, схоже, що з ними буде поводитися аналогічно у додатку, і як таке, мабуть, слід згрупувати разом. Я б використовував більш описову назву, ніж Linksвсе-таки. (Який тип посилань? З якою метою у вашому додатку?)

Я згоден з вашим мисленням №2. Як згадувалося вище, якщо кількість зростатиме або стає змінною, список чи інша колекція буде хорошим вибором, але не для описаного вами сценарію.

Я б не розміщував методи мереж всередині об'єктів, що містять дані, отримані в мережі. Звідки беруться дані та як їх отримати, як правило, не має значення для основної мети класу. Що робити, якщо в майбутньому ви хочете отримати деякі дані з диска? Або хочете, щоб користувач увійшов до нього? Пройдіть досить далеко по цій дорозі, і простий Userклас повинен мати код для обробки всіх можливих методів введення та пошуку даних. Просто зробіть Userутримання класу і підтримуйте дані, поки вони знаходяться в пам'яті. З усім іншим можна впоратися з більш відповідними класами.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.