Which is more important? Readability or encapsulation? Scott Meyers argues that the fewer the member functions a class has, the better the encapsulation. I agree with this. It makes the class more understandable as a whole, and decreases the potential places where you can break something in the class that you really shouldn''t have had access to be messing with. I think this leads to code that is closer to "correct" from the "it does what it is supposed to do" standpoint. On the other hand, this leads to code that is not quite as readable. Your code is not as consistent. For instance, you call a non-member function f(obj) differently than a member function, obj.g(). Is there any rhyme or reason to someone who didn''t have any part in implementing that class? In addition, you are calling member functions all over the place by first referencing the object. This kind of bothers me when I have obj.things().foo().blah() all over a non-member function. That long string of member function calls looks ugly to me, when repeated over and over in the function. I guess I could get around that by making local references to some of the objects returned by member functions. Anyway, details aside, is it more important that the code is straightforward and easy to understand 6 months from now? Or is it better to maintain the absolute tightest encapsulation by having as few member functions as possible?

quote:Original post by antareus
Understandability by a long shot.

I find this is something you work out with experience. C++''s lack of real object properties just means that your method lists will be VERY cluttered on some objects with getters/setters when the need arises. A more expressive language, like C#, ends up cleaner.

So you are saying that since C++ isn''t as elegant as some other languages when it comes to OOP, that it is acceptable to add in more member functions for the purpose of increased readability?

Sometimes I really like the way the object call string is actually readable. This is an example from my chess program (doesn''t actually look like this, just an example):

if (game.side_to_move().has_castling_rights() { ... };

How I would probably do this the encapsulation route:

if (game.castling_rights().exist_for(game.side_to_move())) { ... };

Notice the nice game. plopped in the middle there. That is kind of ugly to me.

If I could at least make the function where this was being called a member of Game, then I could get rid of the game. stuff and it would be more readable: if (castling_rights().exist_for(side_to_move())) { ... }; I guess I''m kind of using the Game class as a namespace there.

I am the only one working on this. Others may also read it, but I''ll be the only one working on it.