Чи відповідні назви методів "плюс" і "мінус"?


21

Java SE 8 поставляється з новим механізмом дат, введення LocalDate, LocalTimeі LocalDateTimeкласів для подання моментів часу. Для управління такими миттєвостями, набір методів Дано: LocalDate.plusDays(...), LocalDate.minusDays(...)і так далі.

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

Ось чому для мене не звучить правильно називати метод plusDaysзамість sumDays, minusDaysа не subtractDays. Це мене просто дуже дратує? Як ти гадаєш?

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


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

2
Програмування не "англійське". Наприклад, sqrtце лише слово, яке програмісти повинні розпізнати та знати. Англійське слово - до речі, «квадратний корінь». Але називати речі відповідно до природного в англійській мові - це не добре. Візьмемо, наприклад, слово "незаконний", наприклад, прекрасне англійське слово. Однак, якщо хтось назвав їх метод, скажіть, isIllicitя думаю, я хотів би вирвати очні яблука кожного разу, коли я дивився на цей метод дзвінка. Це просто виглядає жахливо, і повинен бути кращий спосіб висловити свою ідею.
Брандін

18
sumв цьому контексті звучить неправильно. Я віддаю перевагу .net's AddDays.
CodesInChaos

3
@LuigiCortese Назви методів вибираються так, щоб вони відповідали загальному впорядкуванню англійських слів. Math.addExact(1, 2)тому що ви говорите "додайте 1 і 2". tomorrow.plusDays(2)тому що ви говорите "завтра плюс 2 дні". Якби addExactчлен Integerякимось чином це був би 1.plusExact(2).
Тавіан Барнс

8
Особисто я б розраховував plusDaysповернути нову дату x кількість днів у майбутнє, тоді як addDaysя міг би мутувати вимкнення оригінального об'єкта. Це тільки я, хоча я не все так добре знайомий з Java.
Ajedi32

Відповіді:


52

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

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

var workdaySchedule = initialSchedule.withoutWeekends();

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

Тепер замість цього уявіть, що він названий:

var workdaySchedule = initialSchedule.removeWeekends();

Це заплутано. Чи змінюється початковий графік? Це, звичайно, звучить так, адже це звучить так, ніби ми знімаємо з нього вихідні дні. Але тоді чому ми привласнюємо її до нової змінної? Хоча ці дві схеми іменування дуже схожі, ця набагато менш чітко свідчить про те, що відбувається. Це було б більш доцільно , якщо removeWeekends дійсно змінити первинний графік, і повернувся void- в цьому випадку withoutWeekendsбуде заплутаним варіантом.


Це по суті декларативне та імперативне розрізнення. Ми заявляємо, що workdayScheduleце конкретна річ, або ми виконуємо перелік імперативних вказівок (наприклад, "видалити"), щоб зробити цю конкретну річ? Зазвичай імперативне іменування має більше сенсу, коли ви мутуєте значення, а декларативне має більше сенсу при незмінних значеннях, як це демонструє вищевказаний приклад.

У вашому випадку у вас точно те саме. Якби я бачив: tomorrow.plusDaysя б не уявляв, що tomorrowце мутують, тоді як tomorrow.addDays, я думаю, це може бути. Це дещо тонко, але не обов'язково погано. Без того, щоб надмірно думати про це, це називання, природно, задає ваше мислення у правильному напрямку з точки зору того, ви мутуєте чи ні. Щоб зробити це відміннішим між цими імперативними та декларативними стилями, ясніше: «додати» (і «видалити») - це дієслова , тоді як «плюс» (і «без») є прийменниками .


13
Я на насправді була проблема з addDaysпроти plusDaysвчорашнього дня! У .NET DateTimeклас має методи, що називаються addDays, addMonthsта addYears. Я створив метод для розбору відносної дати (1 рік, 2 місяці, 3 дні тому) і назвав вищезгадані методи, думаючи, що вони змінюють поточний DateTimeоб'єкт. Кожна дата в базі даних закінчувалася 8 червня 2015 року. "Це смішно", - подумав я. Тоді, коли я згадав, що addDaysне змінює DateTimeоб'єкт, він повертає новий . Тож +1 для цього питання є +1.
Грег Бургхардт

1
@GregBurghardt Як користувач .NET, я маю точно протилежні очікування. Я думаю, це означає лише те, що "плюс" і "додати" є обмінними, а не прямими відображеннями до++=
Agent_L

2
@Agent_L Це цікаво. Конвенції .NET убік, "додати" та "плюс" не є взаємозамінними англійською мовою.
Бен Аронсон

1
Крім того, для дат і часу звичайно говорити про D + 1, H + 12 і так далі посилальний час щодо конкретного походження (також для космічних польотів Т-10, Т-9 тощо). Зазвичай це читається як D-плюс-1, H-plus-12, T-мінус-10. Можливо, США орієнтовані, але саме так мені здається.
Крістіан Н

4
Це старе питання StackOverflow про Джона Скета може здатися цікавим: яке найкраще ім’я для немутуючого методу "додати" для незмінної колекції? .
MicSim

2

У .NET найменування відрізняється, хоча результат точно такий же. Замість:

tomorrow = LocalDateTime.plusDays(1);

існує:

tomorrow = DateTime.Now.AddDays(1);

Це означає лише, що відмінності між розумінням "плюс" та "додати" закінчилися як питання особистої думки. Підбадьорюйте, ви не самотні, принаймні ви можете вибрати мову, яка вам більше подобається:)


-1

Це, мабуть, артефакт Java, який використовується .Methodдля всіх методів, як тих, що модифікують об'єкт, так і тих, які не мають.

Уявіть мову, яка також має object=>methodсинтаксис, який дав methodби копію об'єкта для роботи. Зараз такою мовою startDate=>plusDays(5)явно однозначно. Він бере початкову дату і створює нову дату, яка пізніше 5 днів.

Що стосується спорідненої ноти, тут sumDaysнемає сенсу. LocalDateцей час точка , а не на часі тривалості . Ви можете підсумовувати будь-яку кількість тривалостей (а результат - інша тривалість), і ви можете додати точку часу та тривалість (результат - інший момент часу), але ви не можете підсумовувати часові бали.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.