GetComponentInParent is simply this:
public static T GetComponentInParent<T>(this GameObject go)
{
Transform current = go.transform;
while (true)
{
if (current == null)
return null;
T comp = current.GetComponent<T>();
if (comp)
return comp;
current = current.parent;
}
}
It looks for the component on the given object and if it is not found on this gameobject, it goes up the hierarchy and tries it again on the parent. If the parent also does not have this component it continues to go up (the parent’s parent and so on). If the component can not be found at all after reaching the top of the hierarchy, it would return null.
If you get a null reference exception when using GetComponent but no error when using GetComponentInParent it means the component you’re looking for does not exist on the object you used GetComponent on but on one of the parent objects.
Note there’s also the opposite of GetComponentInParent which is called GetComponentInChildren. This method instead of walking up the hierarchy checks the nested objects (childs) of the given object if the component can not be found.
in my mind they are both inherited component from parent.
Note that a hierarchical relationship of gameobjects has nothing to do with type inheritance, even though terms like parent and child are used in both cases. Making a gameobject a child of another object does not change the inheritance of objects. Gameobject nesting should be thought of nesting of objects. So putting your phone into your pocket makes the phone a child of your trousers which is a child of you (in some way). However that doesn’t make the phone become a human, it is just “contained” / “attached” to a human and moves along with it.
The same is true for components. Components are simply attached to gameobjects. GameObjects themselfs are just dumb containers that do not do anything on their own. All they are are boxes which can contain components. Those components define what this gameobject can do.