Wikibooks

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

Przeglądaj historię interaktywnie
← poprzednia edycjanastępna edycja →
Usunięta treść Dodana treść
WizualnieWikikod
Szymon wro (dyskusja | edycje)
557 edycji
Szymon wro (dyskusja | edycje)
557 edycji
Linia 10:
 
Programowanie zorientowane obiektowo pozwala nam przekazywać większość przyziemnych i monotonnych czynności logicznych do samych danych; zmienia to nasze pojmowanie danych z pasywnych na aktywne.
Innymi słowy:
Mówiąc w innym sposób,
 
* Przestajemy traktować każdy kawałek danych jak skrzynkę z otwartym wiekiem, do której możemy sięgać bądź wkładać przedmioty.
* We stop treating each piece of data as a box with an open lid that lets us reach in and throw things around.
 
* Zaczynamy traktować każdy kawałek danych jak działającą maszynę z zamkniętą pokrywą oraz dobrze oznakowanymi przełącznikami i potencjometrami.
* We start treating each piece of data as a working machine with a closed lid and a few well-marked switches and dials.
 
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 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.
What is described above as a "machine" may be very simple or complex on the inside; we can't tell from the outside, and we don't allow ourselves to open the machine up (except when we are absolutely sure something is wrong with its design), so we are required to do things like flip the switches and read the dials to interact with the data. Once the machine is built, we don't want to have to think about how it operates.
 
Możesz sądzić że po prostu robimy sobie więcej pracy, ale to podejście to dobra robota w celu chronienia wszelkich rzeczy przed błędami.
You might think we are just making more work for ourselves, but this approach tends to do a nice job of preventing all kinds of things from going wrong.
 
Let'sZacznijmy startod withprzykładu, aktóry examplejest thatzbyt isprosty tooby simplemieć towartość bepraktyczną, ofale practicalpowinien value,zilustrować butprzynajmniej shouldjedną illustratecześć attej leastkoncepcji. partTwój ofsamochód thema concept.tripmeter<ref>Urządzenie Yourelektroniczne, carktóre hasrejestruje aczas tripmeter.pracy Itspojazdu, jobliczbę isprzejechany tokilometrów, keepzużycie trackpaliwa oforaz theinne distanceparametry</ref>. theJego carcelem hasjest travelledrejestrowanie sinceodległości thektórą lastprzebył timepojazd itsod momentu, resetgdy buttonzostał wasnaciśnięty pushedprzycisk. How would we model this in a programming language? In C, the tripmeter would just be a numeric variable, possibly of type float. The program would manipulate that variable by increasing its value in small increments, with occasional resets to zero when appropriate. What's wrong with that? A bug in the program could assign a bogus value to the variable, for any number of unexpected reasons. Anyone who has programmed in C knows what it is like to spend hours or days tracking down such a bug whose cause seems absurdly simple once it has been found. (The moment of finding the bug is commonly indicated by the sound of a loud slap to the forehead.)
 
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.
Linia 29:
 
It's worth noting here that the use of an OO language will not enforce proper OO design. Indeed it is possible in any language to write code that is unclear, sloppy, ill-conceived, buggy, and wobbly all over. What ruby does for you (as opposed, especially, to C++) is to make the practice of OO programming feel natural enough that even when you are working on a small scale you don't feel a necessity to resort to ugly code to save effort. We will be discussing the ways in which ruby accomplishes that admirable goal as this guide progresses; the next topic will be the "switches and dials" (object methods) and from there we'll move on to the "factories" (classes). Are you still with us?
{{Przypisy}}
<noinclude>
{{ProstaNawigacja|spis=Ruby|poprzart=Ruby/Iteratory|poprz=Iteratory|nastart=Ruby/Metody|nast=Metody}}
Źródło: „https://pl.wikibooks.org/wiki/Ruby/Myślenie_zorientowane_obiektowo”