Кратко: одна и та же задача $подсчётуникальныхсловвтексте$ решается по‑разному в разных парадигмах — меняются способ выражения алгоритма, разделение на компоненты, манипуляция состоянием и способ рассуждения о корректности. Ниже — иллюстрация и разбор по парадигмам.

1) Процедурный стиль

Идея: пошаговая последовательность действий, явные изменения состояния $переменные,массивы/словари$.Пример $Python‑псевдо$:
text = "Hello, world! Hello."
words = tokenize$text$ # нормализация, разделение
counts = {}
for w in words:
counts$$w$$ = counts.get$w,0$ + 1
unique_count = len$counts$Характеристики:
Читаемость: очень понятен для простых задач — «что делать шаг за шагом».Тестируемость: функции/процедуры легко тестировать по вход/выходу, но глобальное состояние снижает удобство.Производительность: обычно эффективен $in‑placeобновления,O(n)посимволам/словам$. Низкая абстракция — прямой контроль ресурсов.Минусы: при росте кода плохо масштабируется; склонность к дублированию; сложнее поддерживать сложные зависимости.

2) Объектно‑ориентированный $ООП$

Идея: инкапсулировать данные и поведение в объектах; состояние хранится в полях, методы манипулируют им.Пример $Python‑псевдо$:
class WordCounter:
def init$self$:
self.counts = {}
def process_text$self,text$:
for w in tokenize$text$:
self.counts$$w$$ = self.counts.get$w,0$ + 1
def unique_count$self$:
return len$self.counts$Характеристики:
Читаемость: хорошо для моделирования предметной области; может быть многословным для простых задач.Тестируемость: методы можно тестировать отдельно; инкапсуляция упрощает мокирование зависимостей, но наличие внутреннего состояния требует аккуратности $сброссостояниямеждутестами$.Производительность: сопоставима с процедурным, но есть накладные расходы $методныевызовы,обёртки$.Плюсы: расширяемость $наследование/композиция$, удобство для больших систем. Минусы: избыточность для тривиальных сценариев, возможное нарушение SRP $одинклассделаетмноговещей$.

3) Функциональный стиль

Идея: строить решение из чистых функций, избегая побочных эффектов и изменяемого состояния; использовать композицию, высшие функции, неизменяемые структуры.Пример $Python‑вфункциональномдухе$:
words = map$normalize,tokenize(text)$ words = filter(lambda w: w != "", words)
unique = set$words$ # pure combinator; или collections.Counter для частот
unique_count = len$unique$ $вчисто‑функц.языкахможнописатьчерезfold/reduceиличерезкомпозицию$Характеристики:
Читаемость: при знакомстве с функциональными приёмами — очень выразительно и компактно; для тех, кто не знаком — может быть менее очевидно.Тестируемость: отличная — чистые функции легко юнит‑тестировать, свойство композиции облегчает генерацию тестов и формальные доказательства.Производительность: зависит от реализаций неизменяемых коллекций; возможна некоторая накладная стоимость $копирование$, но современные реализации и оптимизации $persistentstructures,ленивыевычисления,JIT$ сильно снижают это. Параллелизация и ленивость часто проще выражаются.Минусы: наивная реализация с многократным копированием данных может быть менее эффективна по памяти; требует дисциплины и иногда другие структуры данных.

4) Логический $декларативный$ стиль

Идея: описать «что» должно быть истинно $правила/факты$, дать системе вывести ответ $backtracking,unification$.Пример $Prolog,SWI‑Prolog‑псевдо$:
unique_words$Text,Unique$ :-
split_string(Text, " \t\n.,!?:;", " \t\n.,!?:;", Words),
sort$Words,Unique$. % sort + remove duplicates
unique_count$Text,N$ :-
unique_words$Text,U$,
length$U,N$.Характеристики:
Читаемость: очень компактно для задач, близких к логическому выводу/паттерн‑матчингу; для императивной обработки строк — менее интуитивно для разработчиков, не знакомых с логическими языками.Тестируемость: логические программы легко проверять на конкретных запросах; формальное семантическое основание упрощает доказательство корректности. Но модульное тестирование больших баз правил может быть сложнее.Производительность: встроенный механизм поиска/унификации может быть медленнее в прямолинейных числовых/строчных обработках; однако оптимизации $indexing,tabling$ и библиотечные предикаты делают многие задачи быстрыми.Минусы: непривычность, отладка стеков поиска/резолюций может быть сложной, не всегда хорош для высокопроизводительных потоковых обработок без специальных оптимизаций.

Сравнительная таблица $кратко$

Читаемость:
Процедурный: + для простого, − при росте проекта.ООП: + для моделирования, − многословность.Функциональный: + выразительность, − крутая кривая обучения.Логический: + для декларативных задач, − непривычен для большинства.Тестируемость:
Процедурный: хорошая для отдельных функций; глобальное состояние — минус.ООП: хорошая при правильной инкапсуляции/DI; состояние требует управления.Функциональный: лучшая — чистые функции, простые юнит‑тесты.Логический: тестирование запросов просто, но модульность сложнее.Производительность:
Процедурный: обычно лучше для простых реализаций $in‑place$.ООП: близка к процедурной, небольшие накладные расходы.Функциональный: может иметь накладные расходы, но оптимизации и параллельность компенсируют; часто проще безопасно распараллеливать.Логический: потенциальные накладные расходы $поиск$; зависит от реализации/оптимизаций.

Практические замечания

Для задачи «уникальные слова» алгоритмическая сложность одинакова у всех реализуемых подходов: обычно O$n$ по общему объёму текста и O$k$ по числу уникальных слов $память$. Главный фактор — выбор структуры $хеш‑таблица/множествоvs.сортировка$.Важно: нормализация $lowercase,Unicode‑нормализация,удалениепунктуации,токенизация$ — логика прямо влияет на корректность и тесты; её стоит вынести в отдельную $предпочтительночистую$ функцию/модуль.При реальной нагрузке: процедурный/ООП с in‑place хеш‑таблицей чаще всего быстрее и экономнее по памяти; функциональный и логический «выигрывают» в читаемости/доказуемости/параллельности, но требуют внимания к структурам данных и оптимизациям.

Рекомендация по выбору

Маленькая утилита или скрипт: процедурный — быстро и просто.Большой проект с моделью предметной области и расширяемостью: ООП или композиция модулей.Когда важна корректность, тестируемость, параллелизм и отказ от побочных эффектов: функциональный.Когда задача носит характер правил/поиска/логического вывода $анализязыка,экспертныесистемы$: логический.

Если хотите, могу:

показать конкретные минимальные реализации на Python/Java/Haskell/Prolog;сравнить затраты памяти/времени для нескольких реализаций на реальном тексте.