Я не розумію аргументів проти перевантаження оператора [закрито]

Я щойно прочитав одну із статей Джоеля, в якій він говорить:

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

i = j * 5;

... в C ви знаєте, щонайменше, що j множується на п'ять, а результати зберігаються в i.

Але якщо ви побачите той самий фрагмент коду в C ++, ви нічого не знаєте. Нічого. Єдиний спосіб дізнатися, що насправді відбувається в C ++, - це з’ясувати, які типи i та j є, що може бути декларовано десь взагалі. Це тому, що j може бути типу, який operator*перевантажив, і він робить щось надзвичайно дотепне, коли ви намагаєтесь його примножити.

(Наголос мій.) Бояться мовних особливостей, які приховують речі? Як можна цього злякатися? Чи не приховування речей (також відомих як абстракція ) є однією з ключових ідей об’єктно-орієнтованого програмування? Щоразу, коли ви викликаєте метод a.foo(b), ви не маєте уявлення про те, що це може зробити. Ви повинні з'ясувати , які типи aі bє, то , що може бути оголошена де - то зовсім інше. Тож чи варто відмовлятися від об'єктно-орієнтованого програмування, оскільки воно приховує занадто багато речей від програміста?

І чим j * 5відрізняється від того j.multiply(5), що вам, можливо, доведеться писати мовою, яка не підтримує перевантаження оператора? Знову ж таки, вам доведеться з’ясувати тип jі заглянути всередину multiplyметоду, тому що ось і ось, jможе бути такого типу, який має multiplyметод, який робить щось надзвичайно дотепне.

"Муахаха, я злий програміст, який називає метод multiply, але те, що він насправді робить, є абсолютно незрозумілим і неінтуїтивним і не має нічого спільного з множенням речей". Це сценарій, який ми повинні враховувати при розробці мови програмування? Тоді нам доведеться відмовитися від ідентифікаторів з мов програмування на тій підставі, що вони можуть вводити в оману!

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

Будь ласка, просвіти мене.

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

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

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

Наприклад, це має сенс перевантажувати +або *оператор для class Matrixабо class Complex. Всі миттєво дізнаються, що це означає. З іншого боку, для мене той факт, що +означає об'єднання рядків, зовсім не очевидний, навіть якщо Java робить це як частину мови, а STL робить для std::stringвикористання перевантаження оператора.

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

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

У Haskell "+", "-", "*", "/" тощо - це лише (інфікс) функції.

Чи слід називати функцію інфіксації "плюс", як у "4 плюс 2"? Чому б і ні, якщо доповнення - це те, що робить ваша функція. Чи маєте ви назвати свою функцію "плюс" "+"? Чому ні.

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

EDIT: я зробив більш чіткий погляд

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

Це трагічно з двох причин:

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

Я дещо згоден.

Якщо ви пишете multiply(j,5), jможе бути скалярного чи матричного типу, що робить multiply()більш-менш складним, залежно від того, що jє. Однак, якщо ви взагалі відмовитеся від ідеї перевантажувати, то функція повинна була б бути названа multiply_scalar()або multiply_matrix()яка б дала зрозуміти, що відбувається внизу.

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

Я бачу дві проблеми з перевантаженням оператора.

1. Перевантаження змінює семантику оператора, навіть якщо це не призначено програмістом. Наприклад, коли ви перевантажуєтесь &&, ||або ,ви втрачаєте точки послідовності, що маються на увазі вбудованими варіантами цих операторів (а також короткою схемою поведінки логічних операторів). З цієї причини краще не перевантажувати цих операторів, навіть якщо мова це дозволяє.
2. Деякі люди бачать перевантаження оператора як таку приємну особливість, вони починають використовувати її скрізь, навіть якщо це не відповідне рішення. Це змушує інших людей надмірно реагувати в іншому напрямку та застерігає від використання перевантаження оператора. Я не погоджуюся ні з однією з груп, але візьміть середнє місце: Перевантаження оператора повинна використовуватися вкрай і лише тоді
   • перевантажений оператор має природне значення як для доменних експертів, так і для програмних експертів. Якщо ці дві групи не погоджуються з природним значенням для оператора, не перевантажуйте його.
   • для відповідних типів (типів) не існує природного значення для оператора, а безпосередній контекст (бажано, той самий вираз, але не більше кількох рядків) завжди дає зрозуміти, яке значення має оператор. Прикладом цієї категорії можуть бути operator<<потоки.

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

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

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

