Question on methods in Object Oriented Programming [closed]

I’m learning Java at the minute (first language), and as a project I’m looking at developing a simple puzzle game.

My question relates to the methods within a class. I have my Block type class; it has its many attributes, set methods, get methods and just plain methods. There are quite a few.
Then I have my main board class. At the moment it does most of the logic, positioning of sprites collision detection and then draws the sprites etc...

As I am learning to program as much as I’m learning to program games I’m curious to know how much code is typically acceptable within a given method. Is there such thing as having too many methods?

All my draw functionality happens in one method, should I break this into a few ‘sub’ methods? My thinking is if I find at a later stage that the for loop I’m using to cycle through the array of sprites searching for collisions in the spriteCollision() method is inefficient I code a new method and just replace the old method calls with the new one, leaving the old code intact.

Is it bad practice to have a method that contains one if statement, and place the call for that method in the for loop? I’m very much in the early stages of coding/designing and I need all the help I can get! I find it a little intimidating when people are talking about throwing together a prototype in a day too! Can’t wait until I’m that good!

• I think this belongs on SO. This is too much of a general programming question. Jun 27 '11 at 13:16
• @heishe No, it's pretty specific to gamedev. Jun 27 '11 at 13:54
• @The Communist Duck The fact that you could substitute anything gamedev related with something else in his text (and that his tags are not gamedev related at all) shows that it's not actually a game dev question. But nevermind now. Jun 27 '11 at 14:52
• This is not a game dev question but more of a generic programming question couched as a gamedev question. Jun 27 '11 at 15:56
• Flagged as off topic. While he is asking with a render loop in mind the questions are general programming and the answers would likely benefit more from being on SO. Jun 27 '11 at 16:04

Don't ever follow any "coding-best-practice" from books or individual without understanding the underlying purpose. Keep questioning WHY before you BUY.

1) METHOD SIZE: There are no standard rules for method size. The following things have helped me in managing them.

Lines: I believe that if the methods have less than 15 lines of code, it would be readable and manageable. It doesn't mean that one has to stick to this number. Let's not break a 20 lines method into 2 different 10 lines methods and compromise the readability.

Method Naming: Yes! Method naming helps to maintain the size of a method. Name a method in such a way that it does a single action. Try to avoid "and" in method names. Then don't add even a single line of code in that method which does something other than what your method name says. Its always tempting to give some name that comes to our mind immediately and jump to the implementation. But it is important and okay to spend some time in choosing a right name for a method.

2) With respect to your draw method, can you post your code so that we can discuss about it specifically.

3) Calling "if method" in a for loop: Generally, there is no problem in calling a method from a for loop. I hope you are not talking about performance here. There might be some room for improvement w.r.t. complexity, but it depends on the actual code.

And yeah, this is not a game development related question. You would have more people to help you in Software development exchange :)

• Thanks for the post, I'll add the code when I get a chance
– mal
Jun 28 '11 at 20:02

1) No, you cannot have too many methods. However, having a large amount could be a bad design. If there's a function which does one very simple line and is only accessed internally, why does it need to be a method? Could you replace getters and setters with a public variable?

2) Not really. There's little point in it being a method, so you may want to change that - unless it does something specific that you may need again.

In terms of design as a whole, I would say 50% is common sense and the other 50% is knowledge, be it from other bits of code, questions like this, and other material. It makes no sense to force everything to a design.

• I would disagree with changing getters and setters to public members. If anything, it should be a warning that you're not being very OO by having all your data exposed for anybody to mess with. I'd rather ask "how many of your setters really need to be public?". Jun 27 '11 at 16:59
• @Tetrad I said could, because bounds checking and stupid arguments (-10 health) can be avoided that way. If you're just doing a straight 'x = value', then there's little point..if it's something like a position, there should be no problem. Jun 27 '11 at 17:17
• If your exposing your 'private' variable through remedial getters and setters. Then what was the point of implementing the methods? Getters and setters should only encapsulate the class if you want different behavior from typical assignment. Jun 29 '11 at 3:01
• Hi Daniel, can you expand on your comment a little further please?
– mal
Jun 29 '11 at 15:52
• @mal I may not be Daniel, but the point is if you're just getX and setX, where you're directly assigning to X, there's no point in it being private. Why not access it directly for ease of use? If, however, you check that the value passed in is not above 50 or below 0, then that is a use for setters - and therefore you will need setters too. Jun 29 '11 at 16:58