This is a follow-on to your previous question, and this is a case for using a strategy. Your tanks should all expose the same functionality, but use a different driver or input. Player tanks would use user input, while enemy tanks would use AI.
Turrets can have different capabilities as well, and I believe your design captures this correctly. You have a common interface or parent class, with the player subclass offering the extra complexity of having additional child components.
There are several ways to implement this, but the general idea looks something like this:
class TankDriver {
abstract void move(Tank t);
}
class PlayerTankDriver {
...
}
class AiTankDriver {
...
}
class Tank {
TankDriver driver;
Tank(TankDriver d) {
driver = d;
}
void move() {
d.move(this);
}
}
The general use case is you specify the driver strategy when you construct a tank, then keep a reference around for the tank. When it is the tank's turn to move, you tell it to move: it delegates to its strategy, which is implementation-defined. It is flexible because it can further query the user or use any AI you want: one enemy tank could be very aggressive, another could be more risk-adverse. One might use a lookahead algorithm with a very deep tree, another might just look ahead one move (i.e. the difficulty is different).
The point is, you still only need a single tank class because the pluggable logic is in in other classes that have a laser focus on one aspect of what it means to be a tank.
Finally, there is the issue that the turret on a player tank may have different methods exposed than on an AI-controlled turret. This can get into a weird three-way dependency that is a bit tightly coupled, and there are multiple ways to address it.
This is a tough nut to crack in a way that keeps your design reasonable while also satisfying your professor's goal of having a "proper" OO design.
I think the best way to accomplish this in a true OO fashion is to keep the design you have with the turret belonging to the tank, and to expose a subset of turret functionality on the tank itself which it then forwards to the actual turret. This is not how I would design it in a real-world scenario most likely, but it has advantages:
It satisfies the Law of Demeter which basically states you have driver → tank → turret, and driver should not "reach through" tank to get at turret.
It avoids a messy triangle issue where the driver, tank and turret have a nonlinear dependency which can complicate construction, usage, and referential integrity. For example, you might have a driver have a tank and turret, and the tank has a different turret than the driver. This would be a bug.
It avoids or simplifies generics/templates which may be employed to allow the tank to tell its driver what type of turret to expect, given that tank is a general-purpose class.
But wait, now the tank has to know the turret's interface and expose only those methods that make sense! That goes against the point of using composition like this!
I recommend exposing all turret methods and have nonsensical ones simply do nothing. Again, not quite ideal, but it will make your professor happy because of the Law of Demeter.
Pseudocode for forwarding turret requests through the tank:
interface Turret {
void firePrimary();
void fireSecondary();
// and the other methods in your diagram.
}
class Tank {
Turret turret;
Tank(Turret t) {
turret= t;
}
void firePrimary() {
t.firePrimary();
}
void fireSecondary() {
t.fireSecondary();
}
}
You could have Tank implement the Turret interface, that is up to you. It can be convenient, but can potentially allow Tank to be misused:
Tank has-a turret, so it makes sense from an OO perspective that you can tell a tank to do "turret stuff" and it will pass those commands through.
One could misuse tank by adding another tank as its turret: tank → tank → turret, which is nonsensical. Having compile-time protection against this misuse by using the static type system is a good thing.
There are arguments for and against tank implementing turret, or having the tank return its turret for the driver to use. What you will learn is there is no one correct way to design and implement this: there are only tradeoffs. On one end of the spectrum you have "pure" OO which is what your professor is likely trying to teach you. On the other end of the spectrum are you "mostly" OO designs that have little fudges here and there to make life easier. This is a bit of a tangent, but I bring this up because this is an assignment and you will see real-world projects design more toward the "practical" end of the spectrum not the "theoretical" end.
I wrote up an answer to a different question which you might find helpful. The AI and user input approaches will necessarily require different inputs, making the example above a bit more complex (it is still a good start). If you look at the question/answer I linked you might learn a bit more about this approach.
