Non private privacy
Author
What if your input/event data haseth private data, rather than easy-to-work-with key[VK_..] globals? You would still need to use some GetThis and GetThats in that UpdateColor() function. Also, some people, most of which reside in this forum, would yell at anyone trying to mess with keyboard data in a car class ;)
Quote:Original post by Kest
What if your input/event data haseth private data, rather than easy-to-work-with key[VK_..] globals? You would still need to use some GetThis and GetThats in that UpdateColor() function. Also, some people, most of which reside in this forum, would yell at anyone trying to mess with keyboard data in a car class ;)
Uhm, the above was just a quick example to make my point. I didn't say you would actually handle keyboard input like that. The point is that the car class is the one that requests from a "painter" module to alter its color.
Quote:Original post by Kest
The color of the car is not very internal. But again, I totally follow you and completely agree. It's just that many external states are stand-alone states.
True. The question is, can you always be sure that they'll *stay* stand-alone states? What if, at some point in the future, you decide that red cars can go faster? Everyone knows that's true anyway. [lol]
Now, if you'd used a setter all along, you could simply modify it to adjust the car's maxspeed variable when the color changes. If you were accessing the color directly, it gets messier.
Yeah, I know, another awfully contrived example...
I guess the point is just that it's usually "better" not to use expose members of a class. Especially by making them public, but setter functions are also typically a sign that something is wrong.
But yes, you're right, that's not *always* the case, and you're right, it *is* sometimes easier to just make the damn thing public... [grin]
As long as you understand the reasons why you *shouldn't* do it, you can always decide when to break that rule. Most rules need to be broken every once in a while. [lol]
At any rate, I NEVER write get or set in a function name. If I need that behavior, but still need to hook in behavior when the variable is changed, I will disquise a private member as a public member.
class foo{private: int private_m; void hook_m_assign(); void hook_m_accessed();public: Property<int,hook_m_assign,hook_m_accessed> m;};
Author
Quote:Original post by mikemanQuote:Original post by Kest
What if your input/event data haseth private data, rather than easy-to-work-with key[VK_..] globals? You would still need to use some GetThis and GetThats in that UpdateColor() function. Also, some people, most of which reside in this forum, would yell at anyone trying to mess with keyboard data in a car class ;)
Uhm, the above was just a quick example to make my point. I didn't say you would actually handle keyboard input like that. The point is that the car class is the one that requests from a "painter" module to alter its color.
But your example was to show why Get and Set are not needed. What if your keyboard class, or whatever input or event system you use to update color, has it's own private data? In other words, your virtual Color UpdateColor(Color color) either needs more input params, or needs to access a global. And in either case, you need to use a Get method to see if the event is true. Or in other words, Keyboard->GetKeyValue(VK_DOWN).
Quote:Original post by Deyja
At any rate, I NEVER write get or set in a function name.
Just avoiding the name doesn't really accomplish anything, does it? What about the example I gave earlier? GUI.SetForegroundColor()? Or GUI.SetFont()? What clever interface names are there for these actions that would make the GUI system feel more like a machine with buttons?
Quote:If I need that behavior, but still need to hook in behavior when the variable is changed, I will disquise a private member as a public member.class foo{private: int private_m; void hook_m_assign(); void hook_m_accessed();public: Property<int,hook_m_assign,hook_m_accessed> m;};
Looks like that's just more work. What is the advantage?
Author
By the way, in case anyone is curious, I did obtain an answer to my original concern. Why make interfaces for data even if it's safe, doesn't need converted, and making it public doesn't change anything? Because the object may need to change later. Pretty simple, and there may be situations where you're 99% positive the object will never change. But even the 1% makes it feel more worth-while to stick to the rules.
Thanks
Thanks
Quote:Original post by KestQuote:Original post by Deyja
At any rate, I NEVER write get or set in a function name.
Just avoiding the name doesn't really accomplish anything, does it? What about the example I gave earlier? GUI.SetForegroundColor()? Or GUI.SetFont()? What clever interface names are there for these actions that would make the GUI system feel more like a machine with buttons?Quote:If I need that behavior, but still need to hook in behavior when the variable is changed, I will disquise a private member as a public member.class foo{private: int private_m; void hook_m_assign(); void hook_m_accessed();public: Property<int,hook_m_assign,hook_m_accessed> m;};
Looks like that's just more work. What is the advantage?
With Deyja's approach, and a carefully designed templated Property class, calling code gets to refer to m as if it were a data member, even though it isn't. Thus, the foo class is free to switch implementations between the property-backing-private member and public member, and the client code is presented a simpler abstraction.
That said, I don't agree with banging this out automatically: start out with the public member until usage dictates otherwise. Of course, that's assuming that your *design* concluded that there isn't a good solution to having a "public member interface" in the first place.
Most C# code I've seen is littered with this kind of stuff and it reeks to me of premature generalization.
Quote:Looks like that's just more work. What is the advantage?
I was being facetious. What you can take from that example is that it's easy to retrofit code later without changing the callers. As for the gui example; I'd just have a public color member.
Quote:
But your example was to show why Get and Set are not needed. What if your keyboard class, or whatever input or event system you use to update color, has it's own private data? In other words, your virtual Color UpdateColor(Color color) either needs more input params, or needs to access a global. And in either case, you need to use a Get method to see if the event is true. Or in other words, Keyboard->GetKeyValue(VK_DOWN).
I should have said from the beginning that I don't consider getters a problem. Or course there's no harm about querying an object like Keyboard about its state. What I want to avoid, as I said, is setting the state of an object(Car) in "illegal" places.
For the keyboard example, a more appropriate function would be 'bool is_key_pressed(keycode)'.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
