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

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

Так вот, столкнулся с тем, что класс коллекции изрядно "разбух", что не очень способствует понятности кода.

Методы по назначению можно поделить на несколько групп:

• Навигация по коллекции (перемещение внутреннего указателя тудым-сюдым, вверх-вниз и т.д.)
• Работа с общими свойствами элемента, касающимися структуры (getIndex, getPath, getLevel, getParent, size и т.д.)
• получение ссылок на элементы коллекции (next, prev, current, getChildByIndex и т.п.)
• операции над элементами коллекции (appendElement, prependElement, pushChild и т.д.)
• поиск по коллекции
• разрешение конфликтов (убираем конфликтующие директивы и т.п.)
• операции над коллекцией (collectionClone, collectionUnset...)

Как бы эту задачку обобщения решить покрасивше?

Последовательно наследовать классы, потихоньку добавляя функционал, на мой взгляд, как-то архитектурно ущербно. Множественного наследования нету. Само собой напрашивается использование типажей (traits), но это привяжет к версии 5.4 (сам сейчас пользуюсь 5.3 и переустанавливать пока желанием не горю). Вроде бы, самый удачный вариант - использовать композицию (особенно в сочетании с сокрытием делегирования). Но тогда в самой коллекции опять таки будет куча делегирующих методов.

На ум напрашивается механизм перегрузки методов. Что, если использовать его для "совсем скрытого делегирования"? Т.е. делегирующие методы не объявлены, а их вызовы обрабатывать при помощи магического метода __call()? А если вызываемого метода нету, то бросать исключение?

Или можно как-то элегантнее проблему решить? Посоветуйте, пожалуйста!

Благодарю!

_____________

Хотя вот это:

$collection->currentElement->size();

hydrogen
Для такого рода коллекций есть замечательный SPL интерфейс Iterator, посмотри что еще есть в мане

sharki, я построил коллекцию на основе SPL класса ArrayObject. Встроенные классы, поддерживающие именно такую коллекцию, какую мне надо (древовидная), мне как-то не попались. Все больше списки, стэки, кучи...

Или я чего не понял?

_____________

$collection = new Collection();
// бла-бла-бла...
$searcher = new Collection_Searcher($collection);
$directive = $searcher->findDirective('KeepAlive');
// и т.д.
// (при этом $collection->searcher === $searcher)

$collection = new Collection();
// бла-бла-бла...
$searcher = new Collection_Searcher($collection);
$directive = $searcher->findDirective('KeepAlive');
// и т.д.
// (при этом $collection->searcher === $searcher)

Ты правильно мыслишь, в любом дереве есть веточка в на ней листочки, вот серчер это веточка. Осталось дело за малым. Кстати тебе бы наверное пригодилась бы логика Одного паииерна, забыл как называется, он еще используется в extjs

Во, вспомнил, компоновщик называется http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%...BD%D0%B8%D1%8F)

sharki, спасибо за наводочку!

_____________

Да, еще такой вопрос... Допустим, инстанцированы такие экземпляры:

$element_2 {
    index -> 0
    parent -> $element_1
    childs -> array (0 => $element_3)

    function remove()
    function reindexChilds()
}

$element_3 {
    index -> 0
    parent -> $element_2
    childs -> array ()

    function remove()
    function reindexChilds()
}

А метод remove() имеет такой вид:

function remove() {
    unset($this->parent->childs[$this->index]);
    $this->parent->reindexChilds();
}

И $element_2->childs[0] - единственная ссылка на $element_3.

Что произойдет, если вызвать $element_3->remove()? Как поведет себя сборщик мусора? Удалит объект $element_3 по завершению функции $element_3->remove() или это грозит фатальной ошибкой?

Спасибо!

_____________

да нормально все должно быть, просто линк пропадет.