For my games state check I’ve decided to use the super class LifeForm instead of writing more lines to test for baddie and player class which both extend LifeForm(for the parameter)?
The State check test if the player/baddie is asleep, poisoned, etc it also counts down the timer of the HealthState class which controls what each state does.
I thought about make a class for each aliment but I figure that would be more need for a bigger project.
Thanks for the information in advance
Since a subclass has all the variables and methods of the superclass (though it can not necessarily access all of them) you could always use “this” instead of super which is much better practice.
I had a hard time understanding what you were trying to do with your “statecheck” function or where that function is, but maybe try putting that function in life forms or use lots of is-accessors such as “isPoisened()” in the super class and have them return booleans, and maybe interfaces like “poisonable” if not every life form can be poisoned for example.
The later way would be the most correct for a object-oriented language, but using this instead of super should suffice.
thank you for the information, weather I use it here or not it’s good to know.
lets see if this clears my question up.
The player class extends LifeForm and the aliment is stored in LifeForm(now).
The Baddie class also extends LifeForm so as to make it so there was one check method for the both of them is it fine if I the super class LifeForm as the parameter instead of the player or baddie class.
checkState(player);//calling method with the reference to the player class being passed in.
public void checkState(LifeForm form){
//check this beings state
}
I feel like I’m doing alot of Object Orientated programming no nos but this is the biggest project I’ve done where I wasn’t coping out of a book.
[quote]is it fine if I the super class LifeForm as the parameter instead of the player or baddie class
[/quote]
That is perfectly acceptable as long as the stuff in LifeForm is relevant to all LifeForms, and not specific to a type of LifeForm, such as Player, as that kind of data should belong in the Player class. This is what inheritance is all about.
Basically:
LifeForm class: contains things that all LifeForms have
subclasses of LifeForm: inherit stuff from LifeForm, and also define their own specific behaviors.
You seem to be on the right track. Good luck with your project 
Ok i understand now :), and yes that’s the point of polymorphism so that is the right way to do it
Oop inheritance isn’t to avoid boilerplate code - only inherit when it makes sense. This is one of the most common misuses of oop.
I’m not really sure exactly what you’re doing (it sounds fine), But if it’s just to avoid work I would consider it more closely.
I think he has come up with a very good solution to his problem
instead of doing
void doSomething(Player player);
void doSomething(Monster player);
The following is of course much better if both methods from above do exactly the same.
void doSomething(LifeForm player);
@Jeremy
I think you a totaly wrong. Although I mainly use interfaces and only in very rare cases normale inheritance, this is what everything is about. You make everything generic and abstract so you have to write code only once.
I think you are totally wrong in contradicting my point. Though what you say (other than your statement that I am wrong) doesn’t contradict what I am saying.
You don’t have to only use interfaces to write proper OOP code. Inheritance isn’t to avoid rewriting code - if that is the case then you should use composition - but inheriting an object just so you don’t have to rewrite or to implement functionality you don’t want to rewrite completely destroys the design.
Think of it - you are providing access to your super where it doesn’t make sense - if inheritance doesn’t make sense and you are only doing it to avoid boilerplate code - this is exactly what you are doing. What if you have a class called Door, that has the method ‘attack’ and ‘getHealth’ inherited from it’s super because you inherited GamePlayer so you wouldn’t need to rewrite some entity management code. That’s an extreme example I admit but it makes the point that inheritance is not to avoid boilerplate code. Only inherit when it makes sense.
If something is not a game character, don’t inherit it.
If something is not an entity (but you want access to something implemented in Entity) don’t inherit entity.
If you are writing a class door, it makes sense to inherit Actor which inherits Entity because a door is an entity, and a door is an actor (entity with visual representation - i.e an ‘actor’ in the world)
Once you get something like ‘door’ you’ve essentially reached a point where you want to look into sealing the class - since it doesn’t make sense to inherit from something as specialized as a door.
When we start talking about private inheritance and protected inheritance (which doesn’t exist in Java - but does in i.e C++) that’s a whole other story since you aren’t exposing the object as an instance of what you are inheriting - so there isn’t a door open for misuse.
Why isn’t this player.checkState()?
Presumably because checkState has more to do on ‘this’ before it has to move on to whatever player has to say about it. When you need polymorphic behavior for the same operation on more than one object, the elegant solution is multiple dispatch, but since Java doesn’t have that, you need to rely on workarounds like double dispatch instead.
It’s hard to tell what’s appropriate here because the method is so vaguely named (hint hint).
Thank-you this is all great information.
I have a class called battle which takes in player, input(scanner), baddie
checkState is a method in the battle class that looks like this
private void checkHStates(LifeForm form) {
if(form.HasState == true){
form.getCurrentHState().go(form);
form.getCurrentHState().coutDown();
if(form.getCurrentHState().countDownZero() == true){
form.removeHState();
}
}
/* if(player.HasState == true){
player.getCurrentHState().go(player, null);
player.getCurrentHState().coutDown();
if(player.getCurrentHState().countDownZero() == true){
player.removeHState();
}
}
if(baddie.HasState == true){
baddie.getCurrentHState().go(null, baddie);
baddie.getCurrentHState().coutDown();
if(baddie.getCurrentHState().countDownZero() == true){
baddie.removeHState();
}
}
}*/
}
the commented out is what was before I thought to myself if they both are doing the same thing shouldn’t I just add this to the super class and not to each of them.
I do realize this has limits at the moment but its the best I could think of and I want to move to a “simple” gui as the next step. This project is more about learning then anything else. Since like I said this is my first big project not out of a book.(I made a simple randomizing list program that has a simple gui but that was like one class so yeah)
Again thank you every one
[quote=“Danny02,post:7,topic:43555”]
Well, you could do that - or you could choose to get something done. Interfaces are great for a lot of things. All I’m saying is that it isn’t all black and white. Besides, if you’d really write code only once - you’d still be stuck with your primitive scribblings of when you first started programming.
While I agree you have to learn to walk before you run, it’d be kind of nice if people stopped dismissing the idea of running altogether. Or at least accepted that walking involves putting one foot in front of the other in a particular way, as opposed to, I dunno, randomly wiggling your feet around as long as you stay upright. Sometimes there really is a right and wrong way to do things.
Not going after anyone in particular here, despite quoting you – just about keeping some context is all. Just wanted to get the sentiment off my chest. Now that said, my experience is that reusability isn’t so important as composability. You don’t need so much to reuse the exact same code as the really abstract concepts behind the code, and discovering those abstractions usually involves doing a lot of rewriting of your app code so you discover what they all ultimately have in common.