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

Usunięta treść Dodana treść
Szymon wro (dyskusja | edycje)
Linia 20:
Możesz sądzić że po prostu robimy sobie więcej roboty, ale to podejście to dobra robota w celu chronienia wszelkich 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ę przejechany kilometrów, zużycie paliwa oraz inne parametry</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 rozpoznawanyrozpoznawalny przez odgłos głośnego klepnięcia w czoło.)
 
Ten sam problem można zaatakować z zupełnie innej strony w kontekście zorientowanym obiektowo. Pierwszym pytaniem, o które zadaje programista, gdy projektuje tripmeter nie jest "jaki znany mi typ danych odpowiada najbliżej tej rzeczy?" ale "jak właściwie ta rzecz ma działać?" Różnica jest zasadnicza. Potrzeba poświęcić odrobinę czasu ustalając po co dokładnie jest drogomierz i w jaki sposób zewnętrzny świat zamierza się z nim kontaktować. Decydujemy się zbudować małą maszynkę z metodami regulacji które pozwolą nam zwiększać wartość, kasować ją, czytać ją, i nic poza tym.