Wikibooks

Ruby/Myślenie zorientowane obiektowo: Różnice pomiędzy wersjami

Przeglądaj historię interaktywnie
← poprzednia edycjanastępna edycja →
Usunięta treść Dodana treść
WizualnieWikikod
Szymon wro (dyskusja | edycje)
557 edycji
Szymon wro (dyskusja | edycje)
557 edycji
Nie podano opisu zmian
Linia 1:
== Myślenie zorientowane obiektowo ==
 
''Zorientowany obiektowo'' to chwytliwe określenie. Określenie czegokolwiek jako "zorientowane obiektowo" brzmi naprawdę mądrze. Ruby mieniokreśla się językiemjako skryptowymjęzyk zorientowanymskryptowy zorientowany obiektowo;, ale co to naprawdę znaczy "zorientowany obiektowo"?
 
Istnieje wiele różnorodnych odpowiedzi na to pytanie, które można by prawdopodobnie sprowadzić do tego samego. Zamiast jednak zbyt szybko podsumowywać to podsumowywaćzagadnienie, spróbujmy pomyśleć przez chwilę o tradycyjnym paradygmacie programowania.
 
Tradycyjnie, problem programowania jest rozwiązywany jest przez podejście, zw różnymiktórym typamiobecne są różne typy reprezentacji danych oraz proceduramiprocedury które operują na tych danych operują. W modelu tym dane są obojętne, pasywne i bezradne; oczekują na łaskę dużego proceduralnej bryły, która jest aktywna, logiczna i wszechmocna.
 
Problem zw tym podejściempodejściu jest taki, że programy są pisane przez programistów, którzy są tylko ludźmi i potrafią pamiętać i kontrolować w danym czasie tylko pewną skończoną ilość detali. Jak projekt staje się większy jego proceduralny rdzeń rośnie do punktu, w którym trudno jest już trudno pamiętać jak cała rzecz działa. MałeDrobne pomyłki w sposobie myślenia i błędyusterki typograficzne stają się przyczyną dobrze zamaskowanych błędów. Złożone i niezamierzone interakcje zaczynają wynurzać się z proceduralnego rdzenia i zarządzanie tym stajezaczyna się jakprzypominać noszenie dookoław kółko wściekłej kałamarnicy i walczenie,walkę byz jej macki nie dotykały twojej twarzymackami. Są pewne wytyczne dotyczące programowania, które mogą pomóc zminimalizować i zlokalizować błędy w tym tradycyjnym paradygmacie, ale jest lepsze rozwiązanie które pociąga za sobą fundamentalną zmianę naszego sposobu pracy.
 
Programowanie zorientowane obiektowo pozwala nam przekazywać większość przyziemnych i monotonnych czynności logicznych do samych danych; zmienia to nasze pojmowanie danych z pasywnych na aktywne.
Innymi słowy:
 
* Przestajemy traktować każdy kawałek danych jak skrzynkę z otwartym wiekiem, do której możemy sięgaćwkładać bądźlub wkładaćwyjmować przedmioty.
 
* Zaczynamy traktować każdy kawałek danych jak działającąpracującą maszynę, z zamkniętą pokrywą orazi dobrze oznakowanymi przełącznikami ioraz potencjometrami.
 
To co nazwaliśmy wyżej "maszyną" może miećbyć w środku bardzo proste lub bardzo złożone wnętrze. Nie możemy tego określić patrząc z zewnątrz, jak i nie pozwalamygrzebiemy sobiew grzebaćjej w środkuwnętrzu (za wyjątkiem sytuacji, gdy jesteśmyjest absolutnie pewnie, że coś jest nie tak z jej projektem), więc jedyne czego się od nas wymaga by wpływać na dane to przekręcanie przełączników i odczytywanie potencjometrów. Jak już maszyna jest zbudowana nie chcemy sobie dalej zaprzątać głowy tym, jak ona działa.
 
Możesz sądzić że po prostu robimy sobie więcej roboty, ale totak podejścienaprawdę to dobra robota w celu chronienia wszelkichwielu rzeczy przed błędami.
 
Zacznijmy od przykładu, który jest zbyt prosty by mieć wartość praktyczną, ale powinien zilustrować przynajmniej jedną cześć tej koncepcji. Twój samochód ma tripmeter<ref>Urządzenie elektroniczne, które rejestruje czas pracy pojazdu, liczbę przejechanych kilometrów, zużycie paliwa oraz inne parametry - przyp. tłum.</ref>. Jego celem jest rejestrowanie odległości którą przebył pojazd od momentu, gdy został naciśnięty przycisk. Jak moglibyśmy wymodelować to w języku programowania? W C, tripmeter byłby po prostu zmienną numeryczną, możliwe że typu <tt>float</tt>. Program mógłby manipulować tą zmienną zwiększając jej wartość przyrostowo małymi krokami, z okazjonalnym resetowaniem jej wartości na zero, jeśli zaszłaby taka potrzeba. I co w tym złego? Z nieokreślonej liczby niespodziewanych powodów błąd w programie mógłby przypisać błędną wartość do zmiennej. Każdy, kto programował w C wie, że co to znaczy spędzać godziny lub dnie próbując ustalić gdzie tkwi taki błąd, którego przyczyna, jak się już ją odkryje, wydaje się absurdalnie głupia. (Moment znajdowania błędu jest przeważnie rozpoznawalny przez odgłos głośnego klepnięcia w czoło.)
Źródło: „https://pl.wikibooks.org/wiki/Ruby/Myślenie_zorientowane_obiektowo”