Зараз читаю книгу "Чистий код" і ось вирішив уточнити у розробників з бо льшим досвідом, ніж у мене.
Тут написано, що слід прагнути до написання унарних функцій (які містять один аргумент), а краще щоб і зовсім нічого не брала, щоб було просто красиве ім'я функції, прочитавши яке можна інтуїтивно зрозуміти, що вона робить.
Але, якщо я не помиляюся, це ж суперечить правилам інкапсуляції. Я так розумію, що можна все змінні, які використовує функція визначити як глобальні змінні, але тоді ця функція буде жорстко залежати від класу, в якому знаходиться. І в разі чого перенести її в інший клас буде набагато складніше.
В ідеальному випадку кількість аргументів функції дорівнює нулю (нуль-арная функція). Далі слідують функції з одним аргументом (унарні) і з двома аргументами (бінарні). Функцій з трьома аргументами (тернарних) слід по можливості уникати. Необхідність функцій з бо льшим кількістю аргументів (поліарних) повинна бути підкріплена дуже високими доводами - і все одно такі функції краще не використовувати.
І далі, якщо пару сторінок прочитати, там більш глибоко це описується і все зводиться до суті, що функції повинні бути в ідеалі без аргументів.
Або не так я міркую?
Так що функції з вхідними параметрами це не погано, але слід акуратніше підходити до проектування коду і мінімізувати кількість аргументів.
Не пам'ятаю якщо це відображено в книзі чи ні але уникайте випадків коли всі (кілька) аргументів функції мають один і той же тип. Це часто призводить до помилок.
І ще, глобальні змінні - це зло, про це написано мільйон книжок.
Факт унарна (а точніше навіть сказати, атомарности) функцій і методів - один з тих, до яких майже неможливо прийти в 100% випадків на практиці, але до якого, дійсно, завжди потрібно прагнути.
Суть цієї поради не в тому, щоб всі параметри тупо глобалізувати, а в тому, щоб прийти до хорошого архітектурному рішенню. Тому що якщо функція / метод / процедура / whatever приймає на вхід більше 3-5 параметрів, то це в більшості випадків б'є по якості архітектури і вказує на явні прогалини в ній.
Інкапсуляція. Яка головна мета інкапсуляції? - сформувати хорошу абстракцію, для взаємодії з якої потрібно знати про деталі її реалізації настільки мало, наскільки це можливо (досконало - нічого).
Порівняйте наступні два набори:
Який з наборів, на вашу думку, розкриває деталі реалізації? Правильна відповідь: перший, тому що він вбиває сенс інкапсуляції як такої.
І причина цього - надмірність, яка з'являється в результаті більшого числа аргументів конструктора 1.
Висновок: чим менше параметрів приймає на вхід суб'єкт, тим краще інкапсуляція - параметри розкривають деталі реалізації.
Для більш об'єктивного розуміння принципів проектування функцій / методів /. я б радив вам почитати 7 главу досконалого Кода "Високоякісні методи".
Таке побажання безпосередньо випливає з принципу єдиної обов'язки. Метод, по хорошому, повинен виконувати одну єдину, максимально атомарному, завдання. І я вас запевняю, знайдеться дуже мало таких завдань, для виконання яких знадобиться більше двох параметрів.
Там, де їх знадобиться більше - має сенс подумати про створення об'єкта, що володіє всьому необхідними властивостями / даними і передавати його.
Безглуздий, надуманий приклад, зате відмінно розкриває суть.
Припустимо нам треба збільшувати значення якоїсь змінної на одиницю.
Варіант перший. Передаємо в функцію два параметра і результат присвоюємо змінної
Варіант другий. Передаємо в функцію один аргумент, за допомогою якого змінюємо змінну.
Варіант третій, ідеальний для даної атомарної завдання. Використовуємо функцію взагалі без аргументів.
Від себе можу додати: Пишіть функції так, щоб було максимально легко зрозуміти що вона робить - гарна назва, перше на що потрібно звернути увагу.
Кожна функція повинна виконувати конкретну задачу тільки на одному рівні абстракції - не заважайте всередині низькорівневі обчислення і високорівнева код.
Якщо в неї потрібно передати багато параметрів, простіше зробити клас-аргумент - отримаєте унарна функцію.
В цілому намагайтеся зробити функцію настільки простий, наскільки це можливо. Нагородити тонну коду дуже легко, так само як і заплутатися в ньому, а от вирішити задачу просто набагато складніше.
Так само враховуйте завдання які перед вами стоять. Якщо потрібна максимальна швидкість, то виклик купи функцій всередині інших функцій, може негативно позначитися на продуктивності додатка, особливо на рекурсивних функціях або функціях з довгими ланцюжками викликів.