Jump to content
  • Advertisement
Sign in to follow this  
nGamer

[C++, Oop] Setters Vs. Friend Functions

This topic is 862 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys,

 

In a situation where one needs to design an object that has various things done to it, what are the pros and cons of using setter methods vs. external friend functions. For example, let's say you're making a game, and objects need to be drawn to the screen. What would the differences be in having the object draw itself with a draw () method in the object class versus having a drawObject () friend function that takes an object and as an argument and draws it?

Edited by nGamer

Share this post


Link to post
Share on other sites
Advertisement

Hey guys,

 

In a situation where one needs to design an object that has various things done to it, what are the pros and cons of using setter methods vs. external friend functions. For example, let's say you're making a game, and objects need to be drawn to the screen. What would the differences be in having the object draw itself with a draw () method in the object class versus having a drawObject () friend function that takes an object and as an argument and draws it?

I think you'll get better answers/interest with a more appropriate topic title.

 

Having objects draw themselves I feel is the simplest method and if your scope is small it's probably the better option. The down side of that is that you have render code sprawling all through your code and it becomes quite tightly coupled which is a problem for things like multi threading or targeting multiple graphical APIs. It also limits the amount of optimization you can do.

 

I'm sure there's plenty more but those few stand out to me. 

Share this post


Link to post
Share on other sites

In C++, "friend" is a keyword you should never write.  

 

It is something that you might be forced to write when you cannot come up with a better solution, and even then with a great big comment in the code saying "someone help fix this awful situation".  I can't recall using the keyword in code for well over a decade, about 2002 or 2003; that was for a bunch of code that we didn't have the ability to modify for political reasons so we used language-lawyering to get it done.

 

You say you have a collection of actions you want to do.  That is perfect. 

 

Provide an interface to take those actions.  Describe all the actions in the interface. Keep that interface abstract.  Then create an implementation that implements the interface.  Anywhere you code, rely on the abstract interface. Provide a factory method or similar to create and retrieve your concrete implementation.

Share this post


Link to post
Share on other sites

If you have an object which is a bag-of-values, just make them public and write to them. Why bother with function authoring and then calling overhead if you're just going to put integers into integers?

 

There's nothing wrong with bag-of-value objects; just don't go around thinking that putting lots of boring boilerplate getter-setter methods in there somehow does anything magically OO for your design. All you're doing is writing a bunch of code which, if you're lucky, the compiler will just throw away for you.

Share this post


Link to post
Share on other sites

If you have an object which is a bag-of-values, just make them public and write to them. Why bother with function authoring and then calling overhead if you're just going to put integers into integers?
 


As a general rule, if you're writing a class that has a bunch of setter/getter methods then you're probably doing it wrong.

But in the real world, you sometimes end up with "wrong" code.

Let's say you have the following scenario:

The code is failing somehow (crashing, doing the wrong thing, whatever). You break out the debugger and discover that foo.bar is 41 instead of 42! Something is changing that value.

Now you have two possible options: either you check everywhere in the code where foo.bar is assigned (and praying there isn't an alias to it somewhere you missed)

Or

You put a breakpoint in Foo::SetBar (possibly even conditional on bar != 42).

I know which one I'd rather deal with.

C# style auto properties are a really nice way of handling this.

Share this post


Link to post
Share on other sites

"You put a breakpoint in Foo::SetBar "

 

What's wrong with putting a watch on the foo.bar?

 

Most modern debuggers will quite happily let you say "break when value X is written to this".

 

Bag of values. If you want to watch for changes, watch the values.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!