(Я не читав Чистий код і не знаю багато Java.)
Чи має сенс застосовувати ідею створення багатьох крихітних сутностей, кожна з яких чітко визначає відповідальність, до просторів імен?
Так, як і при рефакторингу на кілька класів і декількох функцій.
Чи повинна невелика група пов'язаних класів завжди бути загорнута в простір імен?
Не відповідаючи насправді: так, ви повинні хоча б використовувати один простір імен верхнього рівня. Це може ґрунтуватися на проекті, організації чи будь-якому іншому, але використання кількох глобальних імен зменшить конфлікти імен. Єдиний простір імен для групування всього іншого під ним вводить лише одне глобальне ім'я. (За винятком зовнішніх функцій "C", але це пов'язано з сумісністю C і впливає лише на інші зовнішні "C" функції.)
Чи повинна невелика група пов’язаних класів бути загорнута у присвячений їм простір імен ? Мабуть. Особливо, якщо ви виявите, що ви використовуєте загальний префікс для цих класів - FrobberThing, FrobberThang, FrobberDoohickey - вам слід розглянути простір імен - frobber :: Thing і так далі. Це все ще буде знаходитися під вашим кореневим простором імен або іншим простором імен, якщо вони є частиною більшого проекту.
Це спосіб управління складністю наявності безлічі крихітних класів, чи витрати на управління безліччю просторів імен будуть непомірними?
Беручи наведений вище приклад префіксованих імен, не важче керувати frobber :: Thing, ніж FrobberThing. З деякими інструментами, такими як документація та заповнення коду, це може бути навіть простіше. Існує різниця з ADL, але це може працювати на вашу користь: менша кількість імен у асоційованих просторах імен робить ADL простішою для з'ясування, і ви можете використовувати декларації для введення конкретних імен в одну чи іншу область імен.
Псевдоніми просторів імен дозволяють використовувати коротше ім’я для більш тривалого простору імен у конкретному контексті, що знову дозволяє легше використовувати:
void f() {
namespace CWVLN = Company_with_very_long_name; // Example from the standard.
// In this scope, use CWVLN::name instead of Company_with_very_long_name::name.
namespace fs = boost::filesystem; // Commonly used.
}
Розглянемо Boost, який має єдиний корінний простір імен, boost, а потім багато підпросторів імені - boost :: asio, boost :: io, boost:: файлова система, boost :: tuples тощо - для різних бібліотек. Деякі імена "просуваються" до кореневого простору імен:
Усі визначення знаходяться у просторі імен :: boost :: tuples, але найпоширеніші імена піднімаються до простору імен :: boost з використанням декларацій. Такими назвами є: кортеж, make_tuple, прив’язати та дістати. Далі ref і cref визначаються безпосередньо у :: boost просторі імен.
Найбільша відмінність від мов із "реальними" модулями полягає в тому, наскільки поширеним є використання більш плоскої структури, що в основному відбувається, тому що так воно працює, якщо ви не докладете додаткових, конкретних зусиль для визначення вкладених імен.