Що таке вихідний аргумент, про який йдеться у чистому кодексі Мартіна?

На сторінці 45 чистого кодексу Роберта К. Мартіна: Підручник з гнучкої майстерності програмного забезпечення, Мартін пише, що слід уникати аргументів виводу. У мене виникають проблеми з розумінням значення "вихідних аргументів" і чому їх слід уникати.

Приклад Мартіна для вихідного аргументу appendFooter(s);називає функцію public void appendFooter(StringBuffer report). Його поліпшення коду єreport.appendFooter();

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

Чи вважалася б така функція прикладом нечистого коду за вищезазначеним принципом?

int[] numberArray = {3, 5, 7, 1};
sortArray(numberArray);

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

ObjectWithArrayField numberArray = new ObjectWithArrayField(3, 5, 7, 1);
numberArray.sort();

Боб Мартін просто говорить про читабельність .

Проблема з appendFooterприкладом полягає в тому, що якщо ви знайдете рядок коду appendFooter(s)десь у програмі, це не відразу очевидно, якщо цей виклик приймається sяк вхідний і додає його кудись, або якщо sпросто передається для отримання результату цієї функції. Для впевненості потрібно перевірити документацію функції. Однак такий дзвінок report.appendFooter()дозволяє уникнути цієї проблеми: набагато очевидніше зараз те, що відбувається.

Зауважте, проте Боб Мартін не каже, що "ніколи не використовуйте вихідні аргументи", він каже: "загалом, вам слід цього уникати, оскільки це допоможе вам зберегти свій код трохи більш чистим". Отже, це не вантажне культове правило, яке слід сліпо слідувати.

Sortметоди для стандартних масивів і колекцій трохи відрізняються. Наявність sortметоду член-функції кожного стандартного типу даних масиву мала б кілька недоліків з точки зору дизайнера мови, наприклад, такий метод, як Array.sortдозволяє зберігати це в стандартній бібліотеці, поза межами виконання Java. Але якщо ви створили індивідуальний тип колекції, який доводиться іноді сортувати, додавання sortв якості функції члена може бути справді кращою ідеєю, ніж переведення його в окремий клас.

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

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

Єдиним винятком є ​​дуже загальні алгоритми. Наприклад, алгоритм сортування може бути справедливо відокремлений від контейнерів, які він сортує, якщо він може бути застосований до будь-якого типу контейнерів за допомогою його загальнодоступного інтерфейсу. Функція одного удару appendFooterне має цього виправдання.