Багато разів під час написання великих програм я запитував після того, скільки копій і вставляє сенс вводити код у функцію чи метод і що є хорошим правилом? Я використовував велике правило з чотирьох рядків або більше і з’являється більше, ніж удвічі, тоді я роблю просту функцію / метод, що містить цей код. Чи можете ви придумати кращу практику чи запропонувати якісь покажчики? Це скоріше загальне питання дизайнерської схеми, а не мовне питання.
Відповіді:
Я частково використовую функції як спосіб документування коду. Виклик функції зі значущим іменем полегшує розуміння коду. В деяких випадках навіть функція з одним рядком має сенс.
Наприклад, у "Чистому коді" Роберт К. Мартін наводить такий приклад: Який із них ви б краще бачили? Це:
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))
Або це?
if (employee.isEligibleForFullBenefits())
Я не завжди з ним погоджуюся, але в цьому випадку роблю. Код повинен бути читабельним не тільки тоді, коли ви пишете його і знаєте кожну деталь, але і о 21:00, коли вам доведеться виправляти помилки в чужому коді. Не дивитися на тривалий стан і намагатися розібратися у всіх подвійних негативах не рекомендується. Якщо ви можете просто поставити ім’я на ньому (не тільки умови, але і кожен фрагмент коду, який ви пишете), це стає набагато простіше.
Я ніколи не пошкодував про те, що поставив якусь функцію, і якщо ви переживаєте за продуктивність, то спочатку профілі.
Поширене непорозуміння, що виклики функцій повинні здійснюватися лише для уникнення повторюваних сегментів коду. Моє правило - будь-яка логічна одиниця роботи повинна бути перетворена на функцію, навіть коли вона використовується лише в одному місці. Зазвичай це призводить до кращої читабельності та дозволяє писати код самодокументування, де назви функцій замінюють коментарі, і вам не потрібно писати додаткові коментарі, пояснюючи, що ви робите.
Якщо він використовується в більш ніж одному місці, і
потім зробіть це функцією або методом. На мій досвід, довгі фрагменти повторного коду, природно, потрапляють до однієї з цих категорій (як правило, першої, але потім категорії сильно перетинаються;). Звичайно, все, що має бути в інтерфейсі, також є функцією / методом.
float x, int yі double density, то налаштування цих обчислень як функції C може бути складнішим, ніж просто повторення коду, оскільки вам доведеться розробити спосіб виведення всіх трьох значень. Якщо самі повторні обчислення є тривіальними, іноді краще просто залишити їх в рядку.
Майже завжди, особливо якщо кожен дублікат представляє одну й ту ж операцію з концептуальної точки зору. Якщо воно виконується однаково, але на різних типах, зробіть загальну реалізацію.
Єдина причина, яку я не можу придумати, - це одне із технічного обслуговування: іноді може бути зручніше уникати створення залежності між окремими речами, навіть ціною певного дублювання.
Пошук " рефакторингу " приведе вас до багатьох ресурсів для "кращих практик" для цього дуже поширеного процесу. Дещо відома стаття " Раз і тільки один раз" - це чудова історична довідка, що пояснює, що деякі вважають "найкращими методами" для проблем, викликаних вашим запитанням. Крім того, ще більш загальна концепція відома як " Не повторюй себе" (DRY) . По-справжньому поглиблений набір відповідей на ваше запитання читайте чудову класику Мартіна Фаулера « Рефакторинг: вдосконалення дизайну існуючого коду» , яка охоплює деякі найвідоміші поради щодо рефакторингу , які ви інтуїтивно намагаєтеся виконати. !
Це залежить від характеру згуртованості повторного коду. Якщо повторний розділ коду виконує певну функцію, то він є чудовим кандидатом для перетворення в метод, частково через принцип DRY , частково тому, що якщо функцію потрібно оптимізувати або виправити, то є лише один розділ коду для вирішення.
Якщо асоціація збігається, код краще повторити, а не перетворити його на метод. Якщо вам потрібно додати щось до середини однієї з кодових послідовностей, щоб задовольнити одне із застосувань цього фрагмента, якщо воно є в методі, внесені вами зміни можуть вплинути на інші способи використання цього методу.
Дивіться статтю у Вікіпедії про концепцію згуртованості коду .
Ви повинні розрізняти функції в сенсі структурованого програмування та методи класу.
У вашому прикладі те, що ви показали - це метод a як такий, не повинен кодуватися в рядку.
можливо, вам доведеться перевірити рядок, щоб побачити, чи є це число чи ні, в цьому випадку ви використовуєте функцію і застосовується більшість попередніх відповідей.
Ця відмінність важлива особливо у великих проектах.
Наскільки ви можете, прагніть відокремити бізнес-правила (тобто методи) від обчислювальних алгоритмів (це чисті функції програмування).