Що краще: купа гетерів або 1 метод з параметром рядка вибору?

Наша область знань стосується людей, які босими ногами переходять через тарілку, що записує тиск. Ми робимо розпізнавання зображень, що призводить до об'єктів класу 'Foot', якщо в даних датчика розпізнається стопа людини.

Існує кілька розрахунків, які необхідно виконати за даними стопи.

Тепер, який API краще:

class Foot : public RecognizedObject  { 
  MaxPressureFrame getMaxPressureFrame();
  FootAxis getFootAxis();
  AnatomicalZones getAnatomicalZones();

  // + similar getters for other calculations

  // ...
}

Або:

class Foot : public RecognizedObject {
  virtual CalculationBase getCalculation(QString aName);

  // ...
}

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

Будь-яка порада?

Деякі профі для першого підходу можуть бути:

• KISS - все дуже конкретно. API, але також і реалізація.
• сильно набрані повернені значення.
• успадковування від цього класу є нерозумним. Нічого не можна відміняти, лише додавати.
• API дуже закритий, нічого не входить, нічого не можна відміняти, тому менше може піти не так.

Деякі конфлікти:

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

Деякі профі для другого підходу:

• більш гнучким
• api рідше зміниться (якщо припустити, що абстракція правильна, якщо ні, зміна обійдеться дорожче)

Деякі конфлікти:

• вільно набрано. Потреби формуються під час кожного дзвінка.
• параметр string - у мене погані почуття з цього приводу (розгалуження на значення рядків ...)
• Немає жодного випадку / вимоги використання, яка б надавала додаткову гнучкість, але це може бути в майбутньому.
• API встановлює обмеження: кожен обчислення має виходити з базового класу. Отримати обчислення буде вимушено за допомогою цього методу 1, і передача додаткових параметрів буде неможливою, якщо тільки ми не розробимо ще більш динамічний, надто гнучкий спосіб передачі параметрів, який ще більше збільшує складність.

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

• Кількість отримувачів буде зростати, оскільки кожен новий розрахунок, який ми вигадуємо, додається до списку

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

• API швидше змінюється, і якщо будуть внесені порушення, нам потрібна нова версія API, Foot2.

Правда, але це насправді величезна проблема;) ви можете визначити інтерфейси для часткових API, і тоді вам не потрібно повторно компілювати залежний клас, на який не впливають новіші API (Тому немає потреби у Foot2). Це дозволяє краще роз'єднати, залежність тепер залежить від інтерфейсу, а не від реалізації. Більше того, якщо існуючий інтерфейс зміниться, ви будете мати помилку компіляції у залежних класах, що чудово запобігає застарілому коду.

• у разі повторного використання класу в інших проектах, можливо, нам не знадобиться кожен розрахунок

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

Я б рекомендував варіант 3: Дайте зрозуміти, що обчислення не є сутнісною частиною абстракції а Foot, але оперують нею. Потім ви можете розділити Footі обчислення на окремі класи, наприклад:

class Foot : public RecognizedObject {
public:
    // Rather low-level API to access all characteristics that might be needed by a calculation
};

class MaxPressureFrame {
public:
    MaxPressureFrame(const Foot& aFoot); // Performs the calculation based on the information in aFoot
    //API for accessing the results of the calculation
};

// Similar classes for other calculations

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