# Wilfrost

Members

8

142 Neutral

• Rank
Newbie
1. ## For Beginners: The Importance Of Object Oriented Design

This is good stuff, please keep it coming!
2. ## Should I dive into linear algebra or follow the prerequisite first?

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!
3. ## "Getters" and "Setters" - do you write them if you don't need them?

[quote name='jefferytitan' timestamp='1349687398' post='4987916'] [quote name='Wilfrost' timestamp='1349666150' post='4987848'] [quote name='Bregma' timestamp='1349665762' post='4987846'] 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. [/quote] I really like the way you stated that. I guess I have some thinking to do about the way my "objects" handle themselves. [/quote] 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. [/quote] 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. [quote name='iMalc' timestamp='1349763089' post='4988232'] I shall sum up my answer into one 5 letter acronym (google it): YAGNI! [/quote] I did, and it makes perfect sense!
4. ## "Getters" and "Setters" - do you write them if you don't need them?

[quote name='Bregma' timestamp='1349665762' post='4987846'] 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. [/quote] I really like the way you stated that. I guess I have some thinking to do about the way my "objects" handle themselves.