I must agree that there are alot of things that -- somewhat incomprehensibly -- aren't OO friendly when they really should be. But I think that this stems from a lack of knowledge of just how certain things can be made friendly. It's definately a different paradigm from the rather haphazard designs (Dikurivatives) that most of us learned from.
Correct. Just like you'd have to write a function if you want to do something with a "public" class. I use a number of macros (I'll post about them later) to define the types I need. Most of them have one-line declarations, just like static methods. The only thing you can't do is embed the algorithm in the parent function. While the usefulness of this is debatable, I generally find that encapsulating the algorithm results in nicer code.
Assuming that you have two seperate classes, Room and Character, this is another pattern called the mediator. This was actually what my next article was going to be about =). Basically, the mediator executes an operation using those two objects. To avoid getters and setters, the mediator is often made a friend of both objects. So in your example, the "CharacterRoomMediator" would perform the operation on the Room class, then format and send output to the Character class.
Before I knew much about mediators, I used the exact method you described -- the look operation returned a string, which was then sent to the character class =).
Friends aren't necessarily bad -- just like accessors and public datamembers aren't necessarily bad. Some of them do have their place. Friends are actually more desirable in alot of cases, because then you give explicit permissions, whereas an accessor will give permission to everybody.
I wholeheartedly agree. Unfortunately, C++ (and Java even moreso) leaves much to be desired in the methods used to declare classes and types that can rival a C programmer's function library. Nobody wants to write a class definition for every operation, but that's often what one has to do. I use macros to get around this, to make my C++ declarations as simple to perform as a C declaration.
Encapsulation is only bad if used improperly. If done poorly, encapsulation can greatly increase the amount of work one has to do. Because one has to write many of the encapsulating functions (accessors), the programmer receives very few, if any, of the benefits by tightly coupling classes together.
Your input is appreciated =).
|