Kiedy użyć zmiennej instancji obiektu w porównaniu z przekazaniem argumentu do metody

Jak wybrać pomiędzy przekazywaniem argumentów do metody a deklarowaniem ich jako zmiennych instancji obiektu, które są widoczne dla wszystkich metod obiektu?

Wolę trzymać zmienne instancji na liście na końcu klasy, ale ta lista staje się dłuższa wraz z rozwojem mojego programu. Myślę, że jeśli zmienna jest przekazywana wystarczająco często, powinna być widoczna dla wszystkich metod, które jej potrzebują, ale wtedy zastanawiam się, " jeśli wszystko jest publiczne, nie będzie potrzeby przekazywania cokolwiek!"

Author: user2514157, 2008-12-06

5 answers

Ponieważ odnosisz się do zmiennych instancji, zakładam, że pracujesz w języku zorientowanym obiektowo. Do pewnego stopnia, kiedy używać zmiennych instancji, jak definiować ich zakres i kiedy używać zmiennych lokalnych jest subiektywne, ale istnieje kilka reguł, których możesz przestrzegać podczas tworzenia klas.

  • Zmienne instancji są zazwyczaj uważane za atrybuty klasy. pomyśl o nich jako o przymiotnikach obiektu, który zostanie utworzony z twojej klasy. Jeśli dane wystąpienia mogą być używane do opisania obiektu, to prawdopodobnie można się założyć, że jest to dobry wybór na przykład dane.

  • Zmienne lokalne są używane w zakresie metod, aby pomóc im zakończyć pracę. zazwyczaj metoda powinna mieć na celu uzyskanie niektórych danych, zwrócenie niektórych danych i/lub przetworzenie / uruchomienie algorytmu na niektórych danych. Czasami pomaga myśleć o zmiennych lokalnych jako sposobach pomagających metodzie uzyskać od początku do końca.

  • Instancja zmienna zakres jest nie tylko dla bezpieczeństwa, ale również dla enkapsulacji, jak również. nie zakładaj, że " celem powinno być zachowanie prywatności wszystkich zmiennych."W przypadku dziedziczenia, tworzenie zmiennych jako chronionych jest zwykle dobrą alternatywą. Zamiast oznaczać publicznie wszystkie dane wystąpienia, tworzysz gettery/settery dla tych, które muszą być dostępne w świecie zewnętrznym. Nie udostępniaj ich wszystkich - tylko tych, których potrzebujesz. To nastąpi w całym cykl życia rozwoju-trudno się domyślić z początku.

Jeśli chodzi o przekazywanie danych po klasie, trudno powiedzieć, że to, co robisz, jest dobrą praktyką bez zobaczenia kodu . Czasami operowanie bezpośrednio na danych instancji jest w porządku, innym razem nie. Moim zdaniem jest to coś, co wiąże się z doświadczeniem - w miarę rozwoju umiejętności myślenia obiektowego rozwiniesz nieco intuicję.

 57
Author: Tom,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-06 10:45:27

Głównie zależy to od czasu życia danych przechowywanych w zmiennej. Jeśli dane są używane tylko podczas obliczeń, przekaż je jako parametr. Jeżeli dane są związane z okresem życia obiektu, należy użyć zmiennej instancji.

Kiedy lista zmiennych staje się zbyt długa, może warto pomyśleć o refaktoryzacji niektórych części klasy do nowej klasy.

 47
Author: H-Man2,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-06 10:59:22

Moim zdaniem, zmienne instancji są potrzebne tylko wtedy, gdy dane będą używane w różnych wywołaniach.

Oto przykład:

myCircle = myDrawing.drawCircle(center, radius);

Teraz pozwala na obrazowanie Klasa myDrawing używa 15 funkcji pomocniczych do tworzenia obiektu myCircle i każda z tych funkcji będzie potrzebowała środka i promienia. Nadal nie powinny być ustawiane jako zmienne instancji klasy myDrawing. Bo już nigdy nie będą potrzebne.

Z drugiej strony, Klasa myCircle będzie musiała przechowywać zarówno środek i promień jako zmienne instancji.

myCircle.move(newCenter);
myCircle.resize(newRadius);

Aby obiekt myCircle wiedział jaki jest jego promień i środek podczas wykonywania tych nowych wywołań, muszą one być przechowywane jako zmienne instancji, a nie tylko przekazywane do funkcji, które ich potrzebują.

Więc zasadniczo zmienne instancji są sposobem na zapisanie" stanu " obiektu. Jeżeli zmienna nie jest konieczna do poznania stanu obiektu, to nie powinna być zmienną instancyjną.

A co do robienia wszystkiego publiczne. To może ułatwić Ci życie w tej chwili. Ale wróci, by cię prześladować. Pease nie.

 22
Author: ng.mangine,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-06 10:47:12

IMHO:

Jeśli zmienna stanowi część stanu instancji, wtedy powinna być zmienną instancji-classinstance ma-a instancevariable.

Jeśli odkryłem, że wielokrotnie przekazuję coś do metod instancji, lub odkryłem, że mam dużą liczbę zmiennych instancji, prawdopodobnie spróbowałbym spojrzeć na mój projekt na wypadek, gdybym coś przeoczył lub zrobił gdzieś złą abstrakcję.

Hope it helps

 4
Author: brabster,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-06 10:40:35

Oczywiście łatwo jest utrzymać jedną dużą listę zmiennych publicznych w klasie. Ale nawet intuicyjnie można powiedzieć, że to nie jest droga.

Zdefiniuj każdą zmienną tuż przed jej użyciem. Jeśli zmienna obsługuje funkcję określonej metody, użyj jej tylko w zakresie metody.

Pomyśl także o bezpieczeństwie, publiczna zmienna klasy jest podatna na niepożądane zmiany z "zewnętrznego" kodu. Twoim głównym celem powinno być zachowanie prywatności wszystkich zmiennych i każda zmienna, która nie jest, powinna mieć bardzo dobry powód, aby tak być.

Jeśli chodzi o przekazywanie parametrów przez cały stos, to bardzo szybko może być nieprzyjemnie. Zasadą jest, aby Twoje podpisy metody były czyste i eleganckie. Jeśli widzisz wiele metod wykorzystujących te same dane, zdecyduj, czy jest to wystarczająco ważne, aby być członkiem klasy, a jeśli nie, przefaktoruj kod, aby miał więcej sensu.

Sprowadza się do zdrowego rozsądku. Zastanów się dokładnie, gdzie i dlaczego deklarujesz każde nowe zmienna, Jaka powinna być jej funkcja, a stamtąd podjąć decyzję, w jakim zakresie powinna żyć.

 3
Author: Yuval Adam,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-06 10:39:52