Когда абстракция и модуляризация являются плохой практикой в программировании?
просто видел этот комментарий в, "какой lib JS делают Вы используете" опрос
"@Xanti - да, да, модуляризация и абстракция в программировании является ужасной практикой. Функции, которые вызывают другие функции? Расточительный".
И это оставило меня любопытным, потому что я использую платформу Kohana для библиотеки PHP и Jquery для JavaScript.
Почему некоторые люди считают абстракцию и модуляризацию плохими методами? Разве платформы и библиотеки не сделаны упростить и ускорить разработку?
вот ссылка на опрос
7 ответов
Я обнаружил, что слишком много абстракции может быть опасно для вашей производительности:
Плохо выбранная абстракция может быть хуже, чем никакая абстракция вообще.
Если вам нужно прочитать четыре или пять разных модулей, чтобы понять, как работает простой алгоритм, то барьеры абстракции, вероятно, не в нужных местах. Может быть, есть хороший способ рефакторинга кода, а может быть проще просто устранить препятствия.
Если абстракция не соответствует относительно знакомой идее, новым членам команды может быть трудно учиться.
Абстракция - это не «бессмысленное благо»; он существует для определенных целей. Среди наиболее распространенных целей
защита инвариантов структуры данных
инкапсуляция проектных решений, которые могут измениться
Мой самый большой опыт с абстракцией мешает был с нашим исследовательским компилятором для C - .В классе компилятора было гораздо больше абстракции, чем студенты привыкли видеть:
- Целевая машина была абстрактной
- Язык ассемблера был абстрактным
- Соглашения о вызовах были абстрактными
- Используемая структура стека-фрейма необычная «блочная» абстракция
Каждая из этих абстракций служила важной цели для нашего исследования, но общий эффект заключался в том, что новичкам было очень трудно изучить компилятор. Таким образом, даже если исходный комментарий был шутливым, существуют места, где абстракция может вызвать проблемы.
Абстракция и модуляризация в целом полезны и необходимы. Там могут быть плохие абстракции, например: фреймворки, которые больше не поддерживаются, или дорогие, или просто непригодные для использования, или большие, или устаревшие, или второй вариант и так далее. Библиотечный «рынок» вообще огромен. Какие библиотеки вы используете, зависит от обстоятельств и личных предпочтений.
Почему некоторые люди считают абстракцию и модуляризацию плохими практиками? Разве фреймворки и библиотеки не созданы для облегчения и ускорения разработки?
Изменения и обучение иногда бывает трудным, поэтому люди борются с этим. Если вам нравится изучать этот вид, вы можете начать свое исследование по адресу: http://thedailywtf.com/ :-) Я бы просто проигнорировал их и использовал библиотеки и фреймворки, поскольку они служат вам и делают вашего программиста жизнь лучше.
Разработчик будет утверждать, что абстракция или модуляризация - плохая практика, когда они могут или обязаны взаимодействовать с указанной абстракцией или модуляризацией и не могут понять ее цель или дизайн.
Некоторое время назад было тихо, но руководство для компилятора fortran рекомендовало выбирать идентификаторы в виде строк одинаковой длины и случайно выбранных букв.
Объяснение? что ж, это позволяет равномерно распределить имена во внутренней хэш-таблице компилятора и, следовательно, обеспечивает более быструю компиляцию.
Я думаю, что цитируемый вами текст относится к этой рекомендации
Когда каждая функция (и вспомогательные функции) находится в своем собственном модуле?
При работе с ограниченными ресурсами это может легко добавить накладные расходы.
Конечно, есть вещи, которые компилятор оптимизирует, но если вы создадите четыре аккуратных объекта в четырех аккуратных файлах .c, скомпилируете их в четыре аккуратных файла .so, а затем свяжете их с помощью немого компоновщика, вызовы кросс-модульных функций, которые могут быть легко встроенными, по-прежнему создаются с полным дампом состояния, части, которые можно полностью оптимизировать, по-прежнему выполняются и т. д.
Уверяю вас, если вы начнете программировать 8-битный микроконтроллер PIC с 4 КБ ОЗУ и 16 КБ флэш-памяти, используя лучшие практики объектно-ориентированных языков, используя расширенные шаблоны проектирования и создавая более одного уровня абстракции, ваша программа никогда не запустится. «Преждевременная оптимизация - корень всех зол», - сказал парень, который никогда не программировал для платформы со 128 байтами ОЗУ.
Мы, вероятно, можем предположить, что комментатор не был серьезным.
Я не могу себе представить, чтобы кто-то утверждал, что модуляризация и абстракция - плохая практика и на самом деле имеет в виду это.