Dependency inversion principle in bindClass

[David200197]

Dependency inversion principle in bindClass

[David200197]

oh I understand. I needed it to be generic to comply with the dependency inversion principle, and although I extended PumpIt Class to be able to use it, it seemed like a good idea to me for it to be in the original library, since it seems to me like a very good library for cases where there is incompatibility with the decorators

[ivandotv]

I'm not sure where the problem is, can you post the problem first?
Is this a types problem?

[David200197]

Yes, in bindClass' Generic, i will show you an example

Type 'UserService' does not satisfy the constraint 'ClassValue'.

this is UserService

import type { Maybe } from "~/core/libs/maybe";
import type { UsersEntity } from "./users.entity";
import type { UserEntity } from "./user.entity";

export interface UserService {
  findOne(id: string): Promise<Maybe<UserEntity>>;
  findAll(): Promise<UsersEntity>;
}

this is UserBaseService

import type { Maybe } from "~/core/libs/maybe";
import type { UserEntity } from "../models/user.entity";
import type { UserService } from "../models/user.service";
import type { UsersEntity } from "../models/users.entity";
import type { UserRepository } from "../models/user.repository";
import { USER_TOKEN } from "../di/tokens";
import type { Inject } from "~/core/models/inject";

export class UserBaseService implements UserService {
  static inject: Inject = [USER_TOKEN.REPOSITORY];

  constructor(private readonly userRepository: UserRepository) {}

  findOne = async (id: string): Promise<Maybe<UserEntity>> => {
    return await this.userRepository.findOne(id);
  };

  findAll = async (): Promise<UsersEntity> => {
    return await this.userRepository.findAll();
  };
}

[ivandotv]

You don't need generics when binding.
You can just do:

container.bindClass(TOKEN, Class)

And when you resolve, you need generics:

container.resolve<WhatEverType>(TOKEN)

and the result from the resolve will be WhatEverType

[David200197]

You are right, for a common case, I do not require interfaces in bindClass, but I am using a Dependency inversion principle, and this allows me to switch between classes without affecting the original behavior, which allows me to scale my project without problems. I have got this idea from another project using inversify.js https://github.com/inversify/InversifyJS#step-1-declare-your-interfaces-and-types, and it seemed like a good idea to me being able to implement it with this library

[ivandotv]

There is no difference in what I gave you in the previous example and the example you posted from inversify.

[David200197]

oh excuse me, here is the example https://github.com/inversify/InversifyJS#step-3-create-and-configure-a-container, it puts interfaces to the bind generics to control which classes you pass through the arguments of the bind method. If there is something you don´t quite understand, feel free to tell me ´cause my english isn´t pretty good

[ivandotv]

Can you write me an example with pumpit that doesn't work?

[David200197]

I show a simple example

interface Vehicle {
     run(): void
}

class Car implements Vehicle {
    run(){
        console.log("the car is running")
    }
}

class Motorcycle implements Vehicle {
    run(){
        console.log("the motorcycle is running")
    }
}

const container = new PumpIt()
//case 1
container.bindClass<Vehicle>("VEHICLE", Car) // error: Type 'Vehicle' does not satisfy the constraint 'ClassValue'.

//case 2: I change Car to Motorcycle
container.bindClass<Vehicle>("VEHICLE", Motorcycle) // error: Type 'Vehicle' does not satisfy the constraint 'ClassValue'.

[ivandotv]

bindClass method is not generic.
https://github.com/ivandotv/pumpit#registering-classes

[David200197]

If you want, I can fork the project and add the generic to bindClass to make it more adaptable

[ivandotv]

There is no reason for bindClass to be generic.