Классификация класса
#1 Опубликовано 29 Октябрь 2011 - 15:13
#2 Опубликовано 29 Октябрь 2011 - 18:57
#3 Опубликовано 29 Октябрь 2011 - 19:25
Он называется неправильно спроектированный класс. Если он ТОЛЬКО для наследования и не предназначается для прямого использования, то он должен быть абстракным.Как называется неабстрактный класс (без неопределённых функций), предназначенный для наследования другими и не используемый никак иначе?
Однако есть одно исключение: mixin. Но в C++ они могут быть реализованы только в виде классов с шаблонной базой, что несколько уменьшает возможности их применения.
#4 Опубликовано 29 Октябрь 2011 - 22:01
#5 Опубликовано 30 Октябрь 2011 - 4:02
Есть класс VideoFilterManager с функциями включения/выключения всяких фильтров (эффектов) и управления ими, а также protected функцией Process. через которую ему наследник передаёт по очереди кадры, а он применяет к ним свои эффекты.Если опишешь, что у тебя за класс такой, что он делает и как его должны использовать остальные, можно будет сказать больше.
Ничего не упадёт, если создать экземпляр класса, просто некому будет его кормить через Process.А если им пользоваться нельзя, то и делать его создаваемым не правильно. Это значит, что у тебя в классе есть заглушки, которые не отловятся на этапе компиляции и, если кто-то им случайно воспользуется, программа будет падать уже в рантайме.
Я думал и о других вариантах реализации:
- Функция Process public, и объект хранится внутри наследника.
Но тогда не получится пользоваться функциями вкл/выкл фильтров извне. - Как звено конвеера. VideoFilterManager существует вне "наследника", получает от него кадры и передаёт их дальше.
Тогда конвеер излишне усложняется, так как остальные звенья сильно отличаются (для них надо делать копии кадров, надо учитывать возможность прицепления нескольких звеньев одновременно и ещё по мелочи).
Изменено: Ripper, 30 Октябрь 2011 - 4:07
#6 Опубликовано 30 Октябрь 2011 - 9:43
Наследованеи - это самая сильная связность. По возможности, если агрегация нормально вписывается, лучше использолвать ее.Есть класс VideoFilterManager с функциями включения/выключения всяких фильтров (эффектов) и управления ими, а также protected функцией Process. через которую ему наследник передаёт по очереди кадры, а он применяет к ним свои эффекты.
А ты не хочешь выкинуть manager вообще и ставить в конвеер фильтры? Получится намного проще. А то у тебя в каждом узле конвеера сидит сложное нечто, что умеет все-все-все и настраивается снаружи.
#7 Опубликовано 30 Октябрь 2011 - 11:15
Не вижу вреда в сильной связности в данном случае.Наследованеи - это самая сильная связность. По возможности, если агрегация нормально вписывается, лучше использолвать ее.
Агрегацию устроить можно, но тогда будет нужна либо куча обёрточных меотодов, либо один метод, который возвращает вложенный объект, что делает взаимодействие очень запутанным.
Тогда осложнится включение/выключение отдельных фильтров, а такжеА ты не хочешь выкинуть manager вообще и ставить в конвеер фильтры? Получится намного проще. А то у тебя в каждом узле конвеера сидит сложное нечто, что умеет все-все-все и настраивается снаружи.
конвеер излишне усложняется, так как остальные звенья сильно отличаются (для них надо делать копии кадров, надо учитывать возможность прицепления нескольких звеньев одновременно и ещё по мелочи).
Может быть, моя ошибка в неправильной организации взаимодействия пользовательского интерфейса и программы? Я представляю GUI как нечто монолитное, настраивающее всё и вся снаружи. И с точки зрения GUI, как раз удобно, когда есть что-то умеющее всё-всё-всё и настраивающееся снаружи.нечто, что умеет все-все-все и настраивается снаружи.
#8 Опубликовано 30 Октябрь 2011 - 12:51
Наоборот, упрощается. Если у тебя в конвеере находятся фильтры, то ты можешь либо убирать/добавлять их в конвеер. Либо включать/отключать их прямо в конвеере. Вместо кучи методов "включить фильтр такой-то" у тебя будет один метод: включить. Используй полиморфизм, не пытайся составить конвеер из одинаковых элементов, умеющих все.Тогда осложнится включение/выключение отдельных фильтров, а также
Не удобно. Почитай про концепцию open close. У тебя получается, что чтобы добавить любой функционал к своей программе нужно переписывать GUI. Причем ты не можешь сделать подключаемые фильтры: GUI то монолитный. И чем больше фильтров, тем сложнее и больше GUI. Ты получишь переграженный большой класс, котоырй делает все.Может быть, моя ошибка в неправильной организации взаимодействия пользовательского интерфейса и программы? Я представляю GUI как нечто монолитное, настраивающее всё и вся снаружи. И с точки зрения GUI, как раз удобно, когда есть что-то умеющее всё-всё-всё и настраивающееся снаружи.
Решение - каждому фильтру сделать widget с настройками этого фильтра. Если у фильтров есть общие настройки - вынести их в базовый интерфейс и сделать отдельные контролы, настраивающие эти свойства.
#9 Опубликовано 30 Октябрь 2011 - 16:46
#10 Опубликовано 30 Октябрь 2011 - 19:30
#11 Опубликовано 31 Октябрь 2011 - 4:38
Я ушёл читать про SOLID, потом паттерны, а потом про виджеты (Qt).Не удобно. Почитай про концепцию open close. У тебя получается, что чтобы добавить любой функционал к своей программе нужно переписывать GUI. Причем ты не можешь сделать подключаемые фильтры: GUI то монолитный. И чем больше фильтров, тем сложнее и больше GUI. Ты получишь переграженный большой класс, котоырй делает все.
Решение - каждому фильтру сделать widget с настройками этого фильтра. Если у фильтров есть общие настройки - вынести их в базовый интерфейс и сделать отдельные контролы, настраивающие эти свойства.
как закончу, вернусь
В ffmpeg похожее реализовали, только без мышки (libavfilter).Мышкой их таскать, вызывать диаог настройки и т.п. Коду, который это делает не нужно знать типы вершин, ему хватит базового класса.
Мышкой же соединяем входные и выходные интерфейсы линиями - каждой линии соответсвует videopipe.
1 пользователей читают эту тему
0 пользователей, 1 гостей, 0 невидимых