)

копипастишь)

что за сервис, что за поле

то что есть дублирование и с ним борются через наследование - это понятно

А хотя... в коллекции всё же есть методы которые не сильно подходят к стеку, тогда нужно имплементировать самый корень выше коллекции т.е. iterable

p.s. мои ангулярщики тоже любят базовый класс для компонентов юзать. так же как и я люблю заюзнуть базовый класс контроллеров. Потому что там эта связанность - ок

другое дело если бы тебя пытались убедить что делать класс BaseService это ок

вот

или BaseHttpClient

ща скину

и такой есть

вот это уже симптом плохой декомпозиции.

и в случае с js/angular объем кода не сильно то и поменяется если агрегацию заюзать вместо наследования.

сейчас, тока там женериков пока нет ибо некогда, поэтому решаю с помощью any (dynamic) Ну у нас в жэс память при этом одна и таже выделяется если что)

https://github.com/rucken/core/blob/master/core/shared/base/services/base-repository.service.ts

вот базовый

а вот отнаследованный

https://github.com/rucken/core/blob/master/core/shared/services/groups.service.ts

крававый ынтерпрайз в ангуляре

репозитооории

может еще unit-of-work запилили?

что mockedItems делает в этом классе?

пока он там

еще не вынес

ну и почитай про ISP

Interface Segregation Principle

сейчас твой этот базовы реппозиторий - просто помойка

там куча всего сейчас, то что выйдет наружу

да помойка я ниче и не говорю

тут у нас во фронте просто несколько вариантов как это все вынести

окей. тогда к чему ты скинул эту штуку? признаешь что тут наследование не нужно?

пока не определился

нужно

пока не определился

запомни - объеденять штуки обычно проще чем разъеденять

+ у тебя всегда есть "клиентский код" для которого ты эти штуки и пишешь

в компоненте юзается сервисы

нужно

поясни мысль.

в компоненте юзается сервисы

давай так, у тебя 300 компонентов. Всем этим 300-м компонентов нужны ВСЕ методы этого сервиса?