Ruby/Myślenie zorientowane obiektowo: Różnice pomiędzy wersjami
Usunięta treść Dodana treść
Szymon wro (dyskusja | edycje) |
Szymon wro (dyskusja | edycje) Nie podano opisu zmian |
||
Linia 16:
* Zaczynamy traktować każdy kawałek danych jak działającą maszynę z zamkniętą pokrywą oraz dobrze oznakowanymi przełącznikami i potencjometrami.
To co nazwaliśmy wyżej "maszyną" może mieć bardzo proste lub bardzo złożone wnętrze. Nie możemy tego określić patrząc z zewnątrz, jak i nie pozwalamy sobie grzebać w środku (za wyjątkiem sytuacji, gdy jesteśmy 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
Możesz sądzić że po prostu robimy sobie więcej
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.
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.
Nie dostarczamy sposobu, by można było przypisać do tripmetera arbitralne wartości. Dlaczego? Ponieważ wszyscy wiemy, że drogomierze nie działają w ten sposób. Jest tylko kilka rzeczy, które powinieneś być w stanie zrobić z tripmeterem, i to wszystko na co pozwalamy. Zatem, jeśli coś innego w programie błędnie spróbuje umieścić jakąś inną wartość (powiedzmy, docelową temperaturę ze sterowania klimatyzacji w samochodzie) w tripmeterze, będzie natychmiastowa wskazówka co poszło nie tak. Będziemy poinformowani gdy program zostanie uruchomiony (lub możliwe, że podczas kompilacji, zależnie od natury języka programowania), że nie mamy prawa przypisywać arbitralnych wartości do obiektów <tt>Tripmeter</tt>. Wiadomość może nie będzie dokładnie tak jasna, ale będzie ona sensownie zbliżona. Nie uchroni nas to przed błędem, prawda? Ale za to szybko wskażen nam w jakim kierunku leży przyczyna błędu. To tylko jeden z kilkunastu sposobów, w jaki OOP może zaoszczędzić nam dużo zmarnowanego czasu.
We commonly take one step of abstraction above this, because it turns out to be as easy to build a factory that makes machines as it is to make an individual machine. We aren't likely to build a single tripmeter directly; rather, we arrange for any number of tripmeters to be built from a single pattern. The pattern (or if you like, the tripmeter factory) corresponds to what we call a class, and an individual tripmeter generated from the pattern (or made by the factory) corresponds to an object. Most OO languages require a class to be defined before we can have a new kind of object, but ruby does not.
|