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

[metaclass]

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

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

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

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

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

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

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

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

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

Comments

[samurai-within.livejournal.com]

ООП зло?

[metaclass.livejournal.com]

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

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

[samurai-within.livejournal.com]

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

[mibori.livejournal.com]

я думаю, что вместе с тем, что преждевременная оптимизация -- зло, преждевременное метапрограммирование -- зло тоже.

[metaclass.livejournal.com]

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

[mibori.livejournal.com]

ну что поделаешь, документируйтесь комментируясь :)

есть в общем-то реляционная алгебра, с помощью которой БД сводится к 3 н.ф., вероятно есть, теория, по которой мн-во классов сводятся к какой-либо "н. ф." (смотря, конечно, что под ней считать)... не интересовался. Если таковой нет, изобрети :)

[lupus-lupusum.livejournal.com]

use perl

[mibori.livejournal.com]

начинается :)

мне тоже хотелось написать "import Haskell"

[lupus-lupusum.livejournal.com]

а что начинается? ООП это холиварная тема разве, в списке вроде нет пока http://lurkmore.ru/Холивар/Список_холиваров

[metaclass.livejournal.com]

Холиварная, однозначно. Помнится в ru_perl на эту тему 500 комментов только так набрали :)

[mibori.livejournal.com]

человеку платят за то, чтобы он писал на визуалке, мучался, а тут вы приходите и говорите use perl

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

[metaclass.livejournal.com]

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

[zamotivator.livejournal.com]

+1000

[lupus-lupusum.livejournal.com]

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

[metaclass.livejournal.com]

Мне тоже :)

[metaclass.livejournal.com]

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

[zamotivator.livejournal.com]

Во-во-во, перманентный холивар.
КОгда компилятор стучит по руках за косяки - говоришь ему и себе спасибо - написанная в запале хуйня не собралась, редкий случай что вылез бы у заказчика и с которым ты бы сломал себе бошку на отладке - проявился.
Но потом начинаешь бороться со всякой хуйней, пишешь врапперы-адаптеры-интерфейсы чтобы один кусок кода работал корректно - и понимаешь, что хочешь динамической типизации...
И вот такой замкнутый круг =(

[zelanton.livejournal.com]

Батенька, а каким это приключением вас прибило к системам распознавания речи? Или это с потолка взятый пример? Всегда интересуюсь в первую очередь прикладным смыслом, а не программистскими заморочками.

[metaclass.livejournal.com]

У клиентов рабочее время стоит настолько дорого, что им дешевле купить систему распознавания речи и заплатить за интеграцию с нашей системой документооборота, чем научить их писать на клавиатуре.

[zelanton.livejournal.com]

О мой Бог! А ошибки при наборе они тоже голосом исправлять думают?

[metaclass.livejournal.com]

Да. Оно именно так и выглядит.

[zhengxi.livejournal.com]

Это как?
"блин" сказанное с правильной интонацией удаляет последнее введённое слово ?

[metaclass.livejournal.com]

Говоришь: select "ранее произнесенная фраза", оно ее выделяет
затем можно сказать "Delete that", можно поменять формат(uppercase, bold, italic, lowercase итд), можно попросить проверить правописание, можно заменить на другие варианты слов из списка распознанных, итд.

[blackyblack.livejournal.com]

Га-га-га. Добавьте сразу распознавание мата. Очень пригодится.

[zamotivator.livejournal.com]

Пиздец, эти люди глубоко больны... ИМХО

[metaclass.livejournal.com]

Это врачи, им можно :)

[veter-r-r.livejournal.com]

Кто дал врачам деньги?!

[metaclass.livejournal.com]

Это неместные врачи.

[blackyblack.livejournal.com]

Это волчанка (с интонациями др. Хауза)

[lupus-lupusum.livejournal.com]

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

[metaclass.livejournal.com]

У меня есть свой стандартный hello-world :)
Время и затраты усилий на разработку телефонного справочника с возможностью редактирования номеров. Для большей специфики и отстрела любителей "веб-приложений" - с возможностью набора номера через модем.

[lupus-lupusum.livejournal.com]

время это я понимайт, а затраты усилий в каких единицах измеряются?

[metaclass.livejournal.com]

Ни в каких, качественная оценка.
В некоторых языках это делается просто, а в некоторых сначала надо вступить в секту, потом самостоятельно написать DataGrid(в экстремальных случаях - GUI фреймворк целиком) :)

[lupus-lupusum.livejournal.com]

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

[metaclass.livejournal.com]

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

[komarov.livejournal.com]

купи себе твердотельный накопитель или девайс, который ставится в PCI и позволяет засунуть в себя до 8 гб оперативки и видеть их в системе как хард-драйв... всё будет компилиться оччень быстро :-)
как остальные направления оптимизировать, не знаю

[blackyblack.livejournal.com]

ООП зачастую зло. Что делать, не знаю. Наверное картинки рисовать и искать по ним дополнительного спеца. Наверное ещё использовать SOA опять же с картинками - тогда ориентирование на проекте будет гораздо свободнее.

[zmila.livejournal.com]

:))
знакомо. у нас тоже бывает так глубоко-паттерново.
если взять тот же уишный контрол (виджет), то в действительности будет:

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

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

[golosptic.livejournal.com]

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

[metaclass.livejournal.com]

Распознавалка речи возвращает \r\n и считает его двумя символами, а rtf-контрол - #21 и считает его одним, из-за чего синхронизация речи и текста слетает на переносах