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 by wpływać na dane. 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 pracyroboty, 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. HowJak wouldmoglibyśmy wewymodelować modelto thisw injęzyku a programming languageprogramowania? InW C, the tripmeter wouldbyłby justpo beprostu azmienną numeric variablenumeryczną, possiblymożliwe ofże typetypu <tt>float</tt>. TheProgram programmógłby wouldmanipulować manipulate thatzmienną variablezwiększając byjej increasingwartość itsprzyrostowo valuemałymi inkrokami, smallz increments,okazjonalnym withresetowaniem occasionaljej resetswartości tona zero, whenjeśli appropriate.zaszłaby What'staka wrongpotrzeba. withI that?co Aw bugtym inzłego? theZ programnieokreślonej couldliczby assignniespodziewanych apowodów bogusbłąd valuew toprogramie themógłby variable,przypisać forbłędną anywartość numberdo of unexpected reasonszmiennej. AnyoneKażdy, whokto hasprogramował programmed inw C knowswie, whatże itco isto likeznaczy tospędzać spendgodziny hourslub ordnie dayspróbując trackingustalić downgdzie suchtkwi ataki bugbłąd, whosektórego causeprzyczyna, seemsjak absurdlysię simplejuż once itodkryje, haswydaje beensię foundabsurdalnie głupia. (TheMoment momentznajdowania ofbłędu findingjest theprzeważnie bugrozpoznawany isprzez commonlyodgłos indicatedgłośnego by the sound of a loud slap toklepnięcia thew foreheadczoł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.
The same problem would be attacked from a much different angle in an object-oriented context. The first thing a programmer asks when designing the tripmeter is not "which of the familiar data types comes closest to resembling this thing?" but "how exactly is this thing supposed to act?" The difference winds up being a profound one. It is necessary to spend a little bit of time deciding exactly what an odometer is for, and how the outside world expects to interact with it. We decide to build a little machine with controls that allow us to increment it, reset it, read its value, and nothing else.
 
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 don't provide a way for a tripmeter to be assigned arbitrary values; why? because we all know tripmeters don't work that way. There are only a few things you should be able to do with a tripmeter, and those are all we allow. Thus, if something else in the program mistakenly tries to place some other value (say, the target temperature of the vehicle's climate control) into the tripmeter, there is an immediate indication of what went wrong. We are told when running the program (or possibly while compiling, depending on the nature of the language) that we are not allowed to assign arbitrary values to Tripmeter objects. The message might not be exactly that clear, but it will be reasonably close to that. It doesn't prevent the error, does it? But it quickly points us in the direction of the cause. This is only one of several ways in which OO programming can save a lot of wasted time.
 
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.