W jaki sposób można uzyskać dostęp do właściwości obiektu z wnętrza metody obiektu?

głosy
81

Co to jest „purist” czy „poprawny” sposób dostępu do właściwości obiektu z wnętrza metody obiektu, który nie jest metoda getter / setter?

Wiem, że z zewnątrz obiektu należy użyć getter / setter, ale od wewnątrz byłoby po prostu zrobić:

Jawa:

String property = this.property;

PHP:

$property = $this->property;

lub chcesz zrobić:

Jawa:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Wybacz mi, jeśli mój Java jest trochę off, to już rok odkąd zaprogramowany w Javie ...

EDYTOWAĆ:

Wydaje się, ludzie są przy założeniu, że mówię o prywatnych lub chronionych zmiennych / tylko właściwości. Kiedy dowiedziałem OO uczono używać pobierające / ustawiające dla każdej nieruchomości, nawet jeśli było to publiczne (a właściwie powiedziano mi nigdy do żadnego Zmienna / własność publiczną). Tak, mogę być ruszania z fałszywego założenia, od uzyskania go. Wydaje się, że ludzie są odpowiedzi na to pytanie może powiedzieć, że trzeba mieć własności publicznej i że ci nie potrzebują pobierające i ustawiające, co jest sprzeczne co uczono mnie, a co mi chodzi, chociaż być może, że musi być omawiane jako dobrze. To chyba dobry temat na inne pytanie, choć ...

Utwórz 01/08/2008 o 17:10
źródło użytkownik
W innych językach...                            


18 odpowiedzi

głosy
58

Ma to religijny potencjał wojenny, ale wydaje mi się, że jeśli używasz getter / setter, należy go używać wewnętrznie, a także - przy użyciu zarówno doprowadzi do problemów serwisowych w dół drogi (np ktoś dodaje kod do seter że potrzebuje uruchomić za każdym razem, że właściwość jest ustawiona, a właściwość jest ustawiona wewnętrznie w / o tym seter miano).

Odpowiedział 01/08/2008 o 17:13
źródło użytkownik

głosy
41

Osobiście czuję się jak ważne jest, aby pozostać w zgodzie. Jeśli masz pobierające i ustawiające, korzystania z nich. Jedyny raz chciałbym dostępu do pola bezpośrednio Akcesor jest, gdy ma dużo napowietrznych. Może poczuć się jak jesteś wzdęcia kod niepotrzebnie, ale z pewnością może zaoszczędzić mnóstwo bólu głowy w przyszłości. Klasycznym przykładem:

Później można pragnąć, aby zmienić sposób, że prace polowe. Może powinien być obliczany na locie, a może chcesz użyć innego rodzaju do sklepu podkładowej. Jeśli właściwości dostępu bezpośrednio, jak zmiana, która może złamać bardzo dużo kodu w jednym pęcznienia foop.

Odpowiedział 01/08/2008 o 19:23
źródło użytkownik

głosy
25

Jestem dość zaskoczony, jak jednomyślni sentyment jest to, że gettersi ustawiaczy są w porządku i dobre. Proponuję zapalającą artykuł Allen Holub „ pobierające i ustawiające metody są złe ”. To prawda, tytuł jest dla wartości szoku, ale autor czyni ważne punkty.

Zasadniczo, jeśli masz gettersi settersza każdym polu prywatnym, robicie te pola tak dobry jak publiczne. Byłbyś bardzo mocno naciskany, by zmienić typ prywatnym polu bez tętnienia skutki dla każdej klasy, która wywołuje że getter.

Ponadto, od ściśle OO punktu widzenia, obiekty powinny być odpowiadanie na wiadomości (metody), które odpowiadają ich (mam nadzieję) pojedynczej odpowiedzialności. Zdecydowana większość gettersi settersnie ma sensu ich obiektów składowych; Pen.dispenseInkOnto(Surface)więcej sensu niż do mnie Pen.getColor().

Pobierające i ustawiające zachęcają również użytkownikom klasy zapytać obiektu dla niektórych danych, wykonywania obliczeń, a następnie ustawić inną wartość w obiekcie, lepiej znany jako programowanie proceduralne. Można by lepiej służyły po prostu powiedzieć, że obiekt, aby robić to, co jechaliśmy w pierwszej kolejności; znany również jako fachowych informacji idiomu.

Pobierające i ustawiające są jednak niezbędne zło na granicach warstw - UI, wytrwałości, i tak dalej. Ograniczony dostęp do wewnętrznych klasy, takich jak znajomego hasła C ++ 's, pakiet zabezpieczony dostęp Java, .NET za dostęp wewnętrzny, a Wzór Friend klasy mogą pomóc zmniejszyć widoczność gettersi ustawiające tylko do tych, którzy ich potrzebują.

