Функциональное программирование в ООП из песочницы

Думаю, никто не станет спорить, что хороший код — код, который не только исполняет, но и максимально описывает свою задачу (это, конечно, относится в первую очередь к бизнес-логике). Причем описывает ее не деталями алгоритма, а своей сигнатурой (названием, параметрами и возвращаемым типом), сигнатурой вызываемых методов, переменными, которые он использует. В таком случае тело метода можно прочитать сверху вниз, не удерживая в памяти какой-то дополнительный контекст.

Пример

Давайте рассмотрим следующий класс (тематика несколько необычная, но надеюсь, что это сделает процесс чтения чужого кода менее скучным):

public class Invasion {
	private SearchCriterion _searchCriterion = (new GeniousCriterion()).or(new SexyCriterion());
	private ExperimentProcedure _experimentProcedure = (new MockProcedure()).then(new WatchProcedure());

	private _experience = new Experience();

	private HumanBeing[] _humans;
	private ArrayList<HumanBeing> _chosenOnes;

	public void investigate() {
		updateChosenOnesList();
		experiment();
	}

	private void updateChosenOnesList() {
		_chosenOnes.clear();

		for (HumanBeing human : _humans)
			if (_searchCriterion.satisfied(human))
				_chosenOnes.add(human);
	}

	private void experiment() {
		for (HumanBeing human : _chosenOnes)
			_experience.push(_experimentProcedure.do(human));
	}
}

В котором

Требуется выяснить, что делает метод investigate или убедиться в правильности его логики. При этом не хотелось бы разбираться в коде всех методов, которые он вызывает.
Метод updateChosenOnesList. В данном случае по названию метода можно определить, что его реализация должна обновить поле _chosenOnes. При этом, просмотрев список полей объекта, можно предположить, что искать новеньких будут среди _humans, а для поиска может использоваться критерий _searchCriterion. Однако проверять список полей объекта и прослеживать связь между их названиями и названиями методов не очень удобно. Аналогичная ситуация с методом experiment.

И еще пример

Вот другой вариант реализации этого класса (см. комментарии):

public class Invasion {
	// …..........

	public void investigate() {
		// можно прочитать не задумываясь: ищем счастливчиков среди людей по критерию, добавляем в избранное
		// вместо старого updateChosenOnesList();
		_chosenOnes = search(_searchCriterion, _humans);
		// ставим опыты над избранными, усваиваем собранный опыт
		_experience.push(experiment(_experimentProcedure, _chosenOnes));
	}

	private Experience experiment(ExperimentProcedure procedure, HumanBeing[] humans) {
		Experience exp = new Experience();

		for (HumanBeing human : humans)
			exp.push(procedure.do(human));

		return exp;
	}

	private ArrayList<HumanBeing> search(SearchCriterion criterion, HumanBeing[] humans) {
		ArrayList<HumanBeing> result = new ArrayList<HumanBeing>();

		for (HumanBeing human : humans)
			if (criterion.satisfied(human))
				result.add(human);

		return result;
	}
}

Собственно, это и было применение функционального стиля программирования. Давайте посмотрим, какие плюсы и минусы есть у такого варианта по сравнению с первым.

Плюсы

Их нет, зато есть куча минусов. Шутка.
Во-первых, теперь легче прочитать метод investigate и понять, что он делает, и делает ли он то, что должен, и если делает, то правильно ли. При этом можно не смотреть никуда кроме тела самого метода, в том числе и на список полей.
Во-вторых, теперь приватные методы не зависят от состояния объекта. Получается, что результат их выполнения определяется исключительно передаваемыми параметрами (т. е. при вызове не нужно следить за состоянием всех полей объекта Invasion — видно, какие поля передаются и какие модифицируются). В то же время, те параметры, которые используются в качестве аргументов, были сформированы / инициализированы в теле метода investigate — т.е. виден весь алгоритм и все изменения, которые произошли с состоянием Invasion.

Минусы

Производительность — увы. В тоже время, нет смысла печалиться, если только метод investigate не будет вызываться очень часто.
Надо передавать методам дополнительные параметры — это достаточно критично, если их оказывается много — 4 и больше. С другой стороны, если параметров, от которых зависит метод много, то, возможно, это повод задуматься об изменении архитектуры (обычно — добавлении нового класса, такого как SexyCriterion, который может содержать в себе нужные параметры).

По поводу примера

Вообще говоря, в данном случае не было необходимости в закрытых методах. Достаточно было добавить объектам критерия поиска и процедур возможность целиком обрабатывать коллекцию объектов. Однако здесь были по-максимуму распределены обязанности между разными типами объектов — в первую очередь, с целью сокращения объема кода для примера. Часто бывает, что на построение такой модели либо нет времени, либо нет необходимости (например, когда есть подозрение, что требования могут поменяться и нужно применить наиболее простой вариант решения). В таких случаях функциональный стиль может несколько упростить чтение и поддержку кода, при этом практически не увеличивая время, затраченное на разработку.

Эпилог

Можно писать код, который не содержит методов с большим числом строк (например, больше 10-ти) и при этом не требует приватных методов (такие методы всегда могут быть вынесены в отдельный объект поведения). Однако, процесс построения такого кода не прост.
Поэтому, можно разбить сложный код public метода на несколько private функций-методов, зависящих исключительно от своих параметров, и не модифицирующих состояние объекта. В таком случае, напрямую к состоянию объекта должны обращаться-модифицировать только public методы (не private) — т.е. методы, которые являются частью его интерфейса. Это позволяет свести сложный алгоритм к набору методов, каждый из которых может быть легко прочитан, при условии что переменные, методы и их параметры получили подходящие имена.
И, на всякий случай, если вдруг есть вопросы, где здесь ООП, а где функциональное программирование. ООП — на основе этой парадигмы разбиты обязанности между объектами Invasion, Criterion, Procedure, Experience. Функциональное программирование — с его помощью реализована внутренняя логика Invasion, приватные методы в данном случае являются функциями (они зависят только от входных параметров и не модифицируют состояние объекта Invasion).


Спасибо за внимание! Пожалуйста, пишите в комментах свои мнения, замечания и критику.

Добавлено 09/10/2012, с учетом некоторых комментариев
Пожалуйста, обратите внимание, что речь идет не только о редактировании состояния объекта внутренними (вспомогательными) методами класса, но еще и о том, что эти методы не должны считывать состояние объекта сами (все свои параметры они получают в качестве аргументов).
Естественно, этот принцип не претендует на абсолютность, есть случаи, когда закрытым методам лучше дать возможность обращаться к состоянию класса. В первую очередь, это случай, когда может возникнуть дублирование кода в виде передачи одного и того же набора аргументов функции в разных местах (либо редактирования одного и того же набора полей по результатам выполнения функции). Например, если метод updateChosenOnesList должен вызываться в нескольких местах и ему каждый раз надо передавать одни и те же внутренние поля объекта, то он определенно лучше реализован в первом примере.
Т.е. целью статьи является не указание способа кодирования, а обращение внимания на те плюсы, которые дает использование методов-функций.
Тема возможности редактирования функциями своих аргументов здесь НЕ рассматривалась.