что обычный ООП-стиль конструирования программ - это наинстанцировать объектов и засовывать их друг в друга. Отсюда высокая сложность чтения ООП-кода собранного на основе интерфейсов - нужно понимать, какая реализация засунута в эту зависимость, какая в эту. Бывают тяжёлые случаи, когда зависимости вычисляются на лету, и простым чтением понять невозможно, приходится код запускать и интроспектить. Рано или поздно ООПшник приходит к мысли, что лучше иметь по одной реализации на интерфейс. Но тогда чем это будет отличаться от чистых не привязанных к контексту функций с хардкодными зависимостями? Ничем. Эликсир-код проще читать чем ООП-лапшу.
А может прийти к композиции
кто/что?
"ООПшник приходит к мысли"
Мощно, красиво
В ООП вообще много "паттернов", потому что языки с этой парадигмой в основе исторически были не очень выразительными. Тот же Dependency Injection в фп часто делается передачей функции или имени модуля без создания новых объектов.
Обсуждают сегодня