Jak funkcje niezwiązane z członkami poprawiają kapsułkowanie
Czytam Scotta Meyersaartykuł na ten temat i dość zdezorientowany o tym, o czym mówi. Mam tutaj 3 pytania.
Pytanie 1
Aby wyjaśnić szczegółowo, załóżmy, że piszę prostyvector<T>
klasa z metodami takimi jakpush_back
, insert
i operator[]
. Gdybym zastosował algorytm Meyersa, skończyłbym ze wszystkimi funkcjami znajomych, którzy nie są członkami. Będę miał klasę wektorową z kilkoma prywatnymi członkami i wieloma funkcjami znajomych innych niż członkowie. Czy o tym on mówi?
pytanie 2
Nadal nie rozumiem, w jaki sposób funkcje niezwiązane z członkami poprawiają hermetyzację. Rozważmy kod podany w artykule Meyersa.
class Point {
public:
int getXValue() const;
int getYValue() const;
void setXValue(int newXValue);
void setYValue(int newYValue);
private:
... // whatever...
};
Jeśli jego algorytm jest przestrzegany,setXXXX
metody powinny być niebędące członkami. Moje pytanie brzmi: jak to zwiększa hermetyzację? On też mówi
Widzieliśmy teraz, że rozsądnym sposobem oceny wielkości enkapsulacji w klasie jest policzenie liczby funkcji, które mogą zostać zerwane, jeśli zmieni się implementacja klasy.
Dopóki nie zachowamy podpisu metody w stanie nienaruszonym, gdy zmieni się implementacja klasy, żaden kod klienta nie zostanie przerwany i będzie dobrze zamknięty, prawda? To samo dotyczy funkcji innych niż członkowie. Jaka jest więc zaleta funkcji bez członków?
pytanie 3
Cytowanie jego algorytmu
else if (f needs type conversions
on its left-most argument)
{
make f a non-member function;
if (f needs access to non-public
members of C)
make f a friend of C;
}
Co miał na myślif potrzebuje konwersji typu na najbardziej lewy argument? Mówi także o następującym artykule.
Co więcej, widzimy teraz, że powszechne twierdzenie, że „funkcje przyjaciela naruszają kapsułkowanie” nie jest do końca prawdą. Przyjaciele nie naruszają enkapsulacji, po prostu ją zmniejszają - dokładnie w taki sam sposób jak funkcje członka.
Ten i powyższy algorytm są ze sobą sprzeczne, prawda?