@topuserman

Как реализовать свой абстрактный класс коллекции?

Помогите пожалуйста реализовать абстрактный класс коллекции.

Хочется написать свой велосипед, чтобы до конца понять, как это должно работать и т.д.

Этот класс должен решить проблемы c типизацией возвращаемых значений метода.

Как я себе это представляю:

class PostCollection extends BaseCollection {

    # Устанавливаю тип коллекции, 
    # при попытке добавить в коллекцию другой тип - выбрасываем исключение

    protected static $collectionType = PostItem::class;

}

class PostItem {
   //...
}

class Posts {
   public function getAllPost() : PostCollection { ... }
}


Также, желательно, чтобы у абстрактного класса таже были реализованы интерфейсы Iterator, ArrayAccess, Countable;

Также планирую добавлять такие методы как map(), sort() и т.д.

Готовой реализации не требую. От вас нужна помощь, чтобы подсказали, как правильно нужно реализовать такие коллекции, какие нюансы стоит учесть? Правильно ли я через статическое свойство $collectionType определяю тип текущей коллекции ?

Или есть какие-то другие варианты ?

Пробовал разобрать, как устроены коллекции в laravel или других фреймворках. Было сложно и непонятно. Очень много кода, предусмотрено все, и на все случаи жизни. Еще и через рефлексию и т.д. Мне хотелось бы минимально рабочую версию реализовать.

За помощь буду очень благодарен!
  • Вопрос задан
  • 244 просмотра
Пригласить эксперта
Ответы на вопрос 3
SilenceOfWinter
@SilenceOfWinter Куратор тега PHP
та еще зажигалка...
gzhegow
@gzhegow
aka "ОбнимиБизнесмена"
Коллекция это просто пачка. Массив с цифровыми ключами. Бывает двух типов я для себя назвал - массив и список.
Массив - ключи строго цифровые и строго по порядку.
Список - ключи строго цифровые но могут идти не по порядку и некоторые из них могут отсутствовать

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

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

Почему в Ларавеле коллекции? Потому что им надоело прокидывать по ссылке вероятно и писать методы для работы над массивами. Может не смогли разобраться. Может задолбались. Но под капотом эта их штука спамит коллекциями так что страшно думать. $collection->merge() - мы вроде как с обьектами работаем, а значит должно добавить в нашу коллекцию. Но вместо этого она создает вторую коллекцию, а первую - удаляет, чтобы вести себя так, как это было бы с двумя массивами.

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

Да и сама эта проверка в общем случае нужна в одном двух местах во всей программе. Самое прикольное, что в коллекцию определенного типа на ларе можно подложить модель другого типа и всё заработает. То есть они даже это не использовали.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы