Здравствуйте, IncremenTop, Вы писали:

ST>> здравый смысл говорит, что чистая функция будет проще с точки зрения всех сложностей, поскольку все, что идет на вход и является результатом является очевидным!

IT>С точки зрения сложности, то функция в которой или для которой создается объект и работающая с ним без интерфейса — это ад и израиль. Это не гибко, не читаемо, трудно поддерживается.

Хм... Я понимаю, что мы здесь теряем контекст рассуждения, но все небезызвестные ОО товарищи (Мейер, Фаулер, Эванс, Сииман) считают, что вводить интерфейсы и полиморфное поведение нужно лишь тогда, когда это требуется. К тому же, "гибко" и "трудно поддерживается" всегда идут рука об руку; за гибкость всегда нужно платить сложностью, без этого ни как (см. Who Needs an Architect Файлера в качестве примера рассуждения на эту тему).

Очень интересно, что отсутствие побочных эффектов рьяно популяризируется сторонниками ФП мира, но как-то многие забывают, что ключевые гуру ОО мира придерживаются этой же стратегии. Во-первых, существует небезызвестный в мире DDD принцип разделения команд и запросов (a.k.a. command query separation principle), предложенный все тем же Мейером, суть которого состоит в том, что мы должны четко разделять команды и запросы, при этом последние не должны менять состояние не в коем случае.

Еще, не менее интересным моментом является то, что Эрик Эванс, ключевой популяризатор DDD считает Side-Effect Free Function основой борьбы со сложностью и основой Model-Driven Design. Вот что он пишет по этому поводу:

Obviously, you can't avoid commands in most software systems, but the problem can be mitigated in two ways. First, you can keep the commands and queries strictly segregated in different operations.... Second, there are often alternative models and designs that do not call for an existing object to be modified at all. Instead a new VALUE OBJECT, representing the result of the computation, is created and returned. This is a common technique ... A VALUE OBJECT can be created in answer to a query, handed off, and forgotten — unlike an ENTITY, whose life cycle is carefully regulated.
... Therefore:
[b]Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects. ... Further control side effects by moving complex logic into VALUE OBJECTS when a concept fitting the responsibility presents itself.

При этом Эванс прав, практически всегда этот "другой дизайн" найти можно и заменить код с горой интерфейсов, а значит и необъятным состоянием в набор VALUE OBJECT-ов и статических функций без побочных эффектов.

Как раз такой пример я разбирал в статье: Тестируемый дизайн vs. Хороший дизайн и именно такому подходу я следую в реальных проектах.


ST>>(да, другой вопрос, что чистые функции не всегда возможны, но где возможны, это лучший инструмент).
IT>Вы про промышленный код или про гномиков?
В каком-то обсуждении я уже упоминал о том, что отсутствие побочных эффектов является одним из фундаментальных основ довольно известной нынче парадигмы программирования, с помощью которой уже построены сотни и тысячи систем и которая оставила неизгладимый след на дизайн довольно известных .NET библиотек, таких как LINQ или Rx, а также является ключевой характеристикой дизайна Розлина. Так что я точно про промышленный код