Jump to content

  • Log In with Google      Sign In   
  • Create Account


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
41 replies to this topic

#41 slayemin   Members   -  Reputation: 2408

Like
1Likes
Like

Posted 12 October 2012 - 03:25 AM

Can I hijack this thread a little?

Now, in uni we're being taught OOP, using Java. One thing that I didn't quite understand (and if I did, then I disagree) is making (protected) setters of the (private) attributes of a class for using them in the constructor of the same class.

What's going on there? Encapsulating the class from itself?

IMO looks useless and inefficient. The first thing that comes to mind when I think "What could have free access to this class's properties?" is the constructor. Why should need to use methods to access the class's attributes its trying to construct? It's one of those "It's in the paradigm!" things? Moreover, the classes that inherit from such class will also carry the "burden" of accessing itself through methods instead of simple direct attribute access.

I'd just use the getters and setters if I need to access the class's attributes from outside the class. It doesn't makes any sense to me to encapsulate the class from itself on constructors nor methods (except some "high risk" public method that could screw up the object that is, but probably that one should be implemented as a separate class anyway).


Let's review access levels:
Public: Everything can access this member function or member variable
Private: The member function/variable is only internally visible to the class
Protected: Publicly accessible by classes which inherit from this class, hidden from all other classes.

So, if you make the internal variables private and the accessors are protected, you're creating a layer of insulation between the internals of your class and any classes which want to inherit from it. This is handy for doing error checking to make sure that class data conforms to the class logic.

To OP:
Personally, I like accessor functions. I like to make a distinction between properties and methods in C#
//These should NOT be "methods" because it's not really doing anything complicated to the data. It's just exposing the data to public use.
public int GetX()
{
	 return m_x;
}
public void SetX(int value)
{
	 //arbitrary rule being enforced
	 if(value >= 0)
	 {
		  m_x = value;
	 }
	 else
	 {
		  throw new exception("X shouldn't be negative!");
	 }
}

//instead, I like accessors which make it clear that you're accessing and using a property
public int X
{
	 get{return m_x;}
	 set
	 {
		  if(value >= 0)
			   m_x = value;
		  else
			   throw new exception("blah blah");
	 }
}

Functionally, Get/Set methods are the same as accessors and can do some light error checking. But, I like to think of "functions" more as a set of instructions used to do operations on data. These sets of instructions are like a true, mathematical function and thus deserve the term "function" unlike simple get/set methods.
Example:
public int Mandelbrot(float px, float py)
{
	 float x = 0;
	 float y = 0;
	 int iterations = 0;
	 const int max_iterations = 100;

	 while((x * x + y * y < 4) && iterations < max_iterations)
	 {
		  float tempx = x*x - y*y + px;
		  y = 2*x*y + py;
		  x = xtemp;
		  iterations++;
	 }
	 return iterations;
}

The following advice may be frowned on or considered "bad", but its pragamatic:
If you're the only person working on a program, you can probably just let all of your class properties be public since you're the only one who will be using them. Nobody else is going to interfere with internal class data. I assume that you know what you're doing and how the class works internally when you're accessing variables which would otherwise be private. In general, the principle of "information hiding" is encapsulation in order to create a contract between the class creator and the class users. Since you're both creator and user, you probably don't need a contract with yourself (but you could treat your future self as a class user since you could forget implementation specifics).
If you're going to share your code, work with other people, or use it as a library, THEN it's a good idea to hide stuff you don't want people to access (to prevent other people from breaking your class). Generally, it's just a good habit to encapuslate data and expose it through methods and accessors (and to enforce validation on data that needs to be validated), but it can also be a waste of time if you're going solo. Use your best judgement.
Personally, I practice encapsulation and information hiding even on small personal projects. It's just a habit of discipline and helps manage where & how my classes are being accessed.

Eric Nevala

Indie Developer | Dev blog


Sponsor:

#42 TheChubu   Crossbones+   -  Reputation: 4062

Like
0Likes
Like

Posted 13 October 2012 - 03:40 PM

So, if you make the internal variables private and the accessors are protected, you're creating a layer of insulation between the internals of your class and any classes which want to inherit from it. This is handy for doing error checking to make sure that class data conforms to the class logic.

I've ended up using this kind of encapsulation and in that case I understand the idea behind getters, and setters in the constructors. I wouldn't want to have someone just extend some class and gain access to everything it has inside it right away potentially messing up the structure.

If you're going to share your code, work with other people, or use it as a library, THEN it's a good idea to hide stuff you don't want people to access (to prevent other people from breaking your class). Generally, it's just a good habit to encapuslate data and expose it through methods and accessors (and to enforce validation on data that needs to be validated), but it can also be a waste of time if you're going solo. Use your best judgement.

Yep, I agree with that. Though have in mind that I'm talking about getters and setters not as a whole but in the specific case of a constructor, It seems that it depends on what level of access you want to grant from the inherited classes (something I hadn't though about too much) and the kind of data validation you want to do in the methods (I prefer to validate the data before calling the constructor and/or methods of the object though).

Though for uni projects, getters and setters for everything in everything it seems! :P

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS