No they can't, but that doesn't stop him from logging in and doing it. =)

Regardless, thanks DigitalDelusion.

I think this issue is mainly coding style orientated - some people just like to think that it's either their way or the highway.

Quote:Original post by Wavarian
I really see the advantages of posting anonymously. Not only are you able to cut down anyone you see fit, but you can also rate them down on the side.

Real mature.

Just so you know, I did *not* rate you down.

If you are going by the least amount of code writing or using a public member variable then why even use a class? That's a dumb reason to say that getter/setter methods are bad design.

If you want to do OOP then use a private variable with getter/setter methods where needed. With a private variable and getter/setter methods you are encapsulating the variable so that you can control who can access it, validate any changes to it, and keep the public interface consistent so you can change the internals of the class at any time.

Those who say to make it public don't understand the benefits of OOP. Again, you might as well not use a class at all in that case. And just because you use getter/setter methods doesn't mean you have a bad design. I would argue that public variables are bad design because they go completely against OOP design. Even having getter/setter methods on something trivial is good, if you need to access or set the variable, because if your needs ever change or you decide to validate what the variable is set to, you can just change the setter method and the interface doesn't change.

An easy example with the health example used earlier is that anyone would be able to set the health to any amount if it were just public! How ridiculous. With a setter method you could validate that the health was never set above 100 (or whatever value you deemed reasonable). And if your max value ever changed, you could change that as well without changing every other bit of code you wrote.

I can never understand how people would say using getter/setter methods is automatically bad design. That's one of the main design patterns of OOP. And its advantages are numerous.

- Kevin

[EDIT]: Another example, let's suppose you decided you wanted to alert the player when the health went under a certain value. With a set method (although other methods such as subtractHealth or what-not might be better, let's keep it simple) you could check to see if the health was below the value you wanted to alert at and then alert the player, with no changes to your calling code.

Not to but in or anything, but I just wanted to point something out:

Quote:
[EDIT]: Another example, let's suppose you decided you wanted to alert the player when the health went under a certain value. With a set method (although other methods such as subtractHealth or what-not might be better, let's keep it simple) you could check to see if the health was below the value you wanted to alert at and then alert the player, with no changes to your calling code.

This is called an event, and doesn't belong in the class in the first place, since it's dependant completely on its environment. For example, using your subtractHealth method to alert the player may be useful in the game, but it creates more dependencies when you want to reuse the 'Player' class in other programs, e.g. a level editor, or another game that doesn't need to alert the player.

Anyway, just wanted to point that out.