Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Is it bad practice to use the super class as a parameter.  (Read 864 times)
0 Members and 1 Guest are viewing this topic.
Offline cloudwindgate

Senior Newbie





« Posted 2013-08-14 01:48:59 »

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
Offline Simba Productions

Senior Newbie


Medals: 1



« Reply #1 - Posted 2013-08-14 02:00:13 »

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.
Offline cloudwindgate

Senior Newbie





« Reply #2 - Posted 2013-08-14 05:28:51 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online BurntPizza
« Reply #3 - Posted 2013-08-14 05:41:11 »

Quote
is it fine if I the super class LifeForm as the parameter instead of the player or baddie class

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  Wink
Offline Simba Productions

Senior Newbie


Medals: 1



« Reply #4 - Posted 2013-08-14 05:49:16 »

Ok i understand now Smiley, and yes that's the point of polymorphism so that is the right way to do it
Offline Jeremy
« Reply #5 - Posted 2013-08-14 05:57:08 »

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)?

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.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline Danny02
« Reply #6 - Posted 2013-08-14 08:06:11 »

I think he has come up with a very good solution to his problem

instead of doing
1  
2  
void doSomething(Player player);
void doSomething(Monster player);


The following is of course much better if both methods from above do exactly the same.
1  
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.
Offline Jeremy
« Reply #7 - Posted 2013-08-14 08:20:23 »


@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.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline pjt33
« Reply #8 - Posted 2013-08-14 09:25:20 »

checkState(player);//calling method with the reference to the player class being passed in.

public void checkState(LifeForm form){
     //check this beings state
}
Why isn't this player.checkState()?
Offline sproingie

JGO Kernel


Medals: 202



« Reply #9 - Posted 2013-08-14 15:34:36 »

checkState(player);//calling method with the reference to the player class being passed in.

public void checkState(LifeForm form){
     //check this beings state
}
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).  
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cloudwindgate

Senior Newbie





« Reply #10 - Posted 2013-08-14 17:06:54 »

@Everyone

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
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
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
Offline jonjava
« Reply #11 - Posted 2013-08-14 18:13:34 »

You make everything generic and abstract so you have to write code only once.

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.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #12 - Posted 2013-08-15 15:54:43 »

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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (13 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (31 views)
2014-08-16 06:45:27

Tekkerue (31 views)
2014-08-16 06:22:17

Tekkerue (19 views)
2014-08-16 06:20:21

Tekkerue (29 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (42 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!