Hi. I'm programming for a simple game.

I designed component classes for my objects. There is a HealthComponent class. This class has a HP and state as a member variable. A HP is for the object like a human, monster. And a state is a object's state, dead or alive.

but I need a component for the object who needs a state but doesn't needs a HP.

So, I thought about that. I have two ways.

1. Just implement two classes. HealthComponent and NonLifeComponent?(btw plz recommend a class's name..)
   A NonLifeComponent class has only a state, expired or not.
   
2. Make a inheritance relation between HealthComponent and NonLifeComponent.
   A NonLifeComponent will be a base class. the member is same with (1). And HealthComponent will be a derived class. In this case, the name of NonLifeComponent is a nonsense.

Maybe (2) will be like next code.

// Plz recommend a class name.
class XXComponent
{
   ...
   eState m_eState; // expired or not
};

class HealthComponent : public XXComponent
{
   ...
   int m_iHP;
} 

And (1) will be like this.

class NonLifeComponent
{
   eState m_eState; // expired or not
};

class HealthComponent
{
   int    m_iHP;
   eState m_eState; // Alive or Dead 
};

Which one is more good way?

Component sounds like you're going somehow into ECS direction or at least object composition so don't think of it in topics rather than in properties. What I do when I design components is to decide which aspect of my game does this component relate to and if it is an atomic aspect (a single purpose) or does it share properties with other components. So if you need a state like Dead/Alife/Expired, which is shared by multiple purposes (so it isn't atomic) just decouple that from the component and make it an own one.

Btw. If something has zero or less life, then it should count as dead anyways so do you really like a state property here or isn't it a better approach to compute if something is alife by the remaining HP?

Components and inheritance isn't a good idea in my opinion. Even if both don't exlcude each other, it isn't a good design approach to have components that other components inherit. As I said above, don't think in components rather than in properties

@Shaarigan Thank you for your opinion! I'm almost beginner in game programming. So maybe you could feel my design is weird. And my English is bad, I'm not sure that I understood you mean.

First of all, I thought that state is needed. My logic in my head like this.

for(monster : monsters)
{
	if(monster is hit by other)
	{
   		pMonster->GetHealthComp()->HitByObj(other);
   		if(pMonster->GetHP() <= 0)
   			pMonster->GetHealthComp()->SetState(eState::DEAD);
	}
}

...
for(obj : objs)
{
	// IsDead() checks if m_eState is eState::DEAD.
	// but I also think that just checking if HP is 0 is good too. 
	if(obj->GetHealthComp()->IsDead())  
	{
		// remove dead obj
	}
}

And.. what do you mean “just decouple that from the component and make it an own one”?

you mean that I just use one class HealthComponent without NonLifeComponent, and remove a state property in the class, and add a state property in object class like next? (if I use state)

class HealthComponent 
{
	...
 	int m_iHP;
};

class CGameObject
{
  ...
  // pointers for components
  XXComp* m_pComp1;
  XXComp* m_pComp2;
  ...
}

class Ammo : public CGameObject
{
  ...
  eState m_eState;
}

eu5 said:
First of all, I thought that state is needed. My logic in my head like this

Like I said, you can compute IsDead and no need for an own state

eu5 said:
HealthComponent without NonLifeComponent, and remove a state property in the class

Yeah but instead of adding it into the gameObject, just make a LifeStateComponent with just that property.

Btw. if you intend to decrease the condition of some of your objects over time “like food” then you may also rename the HealthComponent and use that as well to determine if for example food needs to decay

@Shaarigan Thank you. Your advice helped me a lot ?