C ++ do znajomego lub nie do znajomego

W tym semestrze na studiach mam programowanie obiektowe z kursem c ++ i uczyliśmy się o funkcjach przyjaciela.

Instynktownie ich nie lubię za to, że potrafią ominąć zabezpieczenia zapewniane przez enkapsulację i ukrywanie danych. Przeczytałem kilka artykułów w Internecie, a niektórzy uważali, że to dobry pomysł, jeśli ma uzasadnione zastosowanie.

Co powiedziałby ekspert OOP o funkcjach znajomych w C ++? Czy powinienem to przejrzeć, czy powinienem dowiedzieć się więcej na ten temat?

Nie zawsze wygodne jest tworzenie wszystkich funkcji związanych z członkami klasy C ++ tej klasy. Wyobraźmy sobie na przykład implementację algebry wektorowej z pomnożeniem skalarnym. Chcemy napisać:

 double a;
 Vector v, w;
 w = v * a;

Możemy to zrobić za pomocą funkcji członka:

public class Vector {
 ...
 Vector operator*(double a);
}

Ale chcielibyśmy również napisać:

w = a * v

Wymaga to bezpłatnej funkcji:

 Vector operator*(double a, Vector v)

Słowo friendkluczowe zostało dodane do C ++ w celu obsługi tego użycia. Funkcja swobodna jest częścią implementacji klasy Vector i powinna zostać zadeklarowana w tym samym nagłówku i zaimplementowana w tym samym pliku źródłowym.

Podobnie możemy frienduprościć implementację ściśle powiązanych klas, takich jak kolekcja i iterator. Ponownie zadeklaruję obie klasy w tym samym nagłówku i zaimplementuję je w tym samym pliku źródłowym.

Funkcje zaprzyjaźnienia nie różnią się od funkcji składowych pod względem enkapsulacji. Mogą one jednak oferować inne zalety - na przykład bardziej ogólne, zwłaszcza jeśli chodzi o szablony. Ponadto niektórych operatorów można określić tylko jako funkcje bezpłatne, więc jeśli chcesz, aby mieli dostęp do członków, musisz friend.

Lepiej jest friendużyć jednej funkcji niż być zmuszonym do zrobienia czegoś, czego nie chcesz być publicznym. Oznacza to, że cały świat może z niego korzystać zamiast jednej funkcji.

Jeśli pasjonujesz się tym, co robisz, nauczyłbyś się wszystkiego o C ++. Dowiedz się, do czego służą, jak ich używać, a następnie - i tylko wtedy - zdecyduj, aby ich nie używać. Przynajmniej będziesz przygotowany podczas czytania kodu innej osoby korzystającego z tego aspektu C ++.

„ Co powiedziałby ekspert OOP ... ” To zależy głównie od tego, jak on jest ekspertem w C ++, że - zgodnie z jego własną specyfikacją - nie jest (i nie chce być) językiem purystów.

Zeloci OOP nie używają C ++ (wolą Smalltalk i jak Java).

Zeloty programowania funkcjonalnego nie używają C ++ (wolą LISP i jego następców)

Większość ekspertów OOP nie lubi funkcji znajomych po prostu dlatego, że chcą, aby część OOP w C ++ zachowywała się jak Smalltalk. Ale C ++ nie jest Smalltalk i nie mogą nawet zrozumieć, że przyjaciel nie przerywa enkapsulacji , z bardzo prostego powodu, że funkcja nie może być przyjacielem twojej klasy bez twojej klasy .

A z punktu widzenia „funkcjonalności” pomiędzy a.fn(b)i fn(a,b)nie ma różnicy (gdzie fnjest przyjaciel): zaangażowane strony są takie same. Wystarczy jeden składnia może być bardziej odpowiednie niż inny: jeśli fn jest przemienne czasowo ai b, fn(a,b)prawdopodobnie bardziej nadaje następnie a.fn(b)(. A gdzie wygląd posiadające „szczególną rolę”, że w rzeczywistości nie ma)

Czy „przyjaciel” narusza enkapsulację?

Nie. „Przyjaciel” jest jawnym mechanizmem przyznawania dostępu, podobnie jak członkostwo. Nie możesz (w standardowym programie zgodnym) przyznać sobie dostępu do klasy bez modyfikacji jej źródła.

C ++ FAQ jest zwięzły:

Użyj członka, kiedy możesz, i przyjaciela, kiedy musisz.

FAQ przedstawia jeden z bardziej użytecznych sposobów myślenia o przyjaźni:

Wiele osób uważa, że ​​przyjaciel funkcjonuje jak coś poza klasą. Zamiast tego spróbuj wymyślić funkcję przyjaciela jako część publicznego interfejsu klasy. Funkcja „przyjaciel” w deklaracji klasy nie narusza enkapsulacji tak samo, jak funkcja członka publicznego narusza enkapsulację: obie mają dokładnie takie same uprawnienia w zakresie dostępu do niepublicznych części klasy.

Być może najczęstszym zastosowaniem funkcji znajomych jest przeciążanie << dla I / O.

Funkcje zaprzyjaźnienia najlepiej nadają się do definicji operatora zdefiniowanych przez użytkownika. Przydają się w innych sytuacjach, ale jeśli często określasz klasy znajomych, możesz być na objeździe projektowym (po prostu dobry test do użycia podczas pisania kodu).

Zachowaj ostrożność w stosunku do stwierdzenia „bezpieczeństwo” w pierwotnym pytaniu. Dostępne są modyfikatory dostępu, które zapobiegają pisaniu złego kodu po wypadku, podobnie jak kompilator. Modyfikatory dostępu ograniczają interfejs i służą do komunikowania, jakie funkcje są ważne dla korzystania z klasy (publicznej i chronionej), a które zostały utworzone w ramach upiększania klasy dla opiekunów (prywatnej). Modyfikatory nie stanowią bezpieczeństwa, ponieważ istnieje wiele sposobów na uzyskanie prywatnych danych. Na przykład zdobądź wskaźnik do klasy i jej wielkości i idź łowić ryby.

Funkcje znajomych w C ++ są ściśle powiązane z następującymi funkcjami:

1. darmowe funkcje
2. funkcje statyczne
3. funkcje przyjaciela

Oznacza to, że nie mają tego wskaźnika, a zatem znajdują się poza klasą / obiektem. Z drugiej strony często przyjmują parametry, które sprawiają, że ponownie należą do klasy. Oto przykład, który wyjaśnia link:

class B;
class A {
public:
    friend void f(A &a, B &b);
private:
    int m_a;
};
class B {
public:
   friend void f(A &a, B &b);
private:
   int m_b;
};
void f(A &a, B &b) { /* uses both A's and B's private data */ }

Jedyną różnicą między funkcjami statycznymi a funkcjami znajomego jest to, że funkcja znajomego może korzystać z kilku klas.

Korzystanie z mechanizmu zaprzyjaźnionego w c ++ wymaga programistów, którzy mają około 10-15 lat doświadczenia ze sposobem programowania w c ++, dlatego na początku powinieneś go unikać. To zaawansowana funkcja.