Przestrzeń nazw + funkcje kontra metody statyczne w klasie

Powiedzmy, że mam lub zamierzam napisać zestaw powiązanych funkcji. Powiedzmy, że są związane z matematyką. Pod względem organizacyjnym powinienem:

1. Napisz te funkcje i umieść je w mojej MyMathprzestrzeni nazw i odwołuj się do nich za pośrednictwemMyMath::XYZ()
2. Utwórz klasę o nazwie MyMathi ustaw te metody statycznie i odwołuj się do nich podobnieMyMath::XYZ()

Dlaczego miałbym wybierać między sobą jako sposób organizacji mojego oprogramowania?

Domyślnie używaj funkcji z przestrzenią nazw.

Klasy mają budować obiekty, a nie zastępować przestrzenie nazw.

W kodzie obiektowym

Scott Meyers napisał cały artykuł do swojej książki Effective C ++ na ten temat: „Wolę funkcje nieprzyjazne od innych niż funkcje członkowskie”. Internetowe odniesienie do tej zasady znalazłem w artykule z Herb Sutter:http://www.gotw.ca/gotw/084.htm

Ważne jest, aby wiedzieć, że: W C ++ funkcje w tej samej przestrzeni nazw, w której klasa należy do interfejsu tej klasy (ponieważ ADL przeszuka te funkcje podczas rozwiązywania wywołań funkcji).

Funkcje z przestrzenią nazw, chyba że zostaną uznane za „przyjaciel”, nie mają dostępu do wewnętrznych elementów klasy, podczas gdy metody statyczne mają.

Oznacza to na przykład, że utrzymując klasę, jeśli chcesz zmienić elementy wewnętrzne swojej klasy, będziesz musiał szukać efektów ubocznych we wszystkich jej metodach, w tym statycznych.

Rozszerzenie I

Dodawanie kodu do interfejsu klasy.

W języku C # możesz dodawać metody do klasy, nawet jeśli nie masz do niej dostępu. Ale w C ++ jest to niemożliwe.

Ale nadal w C ++ możesz nadal dodawać funkcje przestrzeni nazw, nawet do klasy, którą ktoś dla ciebie napisał.

Patrz z drugiej strony, jest to ważne przy projektowaniu kodu, ponieważ umieszczając swoje funkcje w przestrzeni nazw, upoważnisz użytkowników do zwiększenia / ukończenia interfejsu klasy.

Rozszerzenie II

Efektem ubocznym poprzedniego punktu jest niemożliwość zadeklarowania metod statycznych w wielu nagłówkach. Każda metoda musi być zadeklarowana w tej samej klasie.

W przypadku przestrzeni nazw funkcje z tej samej przestrzeni nazw można zadeklarować w wielu nagłówkach (prawie standardowa funkcja zamiany jest tego najlepszym przykładem).

Rozszerzenie III

Podstawową zaletą przestrzeni nazw jest to, że w niektórych kodach można uniknąć wspominania o niej, jeśli użyjesz słowa kluczowego „using”:

#include <string>
#include <vector>

// Etc.
{
   using namespace std ;
   // Now, everything from std is accessible without qualification
   string s ; // Ok
   vector v ; // Ok
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Możesz nawet ograniczyć „zanieczyszczenie” do jednej klasy:

#include <string>
#include <vector>

{
   using std::string ;
   string s ; // Ok
   vector v ; // COMPILATION ERROR
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Ten „wzorzec” jest obowiązkowy dla właściwego użycia prawie standardowego idiomu zamiany.

Jest to niemożliwe w przypadku metod statycznych w klasach.

Przestrzenie nazw C ++ mają więc własną semantykę.

Ale idzie dalej, ponieważ można łączyć przestrzenie nazw w sposób podobny do dziedziczenia.

Na przykład, jeśli masz przestrzeń nazw A z funkcją AAA, przestrzeń nazw B z funkcją BBB, możesz zadeklarować przestrzeń nazw C i wprowadzić AAA i BBB w tej przestrzeni nazw za pomocą słowa kluczowego.

Wniosek

Przestrzenie nazw dotyczą przestrzeni nazw. Klasy są dla klas.

C ++ został zaprojektowany, więc każda koncepcja jest inna i jest używana w różnych przypadkach, w różnych przypadkach, jako rozwiązanie różnych problemów.

Nie używaj klas, gdy potrzebujesz przestrzeni nazw.

A w twoim przypadku potrzebujesz przestrzeni nazw.

Jest wielu ludzi, którzy nie zgadzają się ze mną, ale tak to widzę:

Klasa jest zasadniczo definicją pewnego rodzaju obiektu. Metody statyczne powinny definiować operacje ściśle związane z definicją obiektu.

Jeśli chcesz mieć grupę powiązanych funkcji niezwiązanych z obiektem bazowym lub definicją rodzaju obiektu , powiedziałbym, że idź z tylko przestrzenią nazw. Dla mnie, koncepcyjnie, jest to o wiele bardziej sensowne.

Na przykład w twoim przypadku zadaj sobie pytanie: „Co to jest MyMath?” Jeśli MyMathnie określa rodzaj obiektu, a ja powiedziałbym: nie sprawiają, że klasa.

Ale tak jak powiedziałem, wiem, że jest wielu ludzi, którzy (nawet gwałtownie) nie zgadzają się ze mną w tej sprawie (w szczególności deweloperzy Java i C #).

• Jeśli potrzebujesz danych statycznych, użyj metod statycznych.
• Jeśli są to funkcje szablonów i chcesz mieć możliwość określenia zestawu parametrów szablonu dla wszystkich funkcji razem, użyj metod statycznych w klasie szablonów.

W przeciwnym razie użyj funkcji z przestrzenią nazw.

W odpowiedzi na komentarze: tak, metody statyczne i dane statyczne są zwykle nadmiernie wykorzystywane. Dlatego zaproponowałem tylko dwa powiązane scenariusze, w których moim zdaniem mogą być pomocne. W konkretnym przykładzie PO (zestaw procedur matematycznych), jeśli chciałby możliwości określenia parametrów - powiedzmy, podstawowego typu danych i precyzji wyjściowej - które miałyby zastosowanie do wszystkich procedur, mógłby zrobić coś takiego:

template<typename T, int decimalPlaces>
class MyMath
{
   // routines operate on datatype T, preserving at least decimalPlaces precision
};

// math routines for manufacturing calculations
typedef MyMath<double, 4> CAMMath;
// math routines for on-screen displays
typedef MyMath<float, 2> PreviewMath;

Jeśli nie musisz, wtedy przez wszystkich środków używać nazw.

Powinieneś użyć przestrzeni nazw, ponieważ przestrzeń nazw ma wiele zalet w stosunku do klasy:

• Nie musisz definiować wszystkiego w tym samym nagłówku
• Nie musisz ujawniać całej swojej implementacji w nagłówku
• Nie możesz usingczłonka klasy; możesz być usingczłonkiem przestrzeni nazw
• Nie możesz using class, choć using namespacenie jest to często dobry pomysł
• Korzystanie z klasy oznacza, że ​​istnieje jakiś obiekt do utworzenia, gdy tak naprawdę go nie ma

Moim zdaniem członkowie statyczni są bardzo nadużywani. W większości przypadków nie są one koniecznością. Funkcje elementów statycznych są prawdopodobnie lepsze niż funkcje zakresu plików, a elementy danych statycznych to tylko obiekty globalne o lepszej, niezasłużonej reputacji.

Wolałbym przestrzenie nazw, w ten sposób możesz mieć prywatne dane w anonimowej przestrzeni nazw w pliku implementacji (więc nie musi wcale pojawiać się w nagłówku, w przeciwieństwie do privateczłonków). Kolejną korzyścią jest to, że dzięki usingprzestrzeni nazw klienci metod mogą zrezygnować z określaniaMyMath::

Jeszcze jeden powód, aby używać klasy - Opcja korzystania ze specyfikatorów dostępu. Następnie możesz ewentualnie podzielić swoją publiczną metodę statyczną na mniejsze metody prywatne. Metoda publiczna może wywoływać wiele metod prywatnych.

Zarówno przestrzeń nazw, jak i metoda klasy mają swoje zastosowania. Przestrzeń nazw może być rozłożona na pliki, ale jest to słabość, jeśli trzeba wymusić cały powiązany kod, aby przejść do jednego pliku. Jak wspomniano powyżej klasa pozwala również tworzyć prywatne statyczne elementy w klasie. Możesz mieć go w anonimowej przestrzeni nazw pliku implementacji, jednak nadal jest to większy zakres niż posiadanie ich w klasie.