2010-05-26 19 views
15

Jestem oczywiście nowy na te koncepcje. Po prostu nie rozumiem, dlaczego ograniczasz dostęp do właściwości lub metod. Wygląda na to, że po prostu napiszesz kod zgodnie z zamierzonymi wynikami. Dlaczego miałbyś stworzyć prywatną metodę, zamiast po prostu nie wywoływać tej metody? Czy chodzi o wielokrotne tworzenie obiektów (jeśli mówię o tym poprawnie), o wiele sytuacji deweloperskich (nie psuj pracy innych), czy po prostu niechcący nie zepsujesz swojej pracy?Jestem nowy w OOP/PHP. Jaka jest praktyczność widoczności i rozszerzalności na zajęciach?

+0

Bah. Jest tak wiele podobnych odpowiedzi! –

Odpowiedz

7

Wszystko sprowadza się do hermetyzacji. Oznacza to ukrywanie wnętrz klasy i dbanie o to, co robi. Jeśli chcesz mieć klasę przetwarzania kart kredytowych, nie przejmujesz się "jak" przetwarza kartę kredytową. Po prostu chcesz być w stanie: $creditCardProcessor->charge(10.99, $creditCardNumber); i oczekiwać, że zadziała.

Poprzez niektóre metody publiczne i inne prywatne lub chronione, możemy opuścić drogę wejścia dla innych, żeby wiedzieć, gdzie jest to bezpieczne, aby zadzwonić kod. Publiczne metody i zmienne nazywane są "interfejsem".

Dla każdej klasy masz implementację. W ten sposób klasa wykonuje swój obowiązek. Jeśli jest to lekcja smoothie, to w jaki sposób klasa dodaje składniki, jakie składniki dodaje itp. Są częścią wdrożenia. Kod zewnętrzny nie powinien znać i/lub dbać o implementację.

Druga strona tej klasy to jej interfejs. Interfejs jest publicznymi metodami, które programista klasy zamierzał nazwać zewnętrznym kodem. Oznacza to, że powinieneś móc wywołać dowolną publiczną metodę, która będzie działać poprawnie.

+0

Dziękuję za jasne definicje i przykład. –

8

Tworzymy prywatne metody, dzięki którym konsumenci naszych klas nie muszą dbać o szczegóły implementacji - mogą skupić się na kilku sprytnych rzeczach, które zapewniają im nasze zajęcia.

Ponadto, jesteśmy zobowiązani rozważyć każde możliwe użycie publicznych metod. Dzięki metodom prywatnym zmniejszamy liczbę funkcji, które klasa musi obsługiwać, i mamy więcej swobody, aby je zmienić.

Załóżmy, że masz klasę Queue - za każdym razem, gdy osoba wywołująca dodaje element do kolejki, może być konieczne zwiększenie pojemności kolejki. Ze względu na podstawową implementację ustawienie pojemności nie jest banalne, więc dzielisz ją na osobną funkcję w celu poprawy czytelności funkcji Enqueue. Ponieważ osoby dzwoniące nie dbają o pojemność kolejki (obsługujesz ją dla nich), możesz uczynić tę metodę metodą prywatną: dzwoniący nie rozpraszają się zbytecznymi metodami, nie musisz się obawiać, że rozmówcy wykonają śmieszne rzeczy do możliwości, a Ty możesz zmienić implementację w dowolnym momencie bez łamania kodu, który używa twojej klasy (o ile nadal ustawia pojemność w ograniczonych przypadkach użycia zdefiniowanych przez twoją klasę).

5

Istnieje kilka powodów używania enkapsulacji, jednym z najsilniejszych jest: Wyobraź sobie, używając dużej, skomplikowanej biblioteki napisanej przez kogoś innego. Jeśli każdy obiekt był niechroniony, można było nieświadomie uzyskać dostęp lub zmienić wartości, których programista nigdy nie zamierzał manipulować w ten sposób.

Ukrywanie danych ułatwia programowanie i łatwiejsze wdrożenie.

4

Chodzi o hermetyzację. Metody są prywatne, które wykonują wewnętrzne pomruki podczas eksponowania wdzięcznych funkcji, które ułatwiają pracę. Na przykład. możesz mieć funkcję $ product-> insert(), która wykorzystuje 4 wewnętrzne funkcje do sprawdzenia pojedynczego obiektu db, sprawi, że kwerenda będzie bezpieczna, itd. - są to funkcje wewnętrzne, które nie muszą być odsłonięte, a jeśli są wywoływane, mogą zepsuć inne struktury lub przepływy, które stworzyłeś.

8

Twoje ostatnie dwa punkty są dość dokładne - nie potrzebujesz wielu programistów, aby Twoje rzeczy były zmyślone. Jeśli wystarczająco długo będziesz pracować nad projektem, uświadomisz sobie, że zapomniałeś o tym, co zrobiłeś na początku.

Jednym z najważniejszych powodów do ukrycia czegoś jest to, że możesz bezpiecznie zmienić to na . Jeśli pole jest publiczne, a kilka miesięcy później chcesz je zmienić, aby za każdym razem, gdy pole się zmieniało, działo się coś innego, masz kłopoty. Ponieważ była publiczna, nie można w żaden sposób poznać ani zapamiętać, jak wiele innych miejsc uzyskało bezpośredni dostęp do tego pola. Jeśli jest prywatny, masz gwarancję, że nie zostanie on dotknięty poza tą klasą. Prawdopodobnie masz owiniętą wokół niej publiczną metodę i możesz łatwo zmienić zachowanie tej metody.

Ogólnie rzecz biorąc, więcej rzeczy upublicznia, tym bardziej musisz się martwić o kompatybilność z innym kodem.

0

Na przykład - metoda prywatna/chroniona może być częścią jakiejś klasy, która jest wywoływana w innej (publicznej) metodzie. Jeśli ta część jest nazywana bardziej publicznymi metodami, ma to sens. A jednak nie chcesz, aby te metody były nigdzie indziej wywoływane.

To samo dotyczy właściwości klasy. Tak, możesz pisać klasy ogólnodostępne, ale co w tym zabawa?

2

wielokrotnością sytuacja deweloper (nie bałagan pracę innych ludzi), lub po prostu więc nie bałagan własnej pracy zrobić przypadkowo?

Głównie te dwie rzeczy. Publiczna metoda mówi: "w ten sposób klasa ma być używana przez jej klientów", co czyni ją prywatną: "jest to szczegół implementacji, który może ulec zmianie bez ostrzeżenia i którego klienci nie powinni się martwić" ORAZ zmusza klientów do podążania za tym Rada.

Klasa z kilkoma dobrze udokumentowanymi publicznymi metodami jest znacznie łatwiejsza w użyciu dla kogoś, kto jej nie zna (która może być jego oryginalnym autorem, patrząc na nią po raz pierwszy od 6 miesięcy) niż ta, w której wszystko jest publiczna, włączając w to wszystkie drobne szczegóły implementacji, których nie obchodzi.

1

To sprawia, że ​​współpraca łatwiej powiedzieć użytkownikom swoich klas, jakie części nie powinny tak często zmieniać i można zagwarantować, że obiekt będzie w sensowny stanie, jeżeli stosują tylko metody publiczne.

To nie musi być tak surowe jak rozróżniania prywatne/publiczne/cokolwiek (mam na myśli egzekwowane przez język). Na przykład w języku Python jest to realizowane przez konwencję nazewnictwa. Wiesz, że nie powinieneś zadzierać z niczym oznaczonym jako niejawne.