Два структури з однаковими членами, але різними назвами, це гарна ідея?

Я пишу програму, яка передбачає роботу як з полярними, так і декартовими координатами.

Чи має сенс створювати два різних структур для кожного виду точок, одна з яких Xі Yчленів і один з Rі Thetaчленами.

Або це занадто багато, і краще мати лише одну структуру з членами firstі secondв якості членів.

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

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

Я бачив обидва рішення, тому це, безумовно, залежить від контексту.

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

Крайнє рішення (яке ми врешті-решт надали) - мати базовий клас шаблонів CRTP з функціями get <0> () get <1> () та <2> (), щоб отримати елементи в загальному вигляді. Потім ці функції визначаються в декартовій або полярній структурі, що походить від цього базового класу. Він вирішує всі проблеми, але виходить досить нерозумною ціною: вивчити метапрограмування шаблонів. Однак якщо метапрограмування шаблонів уже є справедливою грою для вашого проекту, це може бути хорошим співпадінням.

Так, це має багато сенсу.

Цінність структури полягає не лише в тому, що вона інкапсулює дані під зручним іменем. Цінність полягає в тому, що вона кодифікує ваші наміри, щоб компілятор міг допомогти вам переконатися, що ви не порушуєте їх якийсь день (наприклад, помилка встановлення полярної координати для декартового набору координат).

Люди погано запам’ятовують такі химерні деталі, але добре створюють сміливі винахідливі плани. Комп'ютери непогані у химерних деталях і погані у творчих планах. Тому завжди корисно перенести на комп’ютер якнайбільше технічного обслуговування деталей, залишаючи розум вільним працювати над грандіозним планом.

Так, хоча і декартові, і полярні (замість них) виразно розважливі схеми представлення координат, вони в ідеалі ніколи не повинні бути змішаними (якщо у вас є декартова точка {1,1}, це зовсім інша точка від полярної {1,1 }).

В залежності від ваших потреб, вона також може бути варто реалізації координатно - інтерфейс, з допомогою методів , таких як X(), Y(), Displacement()і Angle()(або , можливо , Radius()і Theta(), в залежності від).

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

Якщо ви просто зробите одну структуру з членами, названими firstі second, тоді імена нічого не означають; ви б по суті ставились до них як до пам'яті. Це перемагає призначення мови програмування високого рівня.

Крім того, те, що всі вони є репрезентативними, doubleне означає, що ви можете використовувати їх взаємозамінно. Наприклад, θ - безрозмірний кут, тоді як y має одиниці довжини. Оскільки типи не є логічно замінними, вони повинні бути двома несумісними структурами.

Якщо вам справді потрібно грати в трюки з повторним використанням пам’яті - а ви майже напевно не повинні - ви можете використовувати unionтип C, щоб зрозуміти свій намір.

По-перше, мати обидва явно, відповідно до цілком обгрунтованої відповіді @ Kilian-foth.

Однак я хочу додати:

Запитайте: Чи дійсно у вас є операції, які є загальними для обох, якщо їх розглядати як пари double? Зауважте, це не те саме, що говорити про те, що у вас є операції, які стосуються обох у власних умовах. Наприклад, "сюжет (Коорда)" переймається тим Coord, полярний чи декартовий. З іншого боку, зберігання файлів просто обробляє дані як є. Якщо у вас дійсно є загальні операції, розгляньте або визначення базового класу, або визначення перетворювача в std::pair<double, double>або, tupleабо що ви маєте на своїй мові.

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

Таким чином, ви можете гарантувати, що всі основні операції закодовані, Cartesianа потім надавати підтримку для перетворення Polarна Cartesian. Це дозволяє уникнути реалізації різних версій багатьох операцій.

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

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

Ще один варіант, залежно від використання класів (якщо вам потрібен поліморфізм і подібний), - це використання публічної спадщини для обох нових типів, тому вони мають однаковий публічний інтерфейс, як і загальний тип, який вони представляють. Це також дозволяє розділити еволюцію типів.

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

Уявіть сценарій: у вас є кілька декартових точок: pntA і pntB. Тоді ви чомусь вирішите, що вони повинні бути краще представлені в полярних координатах, і змінити декларацію та конструктор.

Тепер, якщо всі ваші операції були лише методами викликів типу:

double distance = pntA.distanceFrom(pntB);

значить, ти все добре. Але що робити, якщо ви явно користувались членами? Порівняйте

double leftMargin = abs(pntA.x - pntB.x);
double leftMargin = abs(pntA.first - pntB.first);

У першому випадку код не складеться. Ви побачите помилку одразу і зможете її виправити. Але якщо у вас однакові імена учасників, помилка буде лише на логічному рівні, набагато складніше виявити.

Якщо ви пишете не об'єктно-орієнтованою мовою, тоді навіть простіше передати неправильну структуру функції. Що заважає вам написати наступний код?

double distance = calculate_distance_polar(cartesianPointA, polarPointB);

З іншого боку, різні типи даних дозволять вам знайти помилку під час компіляції.