I am making my custom engine for a school project. I have come up with a Resource Management concept for my engine but not sure if there is any better or improvement to be made.

First of all, if a programmer in my team wanted to create a resource, he has to do the following, 

So in the component will have TextureHolder* pointing to the object stored in my resource manager. The reason for having so many classes just for one resource is to avoid crashing in midway while using our editor. Example, in Editor mode, I have an object that has a component that has TexutreHolder* point to somewhere in resource manager, the texureInteface is pointing to Texture A, and when the user deletes Texture A, the resource manager will assign EmptyTexture to the TextureInterface* inside the TextureHolder, so now the object has a TextureHolder that inside is pointing to an EmptyTexture and when it calls a function it will just call the TextureInterface function and print some message. This prevents the Editor from crashing.

I am trying to think a better way, but this seems to be the only way to avoid the texture in the component having a nullptr after it was deleted.

I had implement a few managers for my hobby game engine.
I based the concept in the design of JMonkey:
https://wiki.jmonkeyengine.org/jme3/advanced/asset_manager.html

I made 3 managers scene, assets, state (undergoing)...
https://github.com/g-amador/JOT/tree/master/engine/Framework-Toolkit-Components/src/main/java/jot/manager

What you want is not a component rather than a resource handle. A component means that you combine properties into an object, you don't want to combine properties here instead of have a "safe" struct that keeps your engine running even if something is missing.

We have a AssetPtr<T> struct in our code. It is a reference pointer like struct that is connected to the asset manager. If a resource is removed from the manager, a flag will set (thread-safe) to indicate that this resource is in an unloading state. Then all AssetPtr<T> structs have the chance to replace their internal pointer to the default asset (Texture, Model ...) when triggered by the render system and count the reference counter down. The asset manager sets a watcher to the resource and removes it from memory when all references have been removed.

Handling assets this way has some advantages, you can prevent the same resource from loading multiple times, just return an AssetPtr to the already loaded memory chunk. You can handle load/unload of resources asynchronously in multiple threads without delays because the AssetPtr just points to the default resource until the true one has been loaded properly. Memory will be automatically cleared if you have a proper destructor in AssetPtr telling the asset manager how many instances are refering to the asset.

Finally there is no real way to do it "right"