Здравствуйте, Sm0ke, Вы писали:

S>>Если у класса A слишком много друзей, то с классом A явно что-то не так.

S>Серьёзно: Если бы было ...

S>public read_only protected full_access:
S>

... то число геттеров могло бы поубавиться

Тут нужно смотреть по конкретной ситуации, а не по сферическим примерам в вакууме.
Из собственной практики могу вспомнить такой пример.
Есть у нас класс environment_t, который дает пользователю доступ к ряду публичных методов. Но внутри библиотеки нужно уметь обращаться и к закрытой части функциональности этого класса. Причем из разных мест библиотеки.

Вариант сделать все эти места (т.е. внутренние классы и функции, да и не только внутренние, некоторые публичные классы/функции в своей реализации так же должны обращаться к закрытой части environment_t) друзьями environment_t -- это прямой путь в никуда (иметь вот такие списки не есть хорошо в долгосрочной перспективе).

Поэтому проще объявить для environment_t другом отдельный внутренний класс internal_env_iface_t, который живет в специальном внутреннем пространстве имен и не предназначен для прямого использования конечным пользователем.

Конечно, в C++ нет средств полностью ограничить доступ к internal_env_iface_t. Но при уже имеющейся сложности языка я не знаю, хотел бы иметь еще и такие возможности. ИМХО, прагматичнее просто сказать "вот это руками не трогать", а кто не внял, тот ССЗБ.