Как стать автором
Обновить

Комментарии 10

Спасибо, забрал себе в копилку выброс исключения для аргумента функции. Интересное решение, не знал о нем. Обычно в самом коде проверял.
//Вернём дерево юзеров(объкт) или массив айдишников(тоже объект) в зависимости от флага withContactInfo

Спроектируем кривую функцию, а потом героически будем решать несуществующие проблемы!


А если серьезно, то этому подходу 100 лет в обед, а что кто-то насмотрелся на реакт и решил так лепить везде — сомнительное решение. По большому счету можно согласиться только с простотой расширения функции, остальное — в код так же придется лезть чтобы понять теперь не аргументы по порядку, а по названию. Ну и intellsense уже придумали.


Кроме того, ничего не мешает бросать исключения таким же образом и с обычными аргументами, а еще лучше использовать ts.


Недостатков, с другой стороны, в таком подходе немного, разве что очень маленький оверхед на создание объекта и все такое, который еще и не в стеке лежать будет, но с мира по нитке и вот у нас уже даже с простенькой веб страничкой не справляется компьютер, который выдает игры с 4к в 60 fps в которых одновременно рисуются миллионы объектов.


А главное — зачем два подхода объединять в один паттерн? Чтобы красивее звучало? Хорошо если функция принимает много аргументов, их можно передать объектом, но если она возвращает число, все, паттерн больше не подходит?


Функции в JS могут возвращать только одно значение, поэтому для передачи большего объёма информации можно использовать объект.

Еще можно использовать массив и возвращать кортеджи таким образом. И вообще это очевидно и истинна для большинства ЯП.


Также данный подход упрощает композицию функций. Ведь при композиции функции должны принимать лишь по одному параметру. Паттерн RORO придерживается этого же контракта.

Ага, только кто будет согласовывать входы-выходы функций, сколько бы там параметров не было. В общем, притянуто за уши.


Ну а лебединая фабрика...


Бил считает. что в некоторых ситуациях этот паттерн может заменить привычные нам ES6 классы.

Классы призваны заменить этой паттерн, который в моем джуниорстве назывался "модуль" (от добавки freeze ничего не меняется, фактически). Неожиданно его оживлять в конце 2019 года и считать будущим.

Знаете, я не считаю, что нужно кого-то к чему-то приучать или отучивать… Просто вижу, что у молодых специалистов, с которыми случается общаться, кругозор ограничен набором кейсов. Мои статьи призваны не дать готовый инструмент, а в каких-то случаях дать понимание или продемонстрировать разные взгляды.

Обратите внимание, я в статьях разбираю концепции ООП с точки зрения спецификации экмаскрипт, разбираю базовые концепции экмаскрипт под капотом и т.д… Я не пишу туториалы в стиле: делайте так и будет вам счастье.
Морозильная фабрика — имхо, что-то из серии «хороший программист на Java может написать программу на Java на любом языке». В JS традиционно всё определяется соглашениями. Кто переопределяет методы инстансов, тот сам себе злобный буратино.

Объект как параметр с деструктуризацией — да, это чертовски удобно. Насчёт такого способа обозначать required-параметры — не знаю, пока не определился для себя, это скорее грязный хак или полезный хак.
НЛО прилетело и опубликовало эту надпись здесь
Знаете, я не считаю, что нужно кого-то к чему-то приучать или отучивать… Просто вижу, что у молодых специалистов, с которыми случается общаться, кругозор ограничен набором кейсов. Мои статьи призваны не дать готовый инструмент, а в каких-то случаях дать понимание или продемонстрировать разные взгляды.

Обратите внимание, я в статьях разбираю концепции ООП с точки зрения спецификации экмаскрипт, разбираю базовые концепции экмаскрипт под капотом и т.д… Я не пишу туториалы в стиле: делайте так и будет вам счастье.
НЛО прилетело и опубликовало эту надпись здесь
Знаете, я не считаю, что нужно кого-то к чему-то приучать или отучивать… Просто вижу, что у молодых специалистов, с которыми случается общаться, кругозор ограничен набором кейсов. Мои статьи призваны не дать готовый инструмент, а в каких-то случаях дать понимание или продемонстрировать разные взгляды.

Обратите внимание, я в статьях разбираю концепции ООП с точки зрения спецификации экмаскрипт, разбираю базовые концепции экмаскрипт под капотом и т.д… Я не пишу туториалы в стиле: делайте так и будет вам счастье.
Вы можете написать свою реализацию. Я просто показал концепции.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.