Имеем такую функцию. От каждого элемента получить дочерний.



теперь мне нужно в некоторых местах получить дочерние элементы, но определенного типа (применив какой-нибудь фильтр). Тут два варианта (как я вижу).
1) Сначала берем все дочерние, потом отфильтровываем



2) Отфильтруем элементы сразу в функции "Get..."


Вопрос в том, что лучше. То есть в первом варианте у нас гораздо меньше вызовов именно функций, но как то не ООП, в отличие от второго варианта. 
А может я слишком заморачиваюсь и разницы особой нет?

Это сообщение отредактировал(а) xTr1m - 26.7.2012, 17:40

Первый вариант фильтрации просто памяти больше будет потреблять на больших коллекциях. Но идеологически, в разрезе проектирования API, наверное более предпочтителен. Ну а во втором варианте я бы передавал какие-нибудь std::function/lambda, нежели голый указатель на функцию.

Это сообщение отредактировал(а) Amp - 26.7.2012, 17:54

Ну передается все по ссылкам, поэтому никаких копирований не предвидеться. Единственное в первом варианте нужно пройтись два раза по этой самой коллекции. 
А чем все же именно предпочтительнее? =))

Да как хочешь 

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

Мне второй вариант больше нравится... Обидно будет, если в коллекции, допустим, миллион элементов, а функция фильтрации оставит 2....
Кстати, функцию фильтрации, возможно, можно сделать универсальной. Не FilterByStatus или FilterByCreationTime, а


Добавлено @ 18:18
а добавив функцию NoFilter, получишь свою изначальную (не фильтрующую) функцию


Это сообщение отредактировал(а) borisbn - 26.7.2012, 18:19

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

> красивее посмотреть на компоновщик+итератор.
Это как? Можно продемонстрировать кодом?

borisbn, за шаблонный вариант спасибо, но боюсь одно слово шаблон вызовет косые взгляды ан меня =))
Result, по поводу архитектуры. Вариант с шаблоном действительно явный пример архитектурного решения. В изначальном же варианте я не вижу явных аргументов, кроме как "это архитектура лучше", вот и хочу узнать чем. Может есть какой-нибудь сценарий развития, при котором в будущем мой 2ой вариант легче модернизировать, чем первый?

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


Можно сказать, что это копи-паст и тд. Но это нормальный копи-паст, потому что функции делают разное.
Пример такого подхода можно считать функцию erase в std::vector.

iterator erase ( iterator first, iterator last );
iterator erase ( iterator position );

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

Ну и в итоге можно сказать, что я за немного измененный второй вариант.

Аргументы:
Имея только одну функцию и реализацию по первому варианту - мы имеем преджевременную писсимизацию (тратим ОЗУ, чего можно не делать)
Имея только одну функцию и реализацию по второму варианту - ме имеем ту же преджевременную писсимизацию (тратим CPU на проверки, чего можно не делать)


Это сообщение отредактировал(а) korian - 27.7.2012, 09:09

Вот примерчик накидал http://liveworkspace.org/ 
Правда абстрактный пример не очень нагляден   
Интересное представляет main.

эта потребность возникает вследствии "ограничения" доступа к древу обьектов функцией ГетЧайлдс.. Если предоставить константый доступ к ссылке на ветку, то можно будет применять стандартные алгоритмы.. Вобщем начинать надо не с вопроса какой сделать функцию, а с того как наиболее удобным образом представить данные... 

Это сообщение отредактировал(а) mes - 29.7.2012, 22:58

Так это все-таки дерево? У меня как бы была мысль, но я не увидел никакого кода обхода дерева.

список - частный случай древа