Accessing variables
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
He's right. For example, if you need to change something within your library, such as a datatype, you can make the necessary updates to handle the changes within the get/set functions, meaning that you never have to touch the code that's calling the library. If you access the variables directly, then if you make a change to that variable type in your library, you then have to change every single app that references that library.
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
BrockVnm wrote:
He says that you should always use get and set functions.
I totally agree, here's a subset of reasons: allows the class to change functionality without the application knowing/caring necessary for databinding to work in C# necessary for events to work on value changes allows internal implementation, such as data type, to vary independently of the application. allows for specialization (well, if the base class property setters/getters were virtual) interfaces support get/set (again C#), so you can use the class in a highly decoupled manner Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
I agree - "data hiding" as some call it is well worth the effort, as you can change the implementation later without breaking other code that relies on your classes. Plus you can choose to make some member variables read-only by only implementing a "Get" function, etc. Back when I was first dabbling with C++, I couldn't be bothered to spend time adding Get/Set functions and I came to regret it. You can also expand this some more - should, for example, code within the class use Get/Set methods to access the variables? I know someone doing a Java course at University and they insist that "getters/setters" are always used, and the only place a variable is referenced directly is when it is initialised in the constructor! Sure, there would be a performance hit, but if this isn't an issue, I know one or two people that would argue that this is a good thing. Also, what about derived classes? Do you make the variables protected, or leave them private and make the derived classes use Get/Set methods too? (I prefer the latter approach myself, but it is often a matter of taste).
The Rob Blog
Google Talk: robert.caldecott -
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
I am not sure, but here's Bjarne Stroustrup's opinion on the matter[^]: If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions and so on, and override it with the one and only representation. That's just elaboration. It's not necessary.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Unless they're declared
const, you should never make member variables publicly accessible. If you're working with a language that supports properties (like the .NET ones), it's not an issue because you can create properties for your fields and syntactically it will look as if you're accessing the variables directly. The compiler may even optimize the call to a direct access to the variable. Regards, Alvaro
... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds
-
BrockVnm wrote:
He says that you should always use get and set functions.
I totally agree, here's a subset of reasons: allows the class to change functionality without the application knowing/caring necessary for databinding to work in C# necessary for events to work on value changes allows internal implementation, such as data type, to vary independently of the application. allows for specialization (well, if the base class property setters/getters were virtual) interfaces support get/set (again C#), so you can use the class in a highly decoupled manner Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
Yeah, your subset reasons are more realistic than the generally given vague reason of hiding private member variables. To be honest though 99% of the time it's a waste to bother with the accessors for most stuff. I always do it that way, but for most code I always feel like "I'm never going to touch this again, why bother?" To me it's sort of a flaw in the language, you have to do it so often it's a lot of typing for little real world gain in most cases, there should be some other way to do the same thing by thinking outside the box in the language design itself.
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
I once had to fix program with the following global veriables: a, b, c, d, e, f, g, h, i :doh: The tigress is here :-D
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Only on exported types IMO, and that serves as a protective/notification measure. For internal (.NET) types, public fields are acceptable if you dont need measure above.
-
Yeah, your subset reasons are more realistic than the generally given vague reason of hiding private member variables. To be honest though 99% of the time it's a waste to bother with the accessors for most stuff. I always do it that way, but for most code I always feel like "I'm never going to touch this again, why bother?" To me it's sort of a flaw in the language, you have to do it so often it's a lot of typing for little real world gain in most cases, there should be some other way to do the same thing by thinking outside the box in the language design itself.
John Cardinal wrote:
To be honest though 99% of the time it's a waste to bother with the accessors for most stuff.
True. I'm slowly getting into the habit of providing OnxxxChanged event capability to a lot of properties, because the stuff I do often involves a lot of data binding, even when it's not visual properties.
John Cardinal wrote:
you have to do it so often it's a lot of typing
Indeed. Snippets are sort of useless for that, so I use QuickCode, which is adequate.
John Cardinal wrote:
to do the same thing by thinking outside the box in the language design itself.
Some of the AOP concepts come to mind. But yes, I imagine people 50 years from now will look at coding and roll their eyes the way we flinch looking at how programming was done by toggling switches 50 years ago. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
I have a question for everyone here. I am not sure if their is a proper way that this should be done or if it is more of a style thing. I have a senior developer that I work with that told me that you should never access any type of global/instance variables directly. He says that you should always use get and set functions. I was just wondering what every bodies take on this is. Thanks!! :-D
We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
First off, you should try to eliminate all global variables. Writing get/set functions for them shouldn't even be an issue. Second, to dogmatically make every class variable private/protected and provide a get/set for them is not the 'right way' (it is however a very pure OO way), there is no universal 'right way'. As a developer you are expected to think, understand, and implement the best solution for the situation. A given methodology is just another tool; you don't always have to use the same one. As a general rule i only hide a class variable and/or provide get/set methods for them if their value is intimately tied to other state (i.e. changing their value requires validation of other state), or a change in their value requires other code to be executed. For example,
class DbRecEmp {
...
string NameFirst;
...
};In almost every situation where this type of case has come up it has made no sense to make NameFirst private/protected and provide GetNameFirst()/SetNameFirst() methods. ...cmk Save the whales - collect the whole set -- modified at 13:25 Thursday 9th March, 2006
-
I once had to fix program with the following global veriables: a, b, c, d, e, f, g, h, i :doh: The tigress is here :-D
Jewish programmers get two more letters than English ones. I'm jealous. :rolleyes: Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
He's right. For example, if you need to change something within your library, such as a datatype, you can make the necessary updates to handle the changes within the get/set functions, meaning that you never have to touch the code that's calling the library. If you access the variables directly, then if you make a change to that variable type in your library, you then have to change every single app that references that library.