Многоглаголание ООП

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

Вот пример: есть система распознавания речи, я к ней прикручиваю звукозапись и поле ввода текста с целью прямой диктовки документов в это поле.
Если не извращаться с мегапаттернами - делается один класс, создающий контрол для звукозаписи, контрол для ввода текста, грузит класс для управления с HID-микрофона с кнопками, реализует связь с системой распознавания, реализует всю дополнительную логику и все.

Но мы по ходу люди умудренные опытом, поэтому сразу приходится делать так: во-первых, система распознавания речи сумасшедшая и есть вероятность, что придется ее когда-нибудь отломать и прикрутить другую, поэтому весь ее API заворачивается во wrapper. Все обращения к нему ведутся через интерфейс типа ISpeechRecognizerWrapper. Для упрощения разработки(система распознавания тяжеловесная и каждый раз ее задолбаться запускать) делается mock-wrapper, реализующий тот же интерфейс. Итого +1 интефейс и два класса, реализующих его.

Поле для ввода текста тоже не так просто. Есть стандартный TextBox, работающий корректно с вводимым текстом. Есть наш собственный контрол - полнофункциональный RTF текстовый редактор, который не совсем адекватным образом взаимодействует с текстом переданным с распознавалки речи из-за разного понимания того, что такое знак абзаца. Так же есть стандартный RichTextBox, который может понадобится использовать. Поэтому вместо прямого обращения к методам и событиям текстового контрола - делается интерфейс ITextControl и классы-врапперы реализующие его для каждого из видов текстового контрола. +1 интерфейс +3 класса.

Контрол звукозаписи и сам по себе уже представляет собой базовое ядро с интерфейсом ISoundEngine и две вариации GUI для него. +1 интерфейс, +3 класса.

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

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

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

Т.е. планомерное следование заветам ООП и паттернам приводит к тому, что проект разрастается, приобретая "гибкость" и возможность независимого тестирования частей, но при этом ухудшается удобство работы с ним (это еще Visual Studio мешает, там без мыши между кучей файлов переключаться практически нереально) и становится сложно удерживать в голове структуру всего этого).

Да, о DSL и метапрограммировании

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

Вот к примеру - нужно вставить в код двумерную таблицу каких-нибудь коэффициентов фильтра дурачных. Какой у нас есть выбор?

1) Записать ее в виде массива прямо на нашем языке программирования. Выглядит криво, редактировать неудобно, менять в рунтайме не получится, зато обращение быстрое.

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

3) Запилить это дело в СУБД, грузить оттуда. Все то же самое, что с файлом, но еще нужен контекст коннекта к БД. Зато можно сделать редактор таблицы, бо если есть БД, то в проекте и вся инфраструктура CRUD-редакторов обычно наличествует.

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

В идеале это было бы что-то вроде: мы пишем некий код, нам понадобилось вставить что-то что в виде кода описывается с трудом. Мы пишем прямо тут в коде некую команду/ссылку на класс/чорти-чо и сбоку бантик но самое главное- чтобы это не более 5-15 символов занимало, и тут же запускаем на исполнение и у нас прямо посреди текстового редактора вылазит редактор в виде электронной таблицы/дизайнер GUI/поле для ввода SQL запроса и некий набор опций "куда сохранять результат(отдельный файл, ресурс, прямо в коде, бд, настройки) и без всяких хождений по сотне файлов проекта мышой начинаем править объект в естесвенном и удобном для него виде.
Причем если нам понадобится - мы можем написать прямо для проекта своих таких произвольных редакторов и вызывать их. Да еще и оставить это дело в проекте в рунтайме для настройки его на месте.

Отдаленно похожим на такое является intellisense - что бы там не говорили гуру с бесконечной памятью, лучше набрать пару-тройку символов идентификатора и дальше выбрать из списка, чем набирать идентификатор длиной в 10-15 символов целиком. Это как бы получается "редактор для более удобного ввода идентификаторов".

Вроде, насколько я помню, что-то похожее есть в IDEA, с ее рефакторингами и подсказками.

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

В экстремальном случае это будет выглядеть таким кошмаром:
начинаем писать текст, постепенно наворачиваем DSL и редакторы для него, язык программирования на ходу меняется, в нем появляются графические и табличные вставки, к концу разработки уже пишем чуть ли не по методу "пару строк - готов новый модуль в систему", а исходный код вместо линейного одномерного текста превратился в двумерную картинку типа электронной схемы :)