2012-10-04 17 views
12

Pisząc metodę pomocniczą dla klasy w C++, czy powinna być zadeklarowana jako prywatna metoda w definicji klasy w pliku nagłówkowym (.h)? Na przykład:Czy funkcja pomocnika powinna znajdować się w nagłówku lub w pliku implementacji?

/*Foo.h*/ 
class Foo { 

    public: 
     int bar(); 

    private: 
     int helper(); 
}; 
... 
/*Foo.cpp*/ 
... 
int foo::bar() { 
    int something = this->helper(); 
} 

int foo::helper() { 
    ... 
} 

lub alternatywnie, jest to nie lepiej zadeklarować go jako prywatny członka klasy, a zamiast tego po prostu zrobić to funkcja wolnostojący w realizacji?

/*Foo.h*/ 
class Foo { 
    public: 
     int bar(); 
}; 
... 
/*Foo.cpp*/ 
... 
int Foo::bar() { 
    int something = helper(); 
    ... 
} 

int helper() { 
    ... 
} 

Odpowiedz

18

wolnostojące funkcja w pliku implementacji poprawia enkapsulacji: nie wymaga zgłoszenia w nagłówku, więc nie rekompilacji kodu klienta, gdy jej zmiany podpisu z jakiegokolwiek powodu. Dla mnie jest to wystarczający powód, by preferować tę opcję, gdy tylko jest to wykonalne. (Pamiętaj, aby umieścić go w anonimowej przestrzeni nazw, aby zapobiec kolizji identyfikatora w czasie połączenia.)

Jednak metoda private ma dostęp do instancji klasy i jego intymnych części poprzez wskaźnik this. Jeśli potrzebuje takiego dostępu, musi to być metoda lub friend. W obu przypadkach będzie to widoczne w definicji klasy (plik nagłówkowy), a metody są po prostu wygodniejsze od znajomych.

+1

Aby rozwinąć akapit drugi: [preferuj nie-przyjacielskie funkcje nie będące członkami] (http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197). Jeśli funkcja nie wymaga dostępu prywatnego, nie udzielaj jej prywatnego dostępu. –

+0

@ftopbit: dzięki. Lekko zaostrzyłem akapit drugi. –

1

Moja pozycja jest taka, że ​​nagłówek zawiera możliwie małą reklamę przy jednoczesnym osiągnięciu pożądanych właściwości projektu i układu. Jeśli istnieje opcja, przechodzi do źródła. Niektóre wewnętrzne szczegóły wymagają dostępu do zbyt wielu wewnętrznych szczegółów klasy, aby uczynić ją zdolną do wdrożenia.

4

Jeśli twoja funkcja pomocnika ma sens, aby być metodą obiektu, prawie zawsze wolałbym uczynić ją funkcją składową, więc istnieje niejawny wskaźnik this, zamiast przekazywać do funkcji pomocnika Foo *.

Jeśli funkcja pomocnik nie musi być to metoda obiektu (to znaczy, że nie potrzebują dostępu do danych lub innych członków funkcji składowych), a następnie stała się ona samodzielną funkcję (static lub anonimowy przestrzeń nazw, najlepiej).

2

To chyba trochę subiektywne.

Moim zdaniem, zależy to od tego, czy ma to coś wspólnego z członkami klasy i czy oczekuje się, że klasy znajomych będą z niej korzystać (lub klasy pochodne w przypadku dostępu protected).

Jeśli funkcja nie działa na żadnym członku i nikt inny nie jest nią zainteresowany, należy zachować ją w pliku implementacji jako funkcję statyczną. Ponadto, jeśli jest to operacja, która musi być szybka, możesz skorzystać z tej okazji, aby ją wykonać: inline.

I odwrotnie, jeśli funkcja działa w klasie lub może mieć dodatkowe zastosowania w klasach pochodnych lub powiązanych, należy ją ustawić jako element.

Powiązane problemy