(Nie przeczytałem Czystego Kodu i nie znam dużo Javy).
Czy ma sens zastosowanie idei tworzenia wielu małych bytów, z których każdy ma jasno określoną odpowiedzialność, do przestrzeni nazw?
Tak, podobnie jak w przypadku refaktoryzacji na wiele klas i wiele funkcji.
Czy mała grupa pokrewnych klas powinna być zawsze zawinięta w przestrzeń nazw?
Bez odpowiedzi: tak, powinieneś użyć przynajmniej jednej przestrzeni nazw najwyższego poziomu. Może to być oparte na projekcie, organizacji lub czymkolwiek innym, ale użycie kilku nazw globalnych ograniczy konflikty nazw. Pojedyncza przestrzeń nazw do grupowania wszystkich pozostałych elementów wprowadza tylko jedną nazwę globalną. (Z wyjątkiem zewnętrznych funkcji „C”, ale wynika to z interoperacyjności C i wpływa tylko na inne zewnętrzne funkcje „C”.)
Czy mała grupa powiązanych klas powinna być zapakowana w dedykowaną im przestrzeń nazw ? Prawdopodobnie. Zwłaszcza jeśli używasz wspólnego przedrostka w tych klasach - FrobberThing, FrobberThang, FrobberDoohickey - powinieneś rozważyć przestrzeń nazw - frobber :: Thing i tak dalej. To nadal znajdowałoby się w głównej przestrzeni nazw lub w innej przestrzeni nazw, jeśli są one częścią większego projektu.
Czy jest to sposób na zarządzanie złożonością posiadania wielu małych klas, czy też koszt zarządzania wieloma przestrzeniami nazw byłby zbyt wysoki?
Biorąc powyższy przykład prefiksowanych nazw, zarządzanie frobber :: Thing nie jest trudniejsze niż FrobberThing. Może być nawet łatwiej z niektórymi narzędziami, takimi jak dokumentacja i uzupełnianie kodu. Istnieje różnica w ADL, ale może to działać na twoją korzyść: mniej nazw w powiązanych przestrzeniach nazw ułatwia ADL, aby łatwiej je rozgryźć, i możesz użyć deklaracji, aby wstrzyknąć określone nazwy do jednej lub innej przestrzeni nazw.
Aliasy przestrzeni nazw pozwalają na użycie krótszej nazwy dla dłuższej przestrzeni nazw w określonym kontekście, co ponownie pozwala na łatwiejsze użycie:
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.
}
Rozważ Boost, który ma jedną główną przestrzeń nazw, boost, a następnie wiele podprzestrzeni - boost :: asio, boost :: io, boost :: system plików, boost :: krotki itp. - dla różnych bibliotek. Niektóre nazwy są „promowane” do głównej przestrzeni nazw:
Wszystkie definicje znajdują się w przestrzeni nazw :: boost :: krotki, ale najpopularniejsze nazwy są podnoszone do przestrzeni nazw :: boost przy użyciu deklaracji. Te nazwy to: krotka, make_tuple, tie i get. Ponadto ref i cref są definiowane bezpośrednio w przestrzeni nazw :: boost.
Największą różnicą w stosunku do języków z „prawdziwymi” modułami jest to, jak często stosuje się bardziej płaską strukturę, co dzieje się głównie dlatego, że tak to działa, chyba że podejmiesz dodatkowy, konkretny wysiłek, aby zdefiniować zagnieżdżone nazwy.