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

Usunięta treść Dodana treść
Gotar (dyskusja | edycje)
 
Linia 18:
To co nazwaliśmy wyżej "maszyną" może być w środku bardzo proste lub bardzo złożone. Nie możemy tego określić patrząc z zewnątrz, jak i nie grzebiemy w jej wnętrzu (za wyjątkiem sytuacji, gdy jest 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 tak naprawdę to dobra robota w celu chronienia wielu 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 naciśnięcia przycisku. 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 do zera, jeśli zaszłaby taka potrzeba. A 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, co to znaczy spędzać godziny lub dni próbując ustalić gdzie tkwi taki błąd. Jego 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.)