Одна відмінність між перевантаженням a * bі викликом multiply(a,b)полягає в тому, що останні можуть легко схопитися за них. Якщо multiplyфункція не перевантажена для різних типів, то ви можете точно дізнатися, що функція буде робити, без необхідності відстежувати типи aта b.

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

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

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

Я думаю, що перевантаження математичних операторів - це не справжня проблема перевантаження оператора в C ++. Я думаю, що перевантаження операторів, які не повинні покладатися на контекст виразу (тобто типу), є "злом". Наприклад, перевантаження , [ ] ( ) -> ->* new deleteабо навіть одинарне *. Ви маєте певний набір від тих операторів, які ніколи не повинні змінюватися.

Я прекрасно розумію, що вам не подобається аргумент Джоеля про приховування. Я також ні. Дійсно набагато краще використовувати "+" для таких речей, як вбудовані числові типи або для власних, наприклад, матриця. Я визнаю, що це акуратно та елегантно, щоб можна було помножувати дві матриці на '*' замість '.multiply ()'. І зрештою, ми маємо однаковий вид абстракції в обох випадках.

Тут боляче - читабельність вашого коду. У реальних випадках не в академічному прикладі множення матриць. Особливо, якщо ваша мова дозволяє визначити операторів, які спочатку відсутні в ядрі мови, наприклад =:=. Наразі виникає багато зайвих питань. Про що той проклятий оператор? Я маю на увазі, що є перевагою цієї речі? Що таке асоціативність? У якому порядку a =:= b =:= cреально виконується?

Це вже аргумент проти перевантаження оператора. Ще не переконаний? Перевірка правил пріоритету у вас зайняла не більше 10 секунд? Гаразд, підемо далі.

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

Тепер уявіть, що вам доведеться використовувати декілька API, які сильно використовують операторів, що перевантажують разом, в одному коді. Або ще краще - ви повинні прочитати такий спадковий код. Це коли перевантаження оператора дійсно смокче. В основному, якщо в одному місці багато операторів, що перевантажуються, вони незабаром почнуть змішуватися з іншими символами, які не буквено-цифровими, у вашому програмному коді. Вони будуть змішуватися з символами, які не бувають цифрами з альфа-чисел, які насправді не є операторами, а більш елементарними елементами граматики мови, які визначають речі, такі як блоки та області застосування, формують заяви управління потоком або позначають деякі мета-речі. Вам потрібно буде поставити окуляри і посунути очі на 10 см ближче до РК-дисплея, щоб зрозуміти, що це зоровий безлад.

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

Прийнятні / заохочені:

class Complex
{
public:
    double r;
    double i;

    Complex operator*(const Compex& rhs)
    {
        Complex result;
        result.r = (r * rhs.r) - (i * rhs.i);
        result.i = (r * rhs.i) + (i * rhs.r);
        return result;
    }
};

Не прийнятний:

class Employee
{
public:
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
    {
        // what the hell do I do here??
    }
};

Окрім сказаного тут, є ще один аргумент проти перевантаження оператора. Дійсно, якщо ви пишете +, це очевидно, що ви маєте на увазі додавання чогось до чогось. Але це не завжди так.

Сам C ++ є чудовим прикладом такого випадку. Як stream << 1слід читати? Потік зміщено вліво на 1? Це зовсім не очевидно, якщо ви прямо не знаєте, що << в C ++ також пише в потік. Однак якби ця операція була реалізована як метод, жоден розумний розробник не писав би o.leftShift(1), це було б щось на зразок o.write(1).

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

На відміну від прописаних методів, оператори коротші, але вони також не потребують дужок. Круглі дужки відносно незручні. І ви повинні їх збалансувати. Загалом для будь-якого виклику методу потрібні три символи звичайного шуму порівняно з оператором. Це робить операторів використання дуже, дуже спокусливими.
Чому б ще хтось цього хотів cout << "Hello world":?

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

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

Причина Оператор Перевантаження страшно, тому , що є велика кількість програмістів , які ніколи б навіть думати , що *зовсім не означає просто «помножити», в той час як метод , як , по foo.multiply(bar)крайней мере відразу ж вказує на той програміст , що хто - то написав спеціальний метод множення . У цей момент вони задумаються, чому і піти розслідувати.

Я працював з "хорошими програмістами", які були на позиціях високого рівня, які створили б методи, звані "Порівняти значення", які брали б два аргументи, і застосовували значення від одного до іншого і повертали булеве значення. Або метод під назвою "LoadTheValues", який би перейшов до бази даних для 3 інших об'єктів, отримав значення, зробив обчислення, змінив thisі збереже його в базі даних.

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

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