Гранулярность смешивания парадигм

Question

При использовании языка с несколькими парадигмами, такого как Python, C ++, D или Ruby, сколько вы смешиваете парадигмы в одном приложении? В пределах одного модуля? Считаете ли вы, что смешивание функциональной, процедурной и ОО-парадигм с высокой степенью детализации приводит к более ясному и краткому коду, потому что вы используете правильный инструмент для каждой подзадачи, или противоречивый беспорядок, потому что вы делаете подобные вещи 3 разными способами?

Answer 1

Я не уверен, что когда-либо думал об этом так.

Как только вы начинаете "мыслить на Ruby", мультипарадигмы просто сливаются в ... ну, Ruby.

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

Answer 2

Разные парадигмы смешиваются по-разному. Например, использование ООП не исключает использование подпрограмм и процедурного кода из внешней библиотеки. Это просто перемещает процедуры в другое место.

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

Answer 3

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

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

Answer 4

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

Для C ++ я обнаружил, что статически типизированный ООП (используйте zope.interface в Python) хорошо работает для деталей более высокого уровня (подключение, обновление, сигнализация и т. Д.), А функциональные вещи решают многие проблемы более низкого уровня (анализ обработка данных ореха и т.д.)

И, как правило, система сценариев с динамической типизацией хороша для выбора и настройки конкретного приложения, уровня игры и так далее. Это может быть сам язык (например, Python) или что-то еще (движок сценариев xml + необходимая система для динамических ссылок в C ++).