Полноценные коллекции в PHP

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

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

BookCollection отдельно от кода работающего с UserCollection, это ж совсем разные сущности

Коллекция это лишь строготипизированный контейнер (как впрочем и в C#). Его задача — удостоверить принимающий метод (addBooks к примеру) что внутри — ТОЛЬКО книги и ничего больше.

# // Добавим объектов в коллекцию:
# $books->add(new Book(1), new Book(2));
# $books->add(new Book(3))->add(new Book(2));
# $books[] = new Book(5);

не желательно использовать несколько вариантов реализаций интерфейсов у одной сущности, так как это может создать дополнительные трудности при развитии проекта или в случае рефакторинга. в частности интерфейс ArrayAccess и интерфейс Collection.

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

# private function __check_type(&$object) {

В PHP5 объекты автоматически передаётся по ссылке!

# public function __construct(&$array) {
# if (is_array($array) ) {
# $this->__elements = $array;

В данном случае передача массива по ссылке ничего хорошего не даст, т.к. нет никакого присваивания элементам массива.

Когда я реализовывал нечто подобное, проверка типа была не строгая (сравнение имен классов), а с учетом наследования. Т.е. использовался is_a.

И в самом деле, почему бы не добавить в BookCollection элементы типа SciFiBook и ArtsBook наследованные от Book?

ИМХО в классе коллекции в имплементации offsetSet ошибка.

Когда вы используете $collectionInstance[] = new Book(5) в $offset приходит NULL. У вас данная ситуация никак не обрабатывается.

может быть сюда:
abstract class Collection implements IteratorAggregate, ArrayAccess, Countable

стоит добаить arrayItrerator?

Пост полностью не читал, но с автором полностью согласен — столько букв не могут быть не убедительным доводом! :)
А если серьезно, то проблема надумана и героически решена.

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

У полноценной коллекции должно быть свойство отложенной инициализации. Так что низачет.

А почему не создавать самому классы коллекций? Или использовать кодегенератор.
Ваша реализация имеет зависимость от класса Collection, от которой лучше избавиться.
Метод Collection::__check_type(&$object) реализован неверно: вы либо возвращаете true, либо кидаете exception. По логике, вы должны либо кидать exception и возвращать void, либо возвращать true|false без exception. Про то, что объекты передаются по ссылке, уже писали.
Кодинг стандарта вообще нет.
Возможно я придираюсь, но код оформлен не очень красиво. Для такого простого примера можно было бы и постараться.

В __check_type по-моему более уместно производить сравнение через instanceof, и честно говоря непонятно зачем переписывать с нуля итератор по коллекции, чем не угодил ArrayIterator, который реализует ну абсолютно такую-же логику, только быстрее и лучше, потому как является частью SPL.
Ну и eval — эт конечно бяка, я считаю уместнее отнаследовать руками требующиеся в коде коллекции, раз язык не предоставляет красивого решения для такого рода задачи.

Кроме уже названных узких мест (типа использования eval) и сомнительной полезности коллекций в таком виде в PHP, стоит обратить внимание на то, что префикс из двух подчеркиваний зарезервирован для стандартных функций и методов (__construct, __get, __set, __call, __clone и т.д.), так что его использование для собственных нужд — это дурной тон.

А ещё в методе __check_type стоило использовать оператор instanceof, чтобы разрешить более одного уровня наследования коллекций.
Хотя с этой ужасной eval'ной архитектурой нормального наследования не выйдет в любом случае.

Писал нечто очень похожее, но по другим причинам: у меня были более сложные классы массивов, зачастую с наследованием и переопределением логики.
Были сущности (e.g. class Entity), был специальный класс для массива сущностей (class EntitiesList), и был фабричный метод, который проверял, есть ли унаследованный класс массива для конкретной сущности. Если нет, то без всяких eval() с созданием нового класса возвращался базовый класс, в котором устанавливалась внутренняя переменная $_type.

Сначала давайте разберемся, для чего вообще нужна реализация «полноценных коллекций для хранения объектов одинакового типа, по удобству напоминающие Listв C#».

1. Избавиться от кода по приведению типов.

Дело в том, что коллекции в C#, Java и т.д. хранят объекты типа Object, и затем, чтобы из извлекать и затем использовать, необходимо делать дополнительное действите — приведение типа, и если это делается часто, то это весьма и весьма загаживает исходный код. То есть смысловой и семантической нагрузки приведение типа не несет, и загромождает код. Именно поэтому есть смысл использовать типизированные коллекции (да и то в Java это появилось аж начиная с версии 1.5).

Теперь пернемся к скриптовым языкам, в частности, к PHP. Тут все типы любых объектов — аналогичны вариантному типу в языках программирования со строгой типизацией, то есть любой переменной можно присвоить значение любого типа, или ссылку на объект любого типа. То есть, приведение типа при извлечении объекта из коллекции смысла не имеет.

Вывод: главный плюс типизированных коллекций — возможность избавиться от приведения типов — в PHP не актуально.

2. Дополнительно контролировать, что именно помещается в коллекцию.

Эта проверка делается в C# и Java делается на этапе компиляции (реализовано на уровне языка), и действительно в некоторых, довольно редких случаях может помогать программисту избежать ошибок.

Но в том же PHP, в любой реализации, эта проверка будет делаться в рантайме постоянно, при добавлении каждого нового объекта в коллекцию! А если в коллекцию нужно добавить, например, миллион элементов? То есть нет смысла жертвовать производительностью и писать бесполезный для логики программы код ради очень небольшого, я бы сказал сомнительного удобства.

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

Если я ошибаюсь, по пожалуйста поправьте. Все что написано выше — исключительно из личного опыта, и относится к реальным проектам, но не относится к академическим «лабораторным работам», где вызов eval и прочие изыски имеют место быть.

удобно конечно, но у меня вопрос… вот Вы создали коллекции, да, это очень гибко и дает возможность создавать нужные коллекции на лету, а вот у Вас разве нет желания контролировать код? ведь в данном подходе можно насоздавая кучу классов потом самому же в них запутаться… ведь обычно при проектировании проекта разработчик должен знать что будут такие классы, будут реализовывать такие методы, зачем создавать классы «на лету»?

Странно, что никто не сказал очевидное. Одним из основных профитов типизированной коллекции в c#(List) является отсутствие auto boxing/unboxing в отличии от ArrayList. В php же все по другому, поэтому типизированные коллекции там на… й не сдались в 90% случаев. Исключение составляют коллекции с дополнительной логикой обработки данных.

Есть замечательный Фаулеровский паттерн — Identity Map. Для сторонников ORM — самое оно. Рекомендую.
За статью спасибо.

В принципе, весь код класса коллекции можно было бы заменить этим:

class Collection extends SplObjectStorage {
  private $__type;
  function attach($o) {
     if (! $o instanceof $this->__type) throw new InvalidArgumentException(...);
     return parent::attach($o);
  }
}

И вообще лично я не догоняю смысла всей затеи. Имхо — вышла типизация ради типизации.

Что нового вы открыли? В Doctrine ORM такие же коллекции уже давно.

Как все же, долгое использование строго типизированных языков калечит психику — кажется, что без типов жизнь невозможна :)

нужно фабрику включать в класс Collection чтоб нельзя было писать так:
$books = CollectionFactory::create('Book');
$books = new BookCollection('Magazine');
не буду пояснять зачем так писать — это концептуальный момент типизация либо полна либо не полна. чтоб она была полна фабрика должна жить статически в родителе и конструктор должен быть protected
и вызов соответственно Collection::factory('Book')

Это вам вообще пригодится — избавляет от лишних сущностей + замыкает типизацию