tank.FireProjectile(Direction("North-westerly"));

Honestly I like returning pointers for most cases. Using the pointer you dont have to make a thousand function calls. Especially in parallel programming this is very useful when you want to avoid static variables. Sometimes its not a good idea, or not even possible depending on the use, but I believe this is a perfectly valid programming habit. IMO

You do realize that that method destroys your ability to enforce class invariants? And that it has no advantage over simply making your members public (and has the disadvantage of being clunky and a really non-obvious and non-idiomatic way of modifying an object)?And that this doesn't do anything to help avoid static variables (how is this even related to static variables?)?

There might be a few exceptional cases where it's a decent idea, but it should be just that, exceptional cases. If it's your preferred/common method... something is wrong.

It is all dependent on what it is you are programming and what the expectations of that program are. To say their are only a few exceptional cases where you would return a pointer and that it has no advantages is purely based on ones own perspective.

My current, long term project is a game engine I have been working on for some time now. The overall goal is parallelism. Being able to pass off a single object pointer to multiple subsystems so that each can do its work at the same time, to me, is an intelligent design. Whether it is the object itself, or maybe just the draw location of a game entity being passed to the physics engine and to the player for keyboard input(gravity must be applied, force from other physics objects may be applied, and the player keyboard input all effect the final draw location of an in-game object). Of course their are cases where placing locks on certain members of that object are necessary, but the overall advantage I feel outweighs any syntax or non-obvious issues that may be encountered.

Regarding angles and strings - it was for convenience; movement is restricted to 4 angles (north, south, west, east) so it's easier to perform direction checks with strings instead of writing Math.PI * (0, 0.5, 1, 1.5).

I would have just used 0, 1, 2, 3 for something like that (or better yet, an enum, but the basic principle is the same). Bonus because checking integers is much easier and faster than the alternatives.

Yep. Actually I use two of them, eDir2d4 and eDir2d8... just make sure you keep track of which one your variable is. And even when I do need real angles, I prefer a 16-bit value instead of float/double in radians. 0x10000 is one full rotation, so it overflows and wraps back to 0 automatically. And you can reinterpret as signed 16 bit to get a -180 to +180 degree angle for situations like figuring whether it's quicker to turn left or right to point yourself toward something. And a quick bitshift of the unsigned 16 bit value converts to and from the eDir2d enums And you can use a 32-bit number if you do need to go over 360 degrees (e.g. a loop counter going from 0 to 360). Really convenient.

As for the original post of get/set madness, I agree with Hodgman that if you're giving out pointers to private variables, they should just be public. I have been known to write lots of get/set pairs though. Gets are generally "pure", just return a value or const reference to the variable. But sets sometimes do extra. And a lot of the time they're actually just pass-throughs to get/set functions of a member of the class. For example, in my 2D tiled game map editor, the MainWindow class has this, which I'm undecided whether it's a nightmare or not:

[source] bool isMapListWindowVisible() const { return mMapListWindow->isVisible(); }
bool isTilesetWindowVisible() const { return mTilesetWindow->isVisible(); }
bool isSpriteWindowVisible() const { return mSpriteWindow->isVisible(); }
bool isLayerWindowVisible() const { return mLayerWindow->isVisible(); }
bool isGameViewVisible() const { return mMapEditorWindow->isGameViewVisible(); }
bool getSpriteMarkersVisible() const { return mMapEditorWindow->getSpriteMarkersVisible(); }
bool getFrontLayersTransparent() const { return mMapEditorWindow->getFrontLayersTransparent(); }
void setMapListWindowVisible(bool visible) { mMapListWindow->setVisible(visible); resizeRedraw(); }
void setTilesetWindowVisible(bool visible) { mSpriteWindow->setVisible(false); mTilesetWindow->setVisible(visible); resizeRedraw(); }
void setSpriteWindowVisible(bool visible) { mTilesetWindow->setVisible(false); mSpriteWindow->setVisible(visible); resizeRedraw(); }
void setLayerWindowVisible(bool visible) { mLayerWindow->setVisible(visible); resizeRedraw(); }
void setGameViewVisible(bool visible) { mMapEditorWindow->setGameViewVisible(visible); }
void setSpriteMarkersVisible(bool visible) { mMapEditorWindow->setSpriteMarkersVisible(visible); }
void setFrontLayersTransparent(bool transparent) { mMapEditorWindow->setFrontLayersTransparent(transparent); }
[/source]

They're mostly there so the menu bar of the main window can call them when you switch on and off the visibility of all the things. And it does eliminate the need for the main window to give access to its sub-windows. But it's quite a wall of text.