TypeScript/Angular 6(2+)では、すべてのアプリケーションサービスの派生元となる基本的な抽象httpサービスを作成することをお勧めしますか?例えば:
//import the angular Http ...etc
export abstract class MyBaseService{
...
protected get<T>(url: string): Observable<T> {
return this.http.get(...)
.pipe(map(result => result.json() as T));
}
protected post<T>....
...
}
基本的に、残りのすべてのメソッド(GET、POST、PUTなど)を定義します。
そして、すべてのサービスで基本サービスを拡張します。
export class MyFirstService extends MyBaseService{
...
public doWork(data: MyModel): Observable<string> {
this.post<string>(`my url`, data);
}
...
}
サービスの場合、継承が最善のアプローチだと思います。 Angularでは、「プロバイダー」を介してサービスのインスタンスを別のサービスに注入することはできません。代わりに、すべてのサービスが同じインスタンスを共有します。これは通常は問題ありませんが、エラーの処理などのBaseServiceでさらに処理を行い、呼び出しが成功したかどうかを確認し、サービスが取得できるように結果を保存します。継承が唯一の実際のオプションです。
たとえば、依存性注入を使用し、ベースサービスに値を格納して提供した場合、サービスはこれらの結果にバインドされます。次に、それにバインドされているすべてのサービスが更新されます。
したがって、この時点でEventServiceとメッセージサービスがあった場合、両方が同じ値で更新されます。
継承ではなく、依存性注入を使用したいと思います。そしてここに理由があります:
MyBaseServiceコンストラクターを更新するたびに(将来のある時点で、エラーを処理するためにHttpLoggerやAlertServiceなどの別のサービスを注入する必要があるかもしれません)、それから継承するすべてのクラスを更新する必要があります(super( )これらの新しい依存関係を呼び出して挿入することもできます。これらの依存関係は子クラスとは関係がない場合があります)。
将来、他のサービスからいくつかのサービスを拡張したい場合はできません。MyBaseServiceからすでに拡張しているためです。
デバッグ中-単一のクラスについて推論する方が簡単です。クラス内のすべてのメソッドを見ることができるため、クラスを簡単に把握できますが、継承がある場合は、親クラスの動作/メソッド/プロパティを覚えておく必要があります同じように。したがって、継承が本当に有益なものを提供しない場合、DIはより良い選択のように見えます。