Наскільки неправильно говорити про "методи" C ++ (проти "членських функцій")?


19

Я розумію, що згідно зі специфікацією C ++ не існує такого поняття, як "метод", і деякі (багато? Більшість?) Програмісти C ++ вважають "метод" Java-ізмом. З іншого боку, навіть на форумі C ++ люди, здається, говорять про методи, не посмикуючись. Я шукаю відомі конвенції або поширені практики щодо цієї термінології.

Я документую API, який має як версії C ++, так і Java. Розробники фактично зберегли імена класів і методів / членів однакові між ними, імовірно, для доцільності перенесення та тестування. Через це частина того, що потрібно задокументувати щодо цих API, сидить "вище" вибору мови; Мені потрібно вміти говорити загалом про Foos і Bars, з їх методами baz () та mumble () ...?

Якщо я кажу про методи, програмісти Java вважатимуть це природним, і, схоже, програмісти на C ++, ймовірно, зрозуміють, але деякі вважають це неправильним. Моє запитання: наскільки це жахливо на практиці ? Як умовно говорять про функції учасників C ++ у загальних контекстах OOP, на відміну від конкретних C ++? Чи є кращий спосіб поговорити про функції учасників таким чином, який не відповідає правилам жодної мови? ("Функції учасника" є трохи дослідними.)

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

Мені відомо це питання , але загалом це стосується ООП і не запитує про конкретні мови.


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

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

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

1
@JimmyHoffa це краще?
Моніка Селліо

3
Просто назвіть їх методами у вашому документі з API міжмовної мови. Ви можете включити фразу в вступний текст на зразок "Щоб спробувати залишатися агностиком мови програмування, ця документація API використовуватиме метод терміна для позначення функцій члена C ++."
Брандін

Відповіді:


11

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


Це я і зробив, і поки що люди, здається, не в порядку з цим. Дякую за пропозицію.
Моніка Селліо

15

Ну, ви не збираєтесь його стратити.

Нарікання у світі С ++ не є педантичною правильністю: це неоднозначність. Існує так багато різних видів "методів" там, в пустелі, залежно від того, про який домен ви говорите, що купа з нас вважає за краще дотримуватися стандартної термінології, щоб пізніше уникнути непорозумінь. Це означає, приблизно, "статичний / [нестатичний] [чистий] віртуальний / [невіртуальний] член / [вільний] функція".

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

Але я впевнений, що є мільйони професійних програмістів на C ++, які самі не мають уявлення, що це навіть річ. Це великий ol 'світ.

Ви не збираєтесь його стратити.


3

Ейфель називає їх звичайними або функціональними можливостями , C ++ називає їх функціями-членами , і (майже) всіма іншими мовами OO, коли-небудь створеними за всю історію обчислень, до і після того, як C ++ називає їх методами , так що останній термін, як правило, слід розуміти навіть Програмісти C ++ (та Ейфеля), якщо вони справді ніколи не чули про Simula, Smalltalk, Self, Objective-C, Newspeak, Java, C #, VB.NET, PHP, Python, Ruby, ECMAScript / JavaScript, Scala, CoffeeScript,…


За винятком суть, що вони часто означають тонко різні речі в цих областях. Ось чому ОП запитує, чи краще дотримуватися конкретної доменної термінології, і чому правильна відповідь - "так" ...
Гонки легкості з Монікою

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

Прототип на основі OOP не має різниці. OOP заснований на уявленні, що об'єкти спілкуються через повідомлення (наприклад, сервери, що надсилають запити один одному), а метод посилається на спосіб (метод), у якому будь-який конкретний об'єкт відповідає на дане повідомлення. Прототип OO має значення лише щодо того, як методи можуть бути успадковані. Що має велику різницю, це OOP на основі слотів (наприклад, Python) і на основі повідомлень (як Ruby), а також чи є у вас запізнення чи рання прив'язка.
saolof
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.