Odpowiedział 19/09/2008 o 01:13
źródło użytkownik

głosy
18

To zależy od tego, w jaki sposób właściwość jest używana. Na przykład, że masz obiekt studenta, który ma właściwość name. Można użyć metody Get wyciągnąć nazwę z bazy danych, jeśli nie zostało już pobrane. W ten sposób zmniejszają niepotrzebnych połączeń do bazy danych.

Teraz powiedzmy, że dysponują całkowitą licznik w swoim obiekcie, który zlicza liczbę razy nazwa została wywołana. Możesz użyć metody nie dostać od wewnątrz obiektu, ponieważ spowodowałoby to nieprawidłową liczbę.

Odpowiedział 01/08/2008 o 17:19
źródło użytkownik

głosy
13

PHP oferuje mnóstwo sposobów, aby sobie z tym poradzić, w tym magicznych metod __geti __set, ale wolę wyraźne pobierające i ustawiające. Dlatego:

  1. Poprawności może być umieszczony w ustawiające (i pobierające tego względu)
  2. Intellisense współpracuje z jawnych metod
  3. Nie ma wątpliwości, czy dana nieruchomość jest tylko do odczytu, zapisu lub tylko do odczytu i zapisu
  4. Pobieranie właściwości wirtualnych (tj obliczone wartości) wygląda tak samo jak zwykłe właściwości
  5. można łatwo ustawić właściwości obiektu, który nigdy nie jest faktycznie nigdzie zdefiniowane, która następnie przechodzi nieudokumentowanych
Odpowiedział 24/09/2008 o 18:24
źródło użytkownik

głosy
12

Ja po prostu za burtę tutaj?

Być może ;)

Innym rozwiązaniem byłoby wykorzystanie prywatny / metoda chroniony rzeczywiście zrobić się (buforowanie / db / etc), a wrapper publicznej dla niego, że zwiększa ilość:

PHP:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

a następnie od wewnątrz samego obiektu

PHP:

$name = $this->_getName();

W ten sposób można nadal korzystać z tego pierwszego argumentu za coś innego (jak wysłanie flagę czy należy stosować buforowane dane tutaj być może).

Odpowiedział 01/08/2008 o 17:43
źródło użytkownik

głosy
11

I musi być brakuje tu chodzi, dlaczego byłoby użyć metody pobierającej wewnątrz obiektu, aby uzyskać dostęp do właściwości tego obiektu?

Biorąc to jej zawarcia getter powinien wezwać getter, które powinny wywołać getter.

Więc powiedziałbym wewnątrz metody dostępu przedmiot nieruchomość bezpośrednio, zwłaszcza widząc, jak wywołanie innej metody w tym obiekcie (który będzie po prostu przejść się bezpośrednio w każdym razie potem zwrócić go) jest po prostu bez sensu, marnotrawstwem ćwiczenia (albo mają źle zrozumiałem pytanie ).

Odpowiedział 04/06/2011 o 16:42
źródło użytkownik

głosy
7

Chciałbym powiedzieć, że lepiej jest użyć metody dostępowe nawet w obrębie obiektu. Oto punkty, które od razu przychodzą mi do głowy:

1) Należy to zrobić w interesie zachowania spójności z dostępów wykonanych na zewnątrz obiektu.

2) W niektórych przypadkach te metody dostępowe mogą być robi więcej niż tylko dostęp do boiska; mogą one być jakiejś dodatkowej obróbki (chociaż jego rzadkie). Jeśli jest to przypadek, otwierając pole bezpośrednio byś brakuje, że dodatkowa obróbka i twój program może nie udać, jeśli przetwarzanie to zawsze jest do zrobienia w ciągu tych dostępów

Odpowiedział 20/01/2010 o 09:32
źródło użytkownik

głosy
7

Sposób purist OO jest unikanie zarówno i śledzić Prawo Demeter przy użyciu Powiedz Nie pytaj podejście.

Zamiast się wartość właściwości obiektu, który szczelnie pary dwie klasy, korzystania z przedmiotu jako parametr np

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

W przypadku, gdy obiekt był rodowitym typ, np int, należy użyć metody dostępu, nazwę go nie domenie problemu dziedziny programowania.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Pozwoli to na utrzymanie enkapsulacji oraz wszelkie warunki lub post-niezmienniki utrzymaniu. Można również użyć metody setter aby utrzymać żadnych warunków wstępnych lub niezmienników zależne, jednak nie wpaść w pułapkę nazywając je ustawiające, wrócić do Hollywood Zasady nazewnictwa podczas korzystania z idiomu.

Odpowiedział 24/09/2008 o 18:04
źródło użytkownik

głosy
7

