is it possible to make an array list in a base class that is static in derived classes?

So, I've got various enemies, some of whom work together so I currently have a static array list of the other enemies of that type in their classes, which derive from a common superclass.

Can I have the superclass Enemy have an array list such that every derived class has one of it, but that is local to each derived class?

So,

Enemy would have (static) ArrayList coenemies or whatever

EnemyTypeA would inherit it but it would be static to EnemyTypeA

EnemyTypeB would inherit it but it's array list would be static to it's type, etc.



Thanks

 

Without doing it behind an accessor method, I might add...

 

Let me get this straight.

You have Enemy with a List<Enemy>

and you have two children. Enemy1 and Enemy2, and you want each to have a List of it same type?

 

No, what I have/ended up doing is I have

Enemy with abstract list method getList

Enemy1 with static list and implementation of getList
Enemy2 with static list and implementation of getList

I just thought there may be a way for Enemy to have some sort of static virtual list (or something) member such that each of its children would have their own static list instead of simply having access to the parents static list.

I'm just wondering if there's an inheritance-proper way to do this... my workaround works fine, just wasn't sure if that's not the typical way to do it.

 

Not doable out of the box. Static is the antithesis of inheritance. You can't force a child class to implement a static, not can you have a child class implement a different instance of the static member of its parent.

Just avoid static altogether with inheritance.

 

Maybe this is what you're after? No need for static stuff.

Code (CSharp):

1. using System;
2. using System.Collections.Generic;
3.  
4.  
5. // Enemy base class
6. class Enemy {
7.     public List<Type> CoEnemies;
8.  
9.     public Enemy() {
10.         CoEnemies = new List<Type>();
11.     }
12. }
13.  
14. // Enemy subtype
15. //// Note how each of these call the parent's constructor,
16. //// filling it's own list of CoEnemies
17. class Dog : Enemy {
18.     public Dog () : base() {
19.         CoEnemies.Add(typeof(Turtle));
20.     }
21. }
22.  
23. // Enemy subtype
24. class Turtle : Enemy {
25.     public Turtle() : base() {
26.         CoEnemies.Add(typeof(Cat));
27.         CoEnemies.Add(typeof(Dog));
28.     }  
29. }
30.  
31. // Enemy subtype
32. class Cat : Enemy {
33.     public Cat() : base() {
34.         CoEnemies.Add(typeof(Dog));
35.     }
36. }
37.  
38. // More dogs!
39. //// Note how again the Puppy constructor calls the constructor of Dog,
40. //// resulting in instances of Puppy to have a CoEnemies list containing
41. //// not only Cat, but also Turtle (see Dog class above).
42. class Puppy : Dog {
43.     public Puppy() : base() {
44.         CoEnemies.Add(typeof(Cat));
45.     }
46. }
47.  

 

Meh that's what I thought. Just out of curiosity, would the proper OOP way to do this be to keep track of which ones are which outside of the classes? So instead of each derived class having a static list of the other instances, just have whatever's handling them have a list for each type?

That is perfect for keeping track of all enemies of all types, but I needed separate ones. I ended up having the base class have a protected abstract list getList() method and each derived type have a static list member and implement the getList() method.


I really like your code though lol... turtles and cats and dogs, oh my! Quite the enemies lololol. The game I'm working on (a dinosaur game) started out as a puppy hunting game until I was... well, talked out of that . Your code reminds me of that haha.

 

Often people post code examples using class names like 'A' and 'B' and it just makes things confusing. I like to use examples you can relate to a bit more, which, in my opinion, makes it a bit easier to understand. I'm glad you found it amusing