Refactor protected member variables to private

[GunChleoc]

I noticed that the buildings have a lot of protected variables, mostly because they're used in map_io. I think we should make as many of these as we can private with proper getters & setters.

Opinions?

[SirVer (sirver)]

I am torn on this. On one site, protected is basically public. And public members are bad. Then again, the io stuffed is pulled out so that the logic does not contain tons of serialization and deserialization information.

I think that protected members are worse than having serialization code all over the place. So I am pro this change in general. But given that it will be a tremendous amount of work I think it should have a very low priority. Also the new design is not immediately apparent to me - this will need some iterations.

[SirVer (sirver)]

I removed lowhangingfruit here, because it is probably not very easy to do this :)

[GunChleoc (gunchleoc)]

I thouched 2 of these variables in this branch: https://code.launchpad.net/~widelands-dev/widelands/bug-1348795

What I did there is program a getter function which the map_io uses instead of directly accessing the member variable.

[Hans Joachim Desserud (hjd)]

> I removed lowhangingfruit here, because it is probably not very easy to do this :)

No problem. It sounded easier based on the original description. :)

[GunChleoc (gunchleoc)]

We need to discuss this carefully because we want them private, but still keep the map_io stuff in separate files. I had a fast idiscussion fir SirVer on IRC and he suggested doing something with friends or have the objects return Savers() or Loaders(). Any other ideas are welcome though. We don't want the map_io objects to be too public either :)

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/1547