"Getters" and "Setters" - do you write them if you don't need them?

Started by
40 comments, last by TheChubu 11 years, 6 months ago

First I will answer your question.
No you don't need to write setters and setter for every field in your class. Only if think you are going to use them or have the need for them to be public.
Making such decision is all up to you and is called software design. Use your logic to layout the classes in such way that they will work together but also will not cause problems behavior wise when you are able to modify properties publicly.

As for getters and setters them self. I have feel obligated to say they are not so great as every body might think. Actually they are even evil. First of all for the fact that most people never put anything in a getter setter block besideds passing true a value which is actually just mindless typing working which doesn't make sense at all.
Secondly for the fact that getters and setters are no more than syntax sugar in the end it is a function that return a fields value and set a value using function. With that said it more logical to make a function/method that has a better description about what the operation is going to preform on a class.

Compare the following example
[source lang="java"]

spaceship = new SpaceShip(imgSpaceShip, posx, posy);

if( spaceship.x < screen.width)
spaceship.x += speed;

if( spaceship.Y < screen.width)
spaceship.y += speed;

[/source]

to..

[source lang="java"]

spaceship = new SpaceShip(imgSpaceShip,posx,posy,speed);
spaceship.move(screen);

[/source]

This is a small part pseudo code that reflects real good what I mean that using getters and setters does not promote better software design. It is not even considered OOP.
I used to be a big fan off getters and setters until I starting using more languages that had no syntax sugar for getters and setters. At first it hated it then i found out that I wrote better OOP and made less mistakes due better open close principle and that methods attached to classes where better descriptions on them self. If you would still feel the need for model / object to have mainly public properties you might think of using a struct. Therefor I have to disagree with people in this thread whom claim that structs and classes are the same this is simple not true.


I agree totally with this idea. It is quite the same what I also said. It's much better design, if you put logic under a function inside the class rather than passing values in and out via getter and setter and do the logic outside of the class.

Also Baase and Van Gelder refers to this design in the "Computer Algorithms: Introduction to Design and Analysis" book.
See my game dev blog: http://gamedev4hobby.blogspot.fi/
Advertisement
Another newbie here finding it hard to grasp these object oriented principles. I think I understand the core idea but extending it to practical applications leaves me confused everytime as to what data should be public or private, or where interfaces should be etc:

As an example, a platform game. When an actor moves it needs to find the actors and tiles nearby to collide with (stored in a World object say). When it collides it needs to know the exact position of the other actor, plus what kind of shape it is, and how the collision will be resolved (moving the shape back maybe). How should access to this information be handled? Where should the code that is calculating the collision be contained in and run from?

Sorry if these questions sound dumb but this stuff leaves me completely lost :/

Another newbie here finding it hard to grasp these object oriented principles. I think I understand the core idea but extending it to practical applications leaves me confused everytime as to what data should be public or private, or where interfaces should be etc:

As an example, a platform game. When an actor moves it needs to find the actors and tiles nearby to collide with (stored in a World object say). When it collides it needs to know the exact position of the other actor, plus what kind of shape it is, and how the collision will be resolved (moving the shape back maybe). How should access to this information be handled? Where should the code that is calculating the collision be contained in and run from?

Sorry if these questions sound dumb but this stuff leaves me completely lost :/


First, the public vs. private argument. I'm fairly new to programming myself, but in general, from what I've read, I make everything private unless I'm given a compelling reason to do otherwise.

In your example, the "actor" would not need to find the other actors. In fact, it shouldn't really even know they exist. All this should be handled by some other physics engine, which handles all the actors, and calculates colisions. When a colision occurs, it calls the necessary method on the actor. i.e. changing movement speed/direction. The actor really only know where it is, and how to move. The physics engine gives it the specifics. Similarly the actor shouldn't know about keyboard inputs, gravity, or anything like that.

When an actor moves it needs to find the actors and tiles nearby to collide with (stored in a World object say).


That's why actors don't move themselves. Something moves them (and can then know enough to handle collision between actors).

Unfortunately, much of OOP turns out to be a bad idea. Not everything is an object. Objects shouldn't necessarily contain all of their state and behavior. These are traditional concepts that are unfortunately still taught heavily at universities.

The focus should be on the SOLID principles. These are more general principles that are great for OO as well as other paradigms. They've evolved over years of use (and academic study in some cases). Hope they help.
What about the actor sending itself to some World interface to be moved during it's Update() (like World.MoveActor(this)) ?
IMO, an actor should not reference objects at a higher level than itself, including the world.

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


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.


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


I did, and it makes perfect sense!

IMO, an actor should not reference objects at a higher level than itself, including the world.


I fully agree with you on this but still I would see this a design decision.


[quote name='zqf' timestamp='1349878892' post='4988728']
When an actor moves it needs to find the actors and tiles nearby to collide with (stored in a World object say).


That's why actors don't move themselves. Something moves them (and can then know enough to handle collision between actors).

Unfortunately, much of OOP turns out to be a bad idea. Not everything is an object. Objects shouldn't necessarily contain all of their state and behavior. These are traditional concepts that are unfortunately still taught heavily at universities.

The focus should be on the SOLID principles. These are more general principles that are great for OO as well as other paradigms. They've evolved over years of use (and academic study in some cases). Hope they help.
[/quote]

Yet again I agree with this too but this pore guy just got flooded with advanced practices. I tried to keep the answer with in context of his question ;)

[quote name='zqf' timestamp='1349878892' post='4988728']
When an actor moves it needs to find the actors and tiles nearby to collide with (stored in a World object say).

That's why actors don't move themselves. Something moves them (and can then know enough to handle collision between actors).

Unfortunately, much of OOP turns out to be a bad idea. Not everything is an object. Objects shouldn't necessarily contain all of their state and behavior. These are traditional concepts that are unfortunately still taught heavily at universities.

The focus should be on the SOLID principles. These are more general principles that are great for OO as well as other paradigms. They've evolved over years of use (and academic study in some cases). Hope they help.
[/quote]
This. A billion times. Naive OOP works fine some of the time, but as soon as you hit an edge case, things start breaking down, patterns fail and the next thing you know, you're using world callbacks in your entities.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

How about the world holding a list of movers that it calls when it updates? Objects that want to move would add themselves to this list, that sort of thing?

This topic is closed to new replies.

Advertisement