@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() - мы вроде как с обьектами работаем, а значит должно добавить в нашу коллекцию. Но вместо этого она создает вторую коллекцию, а первую - удаляет, чтобы вести себя так, как это было бы с двумя массивами.

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

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

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

Войти через центр авторизации
Похожие вопросы
YCLIENTS Москва
от 200 000 до 350 000 ₽
Ведисофт Екатеринбург
от 25 000 ₽
ИТЦ Аусферр Магнитогорск
от 100 000 до 160 000 ₽
25 апр. 2024, в 12:23
2500 руб./за проект
25 апр. 2024, в 12:21
10000 руб./за проект