![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Многоглаголание ООП
Чем больше пишу с использованием ООП, тем больше бесит одна проблема - нарастание количества классов и интерфейсов и уменьшение их размера. В экстремальных случаях интерфейсы и классы вообще служат исключительно маркерами или атрибутами или исключениями и ничего интеллектуального в себе не делают.
Вот пример: есть система распознавания речи, я к ней прикручиваю звукозапись и поле ввода текста с целью прямой диктовки документов в это поле.
Если не извращаться с мегапаттернами - делается один класс, создающий контрол для звукозаписи, контрол для ввода текста, грузит класс для управления с HID-микрофона с кнопками, реализует связь с системой распознавания, реализует всю дополнительную логику и все.
Но мы по ходу люди умудренные опытом, поэтому сразу приходится делать так: во-первых, система распознавания речи сумасшедшая и есть вероятность, что придется ее когда-нибудь отломать и прикрутить другую, поэтому весь ее API заворачивается во wrapper. Все обращения к нему ведутся через интерфейс типа ISpeechRecognizerWrapper. Для упрощения разработки(система распознавания тяжеловесная и каждый раз ее задолбаться запускать) делается mock-wrapper, реализующий тот же интерфейс. Итого +1 интефейс и два класса, реализующих его.
Поле для ввода текста тоже не так просто. Есть стандартный TextBox, работающий корректно с вводимым текстом. Есть наш собственный контрол - полнофункциональный RTF текстовый редактор, который не совсем адекватным образом взаимодействует с текстом переданным с распознавалки речи из-за разного понимания того, что такое знак абзаца. Так же есть стандартный RichTextBox, который может понадобится использовать. Поэтому вместо прямого обращения к методам и событиям текстового контрола - делается интерфейс ITextControl и классы-врапперы реализующие его для каждого из видов текстового контрола. +1 интерфейс +3 класса.
Контрол звукозаписи и сам по себе уже представляет собой базовое ядро с интерфейсом ISoundEngine и две вариации GUI для него. +1 интерфейс, +3 класса.
Управление с HID-микрофона - микрофонов много и разных, каждый представляется своим классом, тоже реализующим стандартный интерфейс. Кроме того, управление с микрофона должно в разных режимах работы направляться в разные части программы, поэтому все события с микрофонов в итоге попадают в менеджер микрофонов, и вызывают метод специального интерфейса IDeviceCommandSink, который этому менеджеру указывается извне теми, кто хочет получать события от микрофонов. Кроме всего этого, на микрофоне есть светодиоды сигнализации режима работы, для управления которыми нужен обратный поток данных от системы, через менеджер микрофонов, в класс-драйвер микрофона. +хрен знает сколько классов и минимум два интерфейса.
Если при этом хотя бы частично следовать идее "один класс-один файл", проекты превращаются в кучу мелких файлов, что совершенно не улучшает время компиляции. Еще хуже, если выделить общие для нескольких проектов части в отдельные проекты и на них ссылаться - компиляция начинает еще больше тупить.
Пониманию логики работы такая структура - множество мелких классов тоже не очень способствует, по моему, потому что реальный рабочий код плохо виден за лесом из служебного кода инициализации-деинициализации всех этих врапперов, интерфейсов и прочего.
Т.е. планомерное следование заветам ООП и паттернам приводит к тому, что проект разрастается, приобретая "гибкость" и возможность независимого тестирования частей, но при этом ухудшается удобство работы с ним (это еще Visual Studio мешает, там без мыши между кучей файлов переключаться практически нереально) и становится сложно удерживать в голове структуру всего этого).
Вот пример: есть система распознавания речи, я к ней прикручиваю звукозапись и поле ввода текста с целью прямой диктовки документов в это поле.
Если не извращаться с мегапаттернами - делается один класс, создающий контрол для звукозаписи, контрол для ввода текста, грузит класс для управления с HID-микрофона с кнопками, реализует связь с системой распознавания, реализует всю дополнительную логику и все.
Но мы по ходу люди умудренные опытом, поэтому сразу приходится делать так: во-первых, система распознавания речи сумасшедшая и есть вероятность, что придется ее когда-нибудь отломать и прикрутить другую, поэтому весь ее API заворачивается во wrapper. Все обращения к нему ведутся через интерфейс типа ISpeechRecognizerWrapper. Для упрощения разработки(система распознавания тяжеловесная и каждый раз ее задолбаться запускать) делается mock-wrapper, реализующий тот же интерфейс. Итого +1 интефейс и два класса, реализующих его.
Поле для ввода текста тоже не так просто. Есть стандартный TextBox, работающий корректно с вводимым текстом. Есть наш собственный контрол - полнофункциональный RTF текстовый редактор, который не совсем адекватным образом взаимодействует с текстом переданным с распознавалки речи из-за разного понимания того, что такое знак абзаца. Так же есть стандартный RichTextBox, который может понадобится использовать. Поэтому вместо прямого обращения к методам и событиям текстового контрола - делается интерфейс ITextControl и классы-врапперы реализующие его для каждого из видов текстового контрола. +1 интерфейс +3 класса.
Контрол звукозаписи и сам по себе уже представляет собой базовое ядро с интерфейсом ISoundEngine и две вариации GUI для него. +1 интерфейс, +3 класса.
Управление с HID-микрофона - микрофонов много и разных, каждый представляется своим классом, тоже реализующим стандартный интерфейс. Кроме того, управление с микрофона должно в разных режимах работы направляться в разные части программы, поэтому все события с микрофонов в итоге попадают в менеджер микрофонов, и вызывают метод специального интерфейса IDeviceCommandSink, который этому менеджеру указывается извне теми, кто хочет получать события от микрофонов. Кроме всего этого, на микрофоне есть светодиоды сигнализации режима работы, для управления которыми нужен обратный поток данных от системы, через менеджер микрофонов, в класс-драйвер микрофона. +хрен знает сколько классов и минимум два интерфейса.
Если при этом хотя бы частично следовать идее "один класс-один файл", проекты превращаются в кучу мелких файлов, что совершенно не улучшает время компиляции. Еще хуже, если выделить общие для нескольких проектов части в отдельные проекты и на них ссылаться - компиляция начинает еще больше тупить.
Пониманию логики работы такая структура - множество мелких классов тоже не очень способствует, по моему, потому что реальный рабочий код плохо виден за лесом из служебного кода инициализации-деинициализации всех этих врапперов, интерфейсов и прочего.
Т.е. планомерное следование заветам ООП и паттернам приводит к тому, что проект разрастается, приобретая "гибкость" и возможность независимого тестирования частей, но при этом ухудшается удобство работы с ним (это еще Visual Studio мешает, там без мыши между кучей файлов переключаться практически нереально) и становится сложно удерживать в голове структуру всего этого).
no subject
no subject
Функциональное программирование и автоматический вывод типов, возможно, помогли бы немного уменьшить количество и размеры служебного кода, но там организационных заморочек хватает, типа "кто это все будет поддерживать в будущем".
no subject
индусовпрограммистов. Как в жаботуториале - все класс, каждый чих класс или его метод. Получаем зачастую искуственное обкласивание всего и вся надо-ненадо.no subject
no subject
no subject
есть в общем-то реляционная алгебра, с помощью которой БД сводится к 3 н.ф., вероятно есть, теория, по которой мн-во классов сводятся к какой-либо "н. ф." (смотря, конечно, что под ней считать)... не интересовался. Если таковой нет, изобрети :)
no subject
no subject
мне тоже хотелось написать "import Haskell"
no subject
no subject
no subject
также, не нужно тыкать на список холиваров: в холиварах обычно участвуют люди, которые лучше всего знают одну точку зрения, а о противоположной практически не имеют представления, и не хотят иметь. Люди знающие плюсы и минусы обеих технологий, или хотя бы желают их изучать, время на холивары не тратят. Им работать нужно.
no subject
no subject
no subject
no subject
no subject
no subject
КОгда компилятор стучит по руках за косяки - говоришь ему и себе спасибо - написанная в запале хуйня не собралась, редкий случай что вылез бы у заказчика и с которым ты бы сломал себе бошку на отладке - проявился.
Но потом начинаешь бороться со всякой хуйней, пишешь врапперы-адаптеры-интерфейсы чтобы один кусок кода работал корректно - и понимаешь, что хочешь динамической типизации...
И вот такой замкнутый круг =(
no subject
no subject
no subject
no subject
no subject
"блин" сказанное с правильной интонацией удаляет последнее введённое слово ?
no subject
затем можно сказать "Delete that", можно поменять формат(uppercase, bold, italic, lowercase итд), можно попросить проверить правописание, можно заменить на другие варианты слов из списка распознанных, итд.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Время и затраты усилий на разработку телефонного справочника с возможностью редактирования номеров. Для большей специфики и отстрела любителей "веб-приложений" - с возможностью набора номера через модем.
no subject
no subject
В некоторых языках это делается просто, а в некоторых сначала надо вступить в секту, потом самостоятельно написать DataGrid(в экстремальных случаях - GUI фреймворк целиком) :)
no subject
Причем обязательно найдется адепт, к-й скажет, что ты его изучил плохо а потому затрудняешься писать.
no subject
no subject
как остальные направления оптимизировать, не знаю
no subject
no subject
знакомо. у нас тоже бывает так глубоко-паттерново.
если взять тот же уишный контрол (виджет), то в действительности будет:
модель (интерфейс, класс реализация, мок-класс)
контроллер (интерфейс, ридонли реализация, её расширяет редактируемая реализация, и ещё возможно реализация, учитывающая права доступа)
вьюха (интерфейс, реализации, которые в свою очередь часто тоже композиция из нескольких классов)
плюс разные обслуживающие листенеры, обсерверы, конвертеры, фактори.
реализация чего-нибудь более-менее значимого, вроде таблицы, выливается в 200+ файлов. ориентироваться там по памяти я не в силах. постоянно поиск.
no subject
И почему же в этом месте я стал истерически хихикать?
Не обращайте внимания, это нервное.
no subject