Комментарии 4
Очередная статья на эту тему… Только ситхи возводят всё в абсолют. Для одних ситуаций фреймворки хороши, для других — избыточны. Библиотечный подход тоже хорош, но опять же, не для всех случаев.
F# тут, как я понял, только для примера, автор рассуждает про фреймворки и библиотеки в целом.
Далеко не все. Есть микрофреймворки, которые предоставляют ядро и АПИ для расширения функционала. Обычно подключаемый модуль — это какая-то уже готовая библиотека (к фреймворку совсем не относящаяся), плюс обёртка.
Если у фреймворка есть хороший АПИ для расширения. то эта проблема исчезает.
Например, есть Flask. По-сути. это библиотека werkzeug (обработка HTTP-запросов/ответов + URL матчинг) + Jinja2 (шаблонизация) + клей между ними. В нём очень просто. например, заменить шаблонизатор. Или добавить persistence-слой на своё усмотрение (ORM-решения, FS-хранилище, NoSQL БД, и т.д.). Система авторизации? Если надо, можно взять любую готовую, или самому соорудить. Ну и т.д.
Тоже применимо далеко не ко всем. Есть конечно фреймворки, наполненные магией, неявными вещами и т.д. (django, например), но в любом случае. если есть хорошая документация и исходники, фреймворки исследовать довольно просто.
Это зачастую плюс. Конечно, если писать код в одиночку, используя свою организацию кода, то всё хорошо, ты помнишь и понимаешь что и где лежит.
Если фреймворк определяет довольно жёсткую структуру кода, то новичкам проще влиться в новый проект, отпадает необходимость изучать и подстраиваться под структуру очередного проекта. Достаточно изучить сам фреймворк и написать на нём проект, тогда любой новый проект на нём будет по структуре похож на другой. Да и работодателю проще нанимать персонал.
Ну а если хочется гибкости, то можно взять фреймворк с более свободной организацией и в нём использовать свой стиль.
У библиотечного подхода тоже есть минусы:
Это особенно проявляется, если библиотеки пишутся разными людьми. У каждого свой стиль и организация кода. Хороший фреймворк определяет некий общий формат для данных, которыми оперирует, реализует часто используемые алгоритмы, определяет АПИ для замены/расширения себя, что позволяет избежать этих проблем.
Но в любом случае. надо всегда отталкиваться от первоначальной задачи и выбирать тот инструмент, что более соответствует контексту.
F# тут, как я понял, только для примера, автор рассуждает про фреймворки и библиотеки в целом.
Фреймворки не компонуются
Далеко не все. Есть микрофреймворки, которые предоставляют ядро и АПИ для расширения функционала. Обычно подключаемый модуль — это какая-то уже готовая библиотека (к фреймворку совсем не относящаяся), плюс обёртка.
Если у фреймворка есть хороший АПИ для расширения. то эта проблема исчезает.
Например, есть Flask. По-сути. это библиотека werkzeug (обработка HTTP-запросов/ответов + URL матчинг) + Jinja2 (шаблонизация) + клей между ними. В нём очень просто. например, заменить шаблонизатор. Или добавить persistence-слой на своё усмотрение (ORM-решения, FS-хранилище, NoSQL БД, и т.д.). Система авторизации? Если надо, можно взять любую готовую, или самому соорудить. Ну и т.д.
Фреймворки сложно исследовать
Тоже применимо далеко не ко всем. Есть конечно фреймворки, наполненные магией, неявными вещами и т.д. (django, например), но в любом случае. если есть хорошая документация и исходники, фреймворки исследовать довольно просто.
Фреймворки определяют организацию вашего кода
Это зачастую плюс. Конечно, если писать код в одиночку, используя свою организацию кода, то всё хорошо, ты помнишь и понимаешь что и где лежит.
Если фреймворк определяет довольно жёсткую структуру кода, то новичкам проще влиться в новый проект, отпадает необходимость изучать и подстраиваться под структуру очередного проекта. Достаточно изучить сам фреймворк и написать на нём проект, тогда любой новый проект на нём будет по структуре похож на другой. Да и работодателю проще нанимать персонал.
Ну а если хочется гибкости, то можно взять фреймворк с более свободной организацией и в нём использовать свой стиль.
У библиотечного подхода тоже есть минусы:
- Несовместимость данных. Например, одна библиотека представляет цвет как 4-вектор, а другая — как число. В итоге ты должен будешь каждый раз перегонять одно представление в другое, при вызове функций из разных библиотек.
- Дублирование функционала. Например, есть 2 библиотеки для обработки изображений. и каждая включает в себя свою реализацию линейной алгебры.
- Разный порядок передаваемых аргументов, разный стиль именования функций/методов/переменных и т.д.
Это особенно проявляется, если библиотеки пишутся разными людьми. У каждого свой стиль и организация кода. Хороший фреймворк определяет некий общий формат для данных, которыми оперирует, реализует часто используемые алгоритмы, определяет АПИ для замены/расширения себя, что позволяет избежать этих проблем.
Но в любом случае. надо всегда отталкиваться от первоначальной задачи и выбирать тот инструмент, что более соответствует контексту.
> поскольку мы сейчас изучаем потенциал одной книги, в создании которой участвовал этот автор
F# Deep Dives? Я бы сначала перевел отличную “Expert F# 3.0”. Те, кому нужна Deep Dives и так уже купили ее в оригинале, а вот вводный курс был бы полезен.
F# Deep Dives? Я бы сначала перевел отличную “Expert F# 3.0”. Те, кому нужна Deep Dives и так уже купили ее в оригинале, а вот вводный курс был бы полезен.
Нет, вообще-то речь шла о www.amazon.com/Real-World-Functional-Programming-Tomas-Petricek/dp/1933988924. Расскажите нам о достоинствах «Expert F# 3.0»? (лично меня там заинтересовало только участие мистера Сайма, автора F#). В книге «Real World Functional Programming» мне кажется интересным сравнение C# и F#
5 лет прошло, некоторые главы уже не совсем актуальны (например всю главу про асинхронные операции нужно брать из более свежих статей того же автора :)
Expert F# 3.0 останется актуальным настольным талмудом еще очень долго даже в свете выходящего через месяц F# 4, т.к. изменения в ядре языка больше косметические, в отличие от C#, обрастающего сахаром.
Но я еще раз пробегусь по Real-World FP и посмотрю, насколько она еще актуальна идеологически, особенно в свете планируемых изменений в C# 7.0 в сторону функциональщины
Expert F# 3.0 останется актуальным настольным талмудом еще очень долго даже в свете выходящего через месяц F# 4, т.к. изменения в ядре языка больше косметические, в отличие от C#, обрастающего сахаром.
Но я еще раз пробегусь по Real-World FP и посмотрю, насколько она еще актуальна идеологически, особенно в свете планируемых изменений в C# 7.0 в сторону функциональщины
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Библиотечные паттерны: Почему фреймворки — это зло