   [.net] Excessive use of properties
  I have a very generic base class for items in my game and due to restrictions beyond my control I can't derive more specialised classes from this base class. So every item has a general type (weapon, ammo, ...) and up to three additional values to further describe it ({pistol, rifle, ..}, {left handed pistol, right handed pistol}, ...)Now, let's assume I want to check whether a given item is a rifle, pistol, etc.Given the choice between these two:public bool IsRifle { get { return CheckWeaponType(1); } }public bool IsPistol { get { return CheckWeaponType(2); } }public bool IsRocket { get { return CheckWeaponType(3); } }public bool IsKnife { get { return CheckWeaponType(4); } }public bool IsFoo { get { return CheckWeaponType(5); } }public bool IsBar { get { return CheckWeaponType(6); } }private bool CheckWeaponType(uint WepType){  return (ItemType == ItemTypes.Weapon && SpecialType1 == WepType);}public bool CheckWeaponType(uint WepType){  return (ItemType == ItemTypes.Weapon && SpecialType1 == WepType);}Is there a reason to prefer one over the other? Personally I like the first approach since it's easier to read, but I'm generally a sucker for abstraction so I can't tell whether it's too much or not. Since this class really is for every single item, I would end up with about ten Is* properties each for armor, weapons, buffs, etc.Also, I realise one could go with the second approach and replace the uint WepType with an enum and thereby avoid the magic-numbers and get similar pleasant code like CheckWeaponType(Item.WeaponTypes.Rifle); but I'd like to avoid that since all item data is read from external data files and I'd have to update the code whenever I update the data files.Is there a difference in performance or memory-use maybe? I'm still kinda new to C# and couldn't find anything in the various MSDN guides.thanks,borealis   
Quote:Is there a difference in performance or memory-use maybe? I'm still kinda new to C# and couldn't find anything in the various MSDN guides.Does it really matter? Do you check this type more than 10000 times a second? If not then you really shouldn't worry about this kind of microoptimization. If you do then you probably still shouldn't worry about this; at least not until you have confirmed with your profiler that it's a bottleneck. Also checking if an object is a rifle thousands or millions or times suggests a bad design anyway, so you probably have bigger issues if this code is performance critical.Quote:I'm generally a sucker for abstraction so I can't tell whether it's too much or not. ...Also, I realise one could go with the second approach and replace the uint WepType with an enum and thereby avoid the magic-numbers and get similar pleasant code like CheckWeaponType(Item.WeaponTypes.Rifle); but I'd like to avoid that since all item data is read from external data files and I'd have to update the code whenever I update the data files.You're a sucker for abstraction, but you want to keep passing around ints? It can't take long to update the data loading code to load the data into an enum. You would have to update the input validation part of the code anyway whenever you modify the enum. I would seriously reconsider using an enum if I was you and then simply have property WeaponType Weapon{get{return weaponType;}}Anyway if you could change your class hierarchy I would consider whether this is really the right way to design it. Often the approach of having a single GameObject class used for many things is bad OOD. However if you can't change the design due to code depending on this design or for some other reason, then I would suggest you at least switch to using enums; not for performance, but for ease of use.   ;  I would use an enum for the weapon type instead.  public enum WeaponType{    Rifle,    Pistol,    Rocket,    Knife,    Foo,    Bar}Now just test for the enum.theTroll   ;  I'm still learning C# so I hope I'm not missing something language-specific here, but you saidQuote:all item data is read from external data files and I'd have to update the code whenever I update the data files.it seems to me that in the end, you'd have to update MORE code if you did NOT use enums, since you'd either be writing new properties or changing magic numbers.  Personally, using 'magic numbers' has caused me grief before, and I try to avoid them.I vote for adhering to the KISS principle in this case.   ;  I suspect what you really want is either inheritance, or have multiple classes that implement one or more interfaces.   