Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Wilfrost

Member Since 06 Oct 2012
Offline Last Active Nov 28 2012 09:50 PM

Posts I've Made

In Topic: For Beginners: The Importance Of Object Oriented Design

13 October 2012 - 01:04 PM

This is good stuff, please keep it coming!

In Topic: Should I dive into linear algebra or follow the prerequisite first?

12 October 2012 - 10:17 PM

It has been years since I took linear algebra, but I don't *remember* needing anything more advanced than Calc 1. Also, if you are planning on teaching yourself linear albegra, the worst that can happen is you get to something you don't understand. If that is the case, you can always come back to it after you get through your calc 2 class. This seems like a situation where you have very little to lose and a whole lot to gain! I'd go for it. Good luck in your studies!

In Topic: "Getters" and "Setters" - do you write them if you don't...

10 October 2012 - 01:57 PM



If you're writing software using object-oriented techniques, you rarely need getters and setters. Conversely, if you have a lot of getters and setters, you're not using object-oriented techniques, you're doing structured procedural programming. Don't fool yourself that because you use the 'class' keyword you're necessarily doing anything object-oriented.

An object-oriented ball doesn't ever need something else to tell it what its size is. Nothing else needs to know its size. It knows how to collide with walls and paddles. It knows how to draw itself.


I really like the way you stated that. I guess I have some thinking to do about the way my "objects" handle themselves.


Yes and no. I agree that other classes shouldn't be calculating using the ball size, e.g. doing collisions for the ball, etc. However no class is totally self contained. The ball needs to get it's size from somewhere, e.g. a constructor. Changing the size at runtime could be useful, e.g. power-ups that make it easier/harder by changing the ball size.


That is exactly how I was looking at it. I may want to implement a powerup where the ball get's bigger, smallet, whatever... And for that I would need to set the ball's size, so I would have to write a setSize() function. Along the same lines, my ball needs to know where the paddles are for collision detection, so my paddles need "get" functions for their xLocation, yLocation ,height, and width variables. The ball is still detecting for itself when the collision is happening, and it is reversing its own direction, but it has to get that information out of the paddle through four get functions.

As a side note: Some of my classes have attributes that are used only within the class and will never ever ever need to be influenced directly from outside. I do not write setters / getters for those.

I shall sum up my answer into one 5 letter acronym (google it):
YAGNI!


I did, and it makes perfect sense!

In Topic: "Getters" and "Setters" - do you write them if you don't...

07 October 2012 - 09:15 PM

If you're writing software using object-oriented techniques, you rarely need getters and setters. Conversely, if you have a lot of getters and setters, you're not using object-oriented techniques, you're doing structured procedural programming. Don't fool yourself that because you use the 'class' keyword you're necessarily doing anything object-oriented.

An object-oriented ball doesn't ever need something else to tell it what its size is. Nothing else needs to know its size. It knows how to collide with walls and paddles. It knows how to draw itself.


I really like the way you stated that. I guess I have some thinking to do about the way my "objects" handle themselves.

In Topic: "Getters" and "Setters" - do you write them if you don't...

07 October 2012 - 09:10 PM

Why write a function for something that's never going to change? While this may not occur much in the home-brew & hobby-est areas, I feel that you're adding the ability to mess with your game. You're just asking someone to abuse a function that was never meant to be used.


I guess I just have this little voice in the back of my head that says "Hey, you might want to have control over that some day... better write a set function for it"

Sorry if this reads weird - I have a bloody headache. :/


Hope your head feels better!

"Getters" and "Setters" are an interface to the data contained in your class. It is typically good practice to do this when you allow data in the class to be accessed externally.
For instance if you had a variable in your Ball class named "speed", you may want to increase this as the game goes on longer. This would require a setter because the game needs to externally increase it. Then lets say you would like to check to see if the ball is off screen. This would require a getter for the position to figure out where the ball is.
Of course you could make the data public in the class but this is considered bad style and should be avoided except when absolutley necessary.

If it is only used in the class and never changed outside the class it should not have a getter or setter.

Hope this helps.


I does! I appreciate everyone's opinion on the subject.

If you do have a class that needs to have a lot of accessible/modifiable attributes, consider just using a struct with public data members and no functions.


Are structs still around? I know that you can *technically* use them in C++ but I've never seen them called for in any C++ book I have, and tbh I have NEVER seen a struct used in Java - the language I have the most experience in (which is not saying much).

Thanks for all the great insights everyone, keep them coming!

PARTNERS