странно что он это делает на уровне модели (но ладно), да так еще конкретную реализацию пихает, а не абстракцию, и почему именно pdf, короче, создал бы абструкцию (стратегию какую нибудь хотя б), создал реализции pdf excel ect, и конвертил бы хорошо]
хотя там ToPdfs, в аргуметах, а потом new ToPdf, мжет опечатка))
а) преждевременная оптимизация б) fizz buzz enterprise edition в) KISS
Какой кисс, кисс жопу Тейлора? Камон, не надо бросаться терминологией, которая не оправдывает то говно, что делает Тейлор. Все эти солиды, киссы, драи и прочее не взаимоисключающие практики, а совместные: это значит, что кисс не говорит, что надо попрать SRP и Open/Close, напротив, почти всегда, когда у тебя получается соблюдать SRP и O/C, то у тебя получается делать и KISS. По твоей же логике получается, что любой джун, который шлепает весь код в одном файле или, прости господи, классе, соблюдает Kiss.
я против любого вида экстремизма. если всё делать "по книжкам", то почему-то это сразу приводит к п. б) — т.е. перегруженному всякой лишней фигнёй коду. считаю это юношеским максимализмом, желанием "сразу сделать хорошо", хотя этого здесь и сейчас(!) не требуется. если уж возводить что-либо в абсолют, то я бы голосовал за DRY. этот принцип никогда меня не подводил — за много лет в программировании наверное даже ни разу. это значит, что если у тебя один код выполняется в одном только месте, то насрать на то, толстая у тебя модель или нет, есть абстракция или нет. ты знаешь как правильно, и пойдёшь по правильному пути, когда это понадобится, но не раннее. в данном случае, если нужен только отчёт ПДФ, то, ради бога, делай как получается. понадобится потом эксель, ты знаешь как надо сделать правильно (ты читал умные книжки!), и только тогда начнёшь рефакторить, вводя уровни абстракции и т.п.
А ты в курсе, что речь про фреймворк, а не твой собственный проект? Никакого "потом" у мейнтейнеров фреймворков нет. Ты должен здесь и сейчас сделать нормально. Это тебе не пет проект, который потом можно отрефакторить. Нельзя. У тебя есть BC и ответственность перед пользователями.
а основная идея Тейлора, насколько я её вижу, это всего лишь "достичь нужного результата с минимально возможным пользовательским кодом". вкатившись в ларавель после Zend Framework'а, где постоянно приходилось делать "восход и закат солнца вручную", я его оч хорошо понимаю =) моя единственная претензия к ларке — это слишком толстый бутстрап. в остальном — вполне себе ок, потому что позволяет решать любого уровня задачи, не стесняя тебя практически ни в чём.
именно! фреймворк должен предоставлять кучку "магии", т.е., грубо говоря, одной строкой выполнить базовую стандартную функцию, но и в то же время должен предоставить возможность достаточно просто tweak'ать любое место в потрохах, чтобы юзер (который программер) мог адаптировать фукнционал под свои нужды, если вдруг ему "захотелось странного".
> почему-то это сразу приводит к п. б) — т.е. перегруженному всякой лишней фигнёй коду Почему-то перегруженный всякой фигней код как раз у ларавеля. Зачем вообще такая фича как "генерация пдф" во фреймворке? Есть этому разумное объяснение? Всем проектам нужна генерация пдф? Мне, например, такая фича не нужна. Тебе нужна? Полагаю, нет. Тогда зачем это тащить во фреймворк? Генерация отчета – это функционал сбоку, где каждый разработчик волен выбрать себе любую либу и прикрутить. С теми усилиями, с которыми фичи делает Тейлор, там не то что пользы не будет, но и вреда добавится. Наверняка под конец вытащит это все в еще один трейт HasPdf/CanBeGeneratedAsPdf.
а ВС здесь, кстати, вполне норм: при переходе с пятёры на семёру, пришлось только Translator потрогать, и вроде как всё =)
чо-т я из его твита не понял, что он "втащил" ПДФ во фреймворк. насколько я вижу, он просто показал паттерн, когда вызов метода "проталкивается" через модель вглубь на специализированный класс
> я против любого вида экстремизма. если всё делать "по книжкам", то почему-то это сразу приводит к п. б) — т.е. перегруженному всякой лишней фигнёй коду. считаю это юношеским максимализмом, желанием "сразу сделать хорошо", хотя этого здесь и сейчас(!) не требуется. Смотря, какие книги читать. Мне, к счастью, ни разу не попадалась книга, где говорили бы, что надо перегружать код абстракциями, нужно делать больше фичей, чем нужно. Почему-то я читал про DRY, KISS, YAGNI и SOLID, где код выглядел совсем иначе. Он простой, он делает только то, что очевидно из названия. Его легко конфигурировать. У него мало входящих зависимостей. Более того, он позволяет тебе выбрать любой драйвер, если речь про бд, генерацию, сессии, поставив всего лишь нужный пакет. Так что хз какие книги читал ты.
Да, возможно. Читал ночью, только проснувшись, показалось, что это его новая киллер-фича.
да все те же книжки я тоже читал, а с некоторыми их авторами и в интернетах общался =) всё хорошо и красиво на бумаге, но потом приходит злой дядька опыт и намекает, что все эти Аффтары хорошо если за свою жизнь пару проектов выкатили в продакшен (обычно и того нет) и поддерживали потом несколько лет =) и выходит, что вся та мнимая чистота и простота кода получается лишь за счёт того, что ты просто спрятал "некрасивое" за кучей абстракций и паттернов. оно никуда не делось, оно там есть, просто ты сам не хочешь его видеть. но код уже сложный — чтобы понять, что делает $this->сделатьКрасиво(), надо погружаться в глубины абстракций, десятка файлов, лишних экранов boilerplate-кода. и, давай признаем, что не меняем мы СУБД на проекте каждую неделю! что если делаешь на Постгресе всё, то у тебя все SELECT-ы оптимизированы на него, и на мускуле оно уже по определению не пойдёт. что проект скорее перепишется с нуля, чем будет мигрировать куда-то там "вмонгубля!" =) все эти абстракции и паттерны нужны когда функционал уже сложный. но если у тебя одна только стратегия, то и паттерн Стратегии ещё рано вводить. лучше сделать всё прямолинейно и просто, а вот когда появится вторая стратегия, ты уже знаешь, в какую сторону ты быстро всё отрефакторишь, потому что читал правильные книжки =)
Обсуждают сегодня