Простір імен + функцій проти статичних методів у класі

Скажімо, я маю або збираюся писати набір пов'язаних функцій. Скажімо, вони пов'язані з математикою. Організаційно я повинен:

1. Запишіть ці функції та поставте їх у мій MyMathпростір імен та посилайтесь на них черезMyMath::XYZ()
2. Створіть клас, що називається, MyMathі зробіть ці методи статичними та зверніться до аналогічногоMyMath::XYZ()

Чому я б обрав один за іншим як засіб організації свого програмного забезпечення?

За замовчуванням використовуйте функції простору імен.

Класи - це створення об'єктів, а не заміна просторів імен.

В об'єктно-орієнтованому коді

Скотт Майєрс написав цілий пункт для своєї ефективної книги C ++ на цю тему "Віддавайте перевагу функціям, що не належать до друзів, перед функціями членів". Я знайшов онлайн-посилання на цей принцип у статті від Herb Sutter:http://www.gotw.ca/gotw/084.htm

Важливо знати, що: У C ++ функції в тому ж просторі імен, що і клас, належать до інтерфейсу цього класу (оскільки ADL здійснюватиме пошук цих функцій при вирішенні викликів функцій).

Функції, розміщені в іменах, якщо не оголошені "friend", не мають доступу до внутрішніх даних класу, тоді як статичні методи мають.

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

Розширення I

Додавання коду до інтерфейсу класу.

У C # ви можете додати методи до класу, навіть якщо у вас немає доступу до нього. Але в C ++ це неможливо.

Але все ж у C ++ ви можете додати функцію простору імен, навіть до класу, який хтось написав для вас.

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

Розширення II

Побічним ефектом попереднього пункту неможливо оголосити статичні методи у кількох заголовках. Кожен метод повинен бути оголошений в одному класі.

Для просторів імен функції з одного простору імен можуть бути оголошені в декількох заголовках (найкращим прикладом цього є майже стандартна функція swap).

Розширення III

Основна прохолода простору імен полягає в тому, що в якомусь коді ви можете уникнути його згадування, якщо будете використовувати ключове слово "using":

#include <string>
#include <vector>

// Etc.
{
   using namespace std ;
   // Now, everything from std is accessible without qualification
   string s ; // Ok
   vector v ; // Ok
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

І ви навіть можете обмежити "забруднення" одним класом:

#include <string>
#include <vector>

{
   using std::string ;
   string s ; // Ok
   vector v ; // COMPILATION ERROR
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Цей "шаблон" є обов'язковим для правильного використання майже стандартної ідіоми своп.

І це неможливо зробити зі статичними методами на заняттях.

Отже, простори імен C ++ мають власну семантику.

Але це йде далі, оскільки ви можете комбінувати простори імен таким чином, як схожий на спадщину.

Наприклад, якщо у вас є простір імен A з функцією AAA, простір імен B з функцією BBB, ви можете оголосити простір імен C і привести AAA і BBB в цей простір імен за допомогою ключового слова.

Висновок

Простори імен призначені для просторів імен. Заняття призначені для занять.

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

Не використовуйте класи, коли вам потрібні простори імен.

І у вашому випадку вам потрібні простори імен.

Є багато людей, які не погоджуються зі мною, але ось як я це бачу:

Клас - це, по суті, визначення певного виду об’єкта. Статичні методи повинні визначати операції, тісно пов'язані з цим визначенням об'єкта.

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

Наприклад, у вашому випадку запитайте себе: "Що таке MyMath?" Якщо MyMathне визначає вид об’єкта, то я б сказав: не робіть це класом.

Але, як я вже сказав, я знаю, що є багато людей, які (навіть жорстоко) не погоджуються зі мною щодо цього (зокрема, розробників Java та C #).

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

В іншому випадку використовуйте функції, розділені на імена.

У відповідь на коментарі: так, статичні методи та статичні дані, як правило, надмірно використовуються. Ось чому я запропонував лише два пов’язані між собою сценарії, де я думаю, що вони можуть бути корисними. У конкретному прикладі ОП (набір математичних процедур), якщо він хотів би можливість задати параметри - скажімо, тип основних даних і точність виводу - що буде застосовано до всіх процедур, він може зробити щось на кшталт:

template<typename T, int decimalPlaces>
class MyMath
{
   // routines operate on datatype T, preserving at least decimalPlaces precision
};

// math routines for manufacturing calculations
typedef MyMath<double, 4> CAMMath;
// math routines for on-screen displays
typedef MyMath<float, 2> PreviewMath;

Якщо вам це не потрібно, то всі кошти використовувати простір імен.

Ви повинні використовувати простір імен, оскільки у простору імен є безліч переваг перед класом:

• Не потрібно визначати все в одному заголовку
• Вам не потрібно виставляти всю свою реалізацію в заголовку
• Ви не usingможете користуватися класом; ти можешusing членом простору імен
• Ви не можете using class, хочаusing namespace це не все так часто гарна ідея
• Використання класу означає, що існує якийсь об’єкт, який потрібно створити, коли його дійсно немає

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

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

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

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