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

Usunięta treść Dodana treść
zamiana ProstaNawigacja->Subst:Naw
Linia 5:
Istnieje wiele różnorodnych odpowiedzi na to pytanie, które można by prawdopodobnie sprowadzić do tego samego. Zamiast jednak zbyt szybko podsumowywać to zagadnienie, spróbujmy pomyśleć przez chwilę o tradycyjnym paradygmacie programowania.
 
Tradycyjnie, problem programowania rozwiązywany jest przez podejście, w którym obecne są różne typy reprezentacji danych oraz procedury które na tych danych operują. W modelu tym dane są obojętne, pasywne i bezradne; oczekują na łaskę dużegodużej proceduralnej bryły, która jest aktywna, logiczna i wszechmocna.
 
Problem w tym podejś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ż pamiętać jak cała rzecz działa. Drobne pomyłki w sposobie myślenia i usterki 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 zaczyna przypominać noszenie w kółko wściekłej kałamarnicy i walkę z jej mackami. 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ę sposobu pracy.