Jeśli przez „purist” masz na myśli „najbardziej hermetyzacji”, to ja zazwyczaj deklarują wszystkie moje pola jako prywatne, a następnie użyć this.field od wewnątrz samej klasy, ale wszystkie inne zajęcia, w tym podklas, dostęp stan instancji przy użyciu pobierające.

Odpowiedział 22/08/2008 o 12:15
źródło użytkownik

głosy
6

To zależy. To bardziej kwestia stylu niż cokolwiek innego, i nie ma twarde reguły.

Odpowiedział 01/10/2008 o 11:51
źródło użytkownik

głosy
6

Jeśli nie będę zmieniać właściwość użyję get_property()metody publiczne, chyba, że to specjalne okazje, takie jak MySQLi obiektu wewnątrz innego obiektu w takim przypadku będę tylko publiczna własność i odnoszą się do niego jako $obj->object_property.

Wewnątrz obiektu jest zawsze $ this-> nieruchomość dla mnie.

Odpowiedział 22/08/2008 o 12:34
źródło użytkownik

głosy
6

Prywatne pola o właściwościach publicznych lub chronionych. Dostęp do wartości powinny przejść właściwości i być kopiowana do zmiennej lokalnej, jeśli będą wykorzystywane więcej niż jeden raz w metodzie. Wtedy i tylko wtedy, gdy reszta aplikacji tak całkowicie manipulowane, zakołysał się, a poza tym zoptymalizowany, gdzie dostęp do wartości przechodząc przez ich assosciated właściwości stał się wąskim gardłem (I że nigdy nie będzie nigdy zdarzyć, gwarantuję) należy nawet zacząć rozważyć pozwalając coś innego niż właściwości bezpośrednio dotknąć ich zmienne podkładu.

NET programiści mogą wykorzystać właściwości automatycznych do egzekwowania tego skoro nie można nawet zobaczyć zmienne podkładowe w czasie projektowania.

Odpowiedział 18/08/2008 o 18:43
źródło użytkownik

głosy
6

Znalazłem za pomocą ustawiające / getters wykonane mój kod łatwiejsze do odczytania. Podoba mi się również to daje kontrolę gdy inne klasy użyć metod i jeśli mogę zmienić dane nieruchomość będzie przechowywać.

Odpowiedział 18/08/2008 o 18:37
źródło użytkownik

głosy
6

Mogę się mylić, bo jestem samoukiem, ale nigdy przez użytkownika właściwości publiczne w moich klas Javy, zawsze są prywatne lub chronione, tak, że kod na zewnątrz musi przejść przez pobierające / ustawiające. To lepsze dla celów konserwacji / modyfikacji. I na wewnątrz kodu klasy ... Jeśli metoda getter jest trywialne używam właściwość bezpośrednio, ale zawsze korzystać z metod ustawiających bo może łatwo dodać kod do ognia zdarzenia jeśli życzę.

Odpowiedział 06/08/2008 o 15:43
źródło użytkownik

głosy
5

Lubię odpowiedź przez cmcculloh , ale wydaje się, że najbardziej prawidłowa jest odpowiedź przez Greg Hurlman . Użyj getter / ustawiające cały czas, jeśli zaczął używać ich z GetGo i / lub są wykorzystywane do pracy z nimi.

Tak na marginesie, ja osobiście uważam, że za pomocą getter / ustawiające sprawia, że ​​łatwiej odczytać kod i debugowania później.

Odpowiedział 15/09/2008 o 10:46
źródło użytkownik

głosy
5

Cóż, wydaje się z domyślnej implementacji C # 3.0 properties, decyzja podejmowana jest dla ciebie; trzeba ustawić właściwość używając (ewentualnie) setter prywatną własność.

Ja osobiście używać tylko dla członków za prywatną gdy nie spowodowałyby one przedmiotem spadać w sposób mniej niż stan pożądany, na przykład podczas inicjalizacji lub gdy buforowanie / leniwy załadunku jest zaangażowana.

Odpowiedział 01/08/2008 o 17:56
źródło użytkownik

głosy
4

Jak stwierdzono w niektórych komentarzach: Czasem należy, czasami nie należy. Duża część o zmiennych prywatnych jest to, że jesteś w stanie zobaczyć wszystkie miejsca są one wykorzystywane, gdy coś zmienić. Jeśli getter / setter robi coś, czego potrzeba, użyj go. Jeśli to nie ma znaczenia, ty decydujesz.

Przeciwnym wypadku mogłyby być wykonane, że w przypadku korzystania z getter / setter i getter ktoś zmienia / Ustawiacz oni przeanalizować wszystkie miejsca getter i setter jest używane wewnętrznie, aby zobaczyć, czy coś się psuje.

Odpowiedział 01/08/2008 o 18:01
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more