Pull to refresh

Comments 7

Я вам сейчас покажу секретную технику, только вы её никому не показывайте, а то уволят из Ангуляра...


@Directive()
export abstract class MyBaseComponent<T> {

     //Пример использования сервиса в родительском классе
     shareEntity = this.deps.get(AdditionalService).getShare()

     protected constructor(
        public deps: Injector
     ) {}

}

@Component()
export class MyChildComponent extends MyBaseComponent {

    //Пример использования сервиса в классе-наследнике
    customEntity = this.deps.get(CustomService).getEntity()

}

Пишу по памяти, Ангуляр уже года 3 не трогал.

Много лет программирую на angular. Возникали также мысли наследования, но в итоге пришел к выводу, что бесполезное это дело. Костылей только больше будет. Лучше применять композицию, чем наследование

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


Если нужна логика из CustomerService — нужно инджектить CustomerService. Если нужна логика из AdditionalService, нужно инджектить AdditionalService. Если нужна логика из обоих, то нужно инджектить оба.


Приём, описываемый в статье имеет, смысл только если все классы из проекта используют методы и из AdditionalService и из CustomerService. Даже в этой подозрительной ситуации я бы инджектил сервисы отдельно. В крайнем случае выделил бы обёртку для используемых во всех классах методов. Но мне представить такую ситуацию очень непросто.


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

UFO just landed and posted this here
Sign up to leave a comment.

Articles