Ruby/Kontrola dostępu: Różnice pomiędzy wersjami
Usunięta treść Dodana treść
Szymon wro (dyskusja | edycje) Nie podano opisu zmian |
|||
Linia 14:
</pre>
Wydaje się, że nasza nowa metoda nie należy do żadnej klasy, ale w rzeczywistości Ruby dodał ją do klasy <tt>Object</tt> która jest nadklasą każdej innej klasy. W rezultacie każdy obiekt powinien mieć możliwość używania tej metody. Jest to prawdą, ale z małym kruczkiem: jest to ''prywatna'' metoda każdej klasy. Wprawdzie będziemy jeszcze dokładnie rozważać co to znaczy, ale zauważmy, że jedną z konsekwencji tego faktu jest to, że metoda ta może być wywołana tylko w funkcyjnym stylu, jak poniżej:
<pre>
ruby> class Foo
| def fourth_power_of(x)
Linia 24 ⟶ 25:
ruby> Foo.new.fourth_power_of 10
10000
</pre>
Wyraźnie nie możemy wywołać metody na rzecz obiektu:
<pre>
ruby> "fish".square(5)
ERR: (eval):1: private method `square' called for "fish":String
</pre>
To raczej zręcznie chroni czysto obiektową naturę Rubiego (funkcje są wciąż metodami obiektów, ale odbiorcą jest domyślnie <tt>self</tt>) dostarczając funkcji które mogą być zapisane podobnie jak w bardziej tradycyjnym języku.
Powszechną dyscypliną umysłową w programowaniu obiektowym, którą zasugerowaliśmy we wcześniejszym rozdziale, jest problem rozdzielenia ''specyfikacji'' i ''implementacji'', czyli ''jakie'' zadania wymagamy by obiekt wypełniał i ''jak'' je właściwie wypełnia. Wewnętrzne prace obiektu powinny być zazwyczaj ukryte przed jego użytkownikami. Powinni oni dbać o to, co wchodzi i wychodzi do/z obiektu oraz ufać, że obiekt wie co robi wewnętrznie z danymi. Z tego powodu często pomocne jest, gdy klasa posiada metody niewidoczne z zewnątrz, ale używane wewnętrznie, które mogą być poprawione przez programistę kiedy tylko zajdzie taka potrzeba, bez zmieniania sposobu, w jaki użytkownicy widzą obiekty danej klasy. W trywialnym przykładzie poniżej, pomyśl o metodzie <tt>engine</tt> jako o niewidocznych pracach klasy.
<pre>
ruby> class Test
| def times_two(a)
Linia 51 ⟶ 56:
6 times two is 12.
nil
</pre>
We might have expected test.engine(6) to return 12, but instead we learn that engine is inaccessible when we are acting as a user of a Test object. Only other Test methods, such as times_two, are allowed to use engine. We are required to go through the public interface, which consists of the times_two method. The programmer who is in charge of this class can change engine freely (here, perhaps by changing b*2 to b+b, assuming for the sake of argument that it improved performance) without affecting how the user interacts with Test objects. This example is of course much too simple to be useful; the benefits of access controls become more clear only when we begin to create more complicated and interesting classes.
<noinclude>
{{ProstaNawigacja|spis=Ruby|poprzart=Ruby/Redefiniowanie metod|poprz=Redefiniowanie metod|nastart=Ruby/Metody singleton|nast=Metody
</noinclude>
|