Когда абстракция и модульность являются плохой практикой в ​​программировании?

Question

только что увидел этот комментарий в опросе "какую JS lib вы используете"

"@ Xanti - да, да, модульность и абстракция в программировании - ужасная практика. Функции, которые вызывают другие функции? Бесполезно."

И это меня заинтересовало, потому что я использую фреймворк Kohana для PHP и библиотеку Jquery для javascript.

Почему некоторые люди считают абстракцию и модульность плохими практиками? Разве фреймворки и библиотеки не созданы для того, чтобы облегчить и ускорить разработку?

вот ссылка на опрос

Answer 1

Я обнаружил, что слишком большая абстракция может быть опасна для вашей производительности:

• Плохо выбранная абстракция может быть хуже, чем вообще никакой абстракции.

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

• Если абстракция не соответствует относительно знакомой идее, новым членам команды может быть трудно учиться.

Абстракция не является "бездумным благом"; он существует для определенных целей. Среди наиболее распространенных целей

• Для защиты инвариантов структуры данных

• К инкапсулируют проектные решения, которые могут измениться

Мой самый большой опыт работы с абстракцией был с нашим исследовательским компилятором для C - . Было намного больше абстракций, чем студенты привыкли видеть в классе компиляторов:

• Целевая машина была абстрактной
• Язык ассемблера был абстрактным
• Соглашения о вызовах были абстрактными
• Компоновка стека-фрейм использует необычную "блочную" абстракцию

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

Answer 2

При работе на ограниченных ресурсах это может легко добавить издержки.

Конечно, есть вещи, которые компилятор будет оптимизировать, но если вы создадите четыре аккуратных объекта в четырех аккуратных .c-файлах, скомпилируйте их в четыре аккуратных .so-файла, а затем свяжите их с тупым компоновщиком, вызовом кросс-модульных функций, быть легко встроенными, все еще создаются с полным дампом состояния, части, которые могут быть полностью оптимизированы, все еще выполняются и т. д.

Уверяю вас, если вы начнете программировать 8-битный микроконтроллер PIC с 4K RAM и 16K Flash, используя лучшие практики объектно-ориентированных языков, используя передовые шаблоны проектирования и создавая более одного уровня абстракции, ваша программа никогда не запустится. «Преждевременная оптимизация - корень всего зла», - сказал парень, который никогда не программировал на платформу с 128 байтами оперативной памяти.

Answer 3

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

Answer 4

Абстракция и модульность в целом хороши и необходимы. Там могут быть плохие абстракции, например: фреймворки, которые больше не поддерживаются, не стоят дорого, или просто не используются, или большие, или устаревшие, или второй выбор, и так далее. Библиотека "Маркет" вообще огромна. Какие библиотеки вы используете, зависит от обстоятельств и личных предпочтений.

Почему некоторые люди считают абстракцию и модульность плохими практиками? Не являются рамками и библиотеки сделаны для облегчения и ускорения разработки?

Перемены и обучение иногда трудно - поэтому люди борются с этим. Если вы хотите изучать этот вид, вы можете начать свое исследование по адресу: http://thedailywtf.com/ :-) Я бы просто проигнорировал их и использовал библиотеки и фреймворки, поскольку они служат вам и улучшают жизнь вашего программиста.

Answer 5

Мы, вероятно, можем предположить, что комментатор не был серьезным.

Я не могу представить, чтобы кто-то утверждал, что модульность и абстракция - это плохая практика, и на самом деле это имеет значение.

Answer 6

Часто используются хорошие абстракции

Хорошие абстракции упоминаются в 2 или более местах вашего программного обеспечения.

Примеры:

• Функции с 2+ сайтами вызовов.
• Абстрактный класс с 2+ конкретными классами.
• Интерфейсы с 2+ реализациями.
• Обобщения с 2+ экземплярами
• Библиотеки с 2+ пользователями.
• и т.д.

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

Но если у вас много абстракций, на которые ссылаются только один раз, тогда Это хороший шанс, что абстракция не нужна.

Некоторые примеры появления ненужных абстракций:

• Написание объектного счастливого кода (интерфейсы и абстрактные классы везде имеют только 1 реализацию или конкретизацию). Эти интерфейсы и абстрактные классы не нужны (на этом этапе разработки). Принцип ЯГНИ.
• Кто-то строит «блестящий новый» интерфейс на старом, где новые функции после некоторого преобразования вызывают только старый интерфейс. Вы можете себе представить, какой большой беспорядок в результате, если вы повторите это несколько раз. В этом случае старые функции будут иметь единый сайт вызова, поэтому они не нужны. Вам нужно переместить код из старых функций в новую или не писать новую и модифицировать старую.

Некоторые примеры действительно хороших абстракций:

• Уровень аппаратной абстракции: предоставляет единый интерфейс для приложений, поэтому им не нужно разрабатывать код для каждого типа оборудования.
• Файловая система: Неважно, используете ли вы FAT, NTFS, EXT3. Он позволяет вам использовать файлы и каталоги, а драйвер файловой системы сделает все остальное.
• Язык C: вам не нужно портировать вашу программу для каждой архитектуры ЦП. Просто скомпилируйте это.

Итак, чтобы ответить на ваш вопрос прагматично: Абстракции плохие, когда на них ссылаются менее чем из 2 мест .

Что касается модульности, то она субъективна: вы можете организовать свой код как угодно. Если исходный код вашей библиотеки находится в одном исходном файле, это не делает его хуже, чем если бы вы поместили его в несколько сотен файлов.

Оценивая свои абстракции как хорошие или плохие, всегда учитывайте общую картину: весь проект, всю линейку продуктов и т. Д.

Answer 7

Некоторое время назад было тихо, но руководство для компилятора Фортрана рекомендовало выбирать идентификаторы в виде строк одинаковой длины и случайно выбранных букв.

Объяснение? ну, это позволяет равномерно распределять имена во внутренней хэш-таблице компилятора и, следовательно, обеспечивает более быструю компиляцию.

Я думаю, что цитируемый вами текст относится к этой рекомендации

Answer 8

Когда каждая функция (и вспомогательные функции) находится в своем собственном модуле?