Zastanów się nad rozwiązaniem Matta Price'a .
- W C ++ „klasa statyczna” nie ma znaczenia. Najbliższa rzecz to klasa posiadająca wyłącznie statyczne metody i elementy.
- Korzystanie z metod statycznych tylko cię ogranicza.
To, czego chcesz, to wyrażone w semantyce C ++, aby umieścić swoją funkcję (ponieważ jest to funkcja) w przestrzeni nazw.
Edytuj 11.11.2011
W C ++ nie ma „klasy statycznej”. Najbliższą koncepcją byłaby klasa posiadająca wyłącznie metody statyczne. Na przykład:
// header
class MyClass
{
public :
static void myMethod() ;
} ;
// source
void MyClass::myMethod()
{
// etc.
}
Musisz jednak pamiętać, że „klasy statyczne” to włamania w językach podobnych do Javy (np. C #), które nie mogą mieć funkcji nie będących członkami, więc zamiast tego muszą przenieść je do klas jako metody statyczne.
W C ++ tak naprawdę chcesz funkcji nieosobistej, którą zadeklarujesz w przestrzeni nazw:
// header
namespace MyNamespace
{
void myMethod() ;
}
// source
namespace MyNamespace
{
void myMethod()
{
// etc.
}
}
Dlaczego?
W C ++ przestrzeń nazw ma większą moc niż klasy dla wzorca „Java static method”, ponieważ:
- metody statyczne mają dostęp do klas prywatnych symboli
- prywatne metody statyczne są nadal widoczne (jeśli niedostępne) dla wszystkich, co nieco narusza enkapsulację
- metody statyczne nie mogą być deklarowane w przód
- metody statyczne nie mogą być przeciążone przez użytkownika klasy bez modyfikacji nagłówka biblioteki
- nic nie da się zrobić za pomocą metody statycznej, której nie da się zrobić lepiej niż funkcja nie będąca członkiem (prawdopodobnie przyjacielem) w tej samej przestrzeni nazw
- przestrzenie nazw mają własną semantykę (można je łączyć, mogą być anonimowe itp.)
- itp.
Wniosek: Nie kopiuj / wklej tego wzorca Java / C # w C ++. W Javie / C # wzorzec jest obowiązkowy. Ale w C ++ jest to zły styl.
Edytuj 2010-06-10
Argumentowano za metodą statyczną, ponieważ czasami trzeba użyć statycznej zmiennej członka prywatnego.
Nie zgadzam się, jak pokazano poniżej:
Rozwiązanie „Statyczny członek prywatny”
// HPP
class Foo
{
public :
void barA() ;
private :
void barB() ;
static std::string myGlobal ;
} ;
Po pierwsze, myGlobal nazywa się myGlobal, ponieważ wciąż jest globalną zmienną prywatną. Spojrzenie na źródło CPP wyjaśni, że:
// CPP
std::string Foo::myGlobal ; // You MUST declare it in a CPP
void Foo::barA()
{
// I can access Foo::myGlobal
}
void Foo::barB()
{
// I can access Foo::myGlobal, too
}
void barC()
{
// I CAN'T access Foo::myGlobal !!!
}
Na pierwszy rzut oka fakt, że bezpłatna funkcja barC nie może uzyskać dostępu do Foo :: myGlobal, wydaje się dobrą rzeczą z punktu widzenia enkapsulacji ... Fajnie, ponieważ ktoś patrząc na HPP nie będzie w stanie (chyba, że ucieknie się do sabotażu) uzyskać dostęp Foo :: myGlobal.
Ale jeśli przyjrzysz się temu uważnie, okaże się, że jest to kolosalny błąd: nie tylko twoja prywatna zmienna musi być nadal zadeklarowana w HPP (a więc widoczna dla całego świata, mimo że jest prywatna), ale musisz zadeklarować w tym samym HPP wszystkie (jak we WSZYSTKICH) funkcjach, które będą uprawnione do dostępu do niego !!!
Zatem używanie prywatnego statycznego członka jest jak chodzenie nago na zewnątrz z listą kochanków wytatuowaną na skórze: Nikt nie jest upoważniony do dotykania, ale każdy jest w stanie zerknąć. I bonus: każdy może mieć nazwiska osób upoważnionych do korzystania z twoich uprawnień.
private rzeczywiście ... :-D
Rozwiązanie „Anonimowe przestrzenie nazw”
Anonimowe przestrzenie nazw będą miały tę zaletę, że uczynią rzeczy prywatnymi naprawdę prywatnymi.
Najpierw nagłówek HPP
// HPP
namespace Foo
{
void barA() ;
}
Dla pewności, że zauważyłeś: Nie ma bezużytecznej deklaracji barB ani myGlobal. Co oznacza, że nikt nie czytający nagłówka nie wie, co kryje się za paskiem A.
Następnie CPP:
// CPP
namespace Foo
{
namespace
{
std::string myGlobal ;
void Foo::barB()
{
// I can access Foo::myGlobal
}
}
void barA()
{
// I can access myGlobal, too
}
}
void barC()
{
// I STILL CAN'T access myGlobal !!!
}
Jak widać, podobnie jak tak zwana deklaracja „klasy statycznej”, fooA i fooB nadal mają dostęp do myGlobal. Ale nikt inny nie może. I nikt poza CPP nie wie, że fooB i myGlobal nawet istnieją!
W przeciwieństwie do „klasy statycznej” chodzącej nago z książką adresową wytatuowaną na skórze, „anonimowa” przestrzeń nazw jest w pełni ubrana , co wydaje się znacznie lepiej zamknięte AFAIK.
Czy to naprawdę ma znaczenie?
O ile użytkownicy Twojego kodu nie są sabotażystami (pozwolę ci, jako ćwiczenie, dowiedzieć się, jak można uzyskać dostęp do prywatnej części klasy publicznej za pomocą brudnego, niezdefiniowanego zachowania hack ...), co to privatejest private, nawet jeśli to jest widoczny w privatesekcji klasy zadeklarowanej w nagłówku.
Jeśli jednak chcesz dodać kolejną „funkcję prywatną” z dostępem do prywatnego członka, nadal musisz ją zadeklarować na całym świecie, modyfikując nagłówek, co jest moim zdaniem paradoksem: jeśli zmienię implementację mój kod (część CPP), a następnie interfejs (część HPP) NIE powinien się zmienić. Cytując Leonidasa: „ To jest ENCAPSULATION! ”
Edytuj 2014-09-20
Kiedy klasy metody statyczne są w rzeczywistości lepsze niż przestrzenie nazw z funkcjami nieczłonkowskimi?
Gdy musisz zgrupować funkcje i nakarmić tę grupę szablonem:
namespace alpha
{
void foo() ;
void bar() ;
}
struct Beta
{
static void foo() ;
static void bar() ;
};
template <typename T>
struct Gamma
{
void foobar()
{
T::foo() ;
T::bar() ;
}
};
Gamma<alpha> ga ; // compilation error
Gamma<Beta> gb ; // ok
gb.foobar() ; // ok !!!
Ponieważ jeśli klasa może być parametrem szablonu, przestrzenie nazw nie mogą.