2011-09-03 20 views
8

Czy istnieje sposób ograniczenia widoczności w PHP w taki sam sposób, jak widoczność "pakietu" działa w Javie lub przynajmniej widoczność "przyjaciela" w C++? Jaka jest najlepsza praktyka, aby utrzymać duży projekt OOP i nie pozwolić nikomu korzystać z jakiejkolwiek części kodu?Znajomość/widoczność pakietu PHP:

Używam prywatnej i chronionej widoczności tak często jak tylko mogę, ale czasami to za mało. Wiem o tym żądaniu: https://bugs.php.net/bug.php?id=55331. Czy jest jakiś postęp w implementacji tego czegoś do PHP? Czy istnieje sposób obejścia zabezpieczenia kodu (metod, zmiennych klasowych) przed dostępem z dowolnego miejsca?

+0

Nie tak jak pakiety w Javie, ale [namespaces] (http://php.net/manual/en/language.namespaces.php) będą służyć do enkapsulacji kodu. – Shef

+0

Czy możesz podać krótki przykład? –

+0

Po prostu myśl, jeśli naprawdę potrzebujesz, możesz użyć 'debug_backtrace' [http://php.net/manual/en/function.debug-backtrace.php], aby zobaczyć, jaki kod wywołuje twój kod. Zasadniczo pisanie własnej kontroli dostępu do środowiska wykonawczego. Prawdopodobnie więcej pracy niż jest warta, a 'debug_backtrace' ma wydajność. – Chris

Odpowiedz

3

Jak stwierdzono here:

Nie można ustawić zmienną po deklarowania przestrzeni nazw, ale zmienne zawsze będzie istnieć w zasięgu globalnym. Nigdy nie są powiązane z obszarami nazw . Można wywnioskować, że z powodu braku jakichkolwiek nazwa opisów rozdzielczości w http://www.php.net/manual/en/language.namespaces.faq.php

+0

Dzięki za odpowiedź. Howerver, nadal chciałbym poznać najlepsze praktyki lub obejścia, by osiągnąć pewną ochronę twojego kodu. –

+0

Nie widzę, jak to odpowiada na pytanie OP. Przestrzenie nazw nie mają nic wspólnego z widocznością dostępu. –

+0

@Markus Zgadzam się, że ta moja stara odpowiedź nie odnosi się do niej jednoznacznie, ale mówi, że (w przeciwieństwie do zmiennej) wszystko w dowolnej przestrzeni nazw jest globalne, dlatego nie ma sposobu, aby ukryć członków za pomocą modyfikatorów dostępu takich jak " prywatny "lub" chroniony ". – CodeCaster

8

Do dzisiaj nie ma konstrukt język ograniczyć widoczność. Ale można opisywać swoją klasę z PhpDocumentor na @internal:

Znacznik @internal może być używany jako odpowiednik tagu @api, wskazując, że związane z nimi elementy konstrukcyjne są wykorzystywane wyłącznie do wewnętrznych prac tego kawałka oprogramowania.

To użytkownik interfejsu API może zastosować się do tej sugestii.