Wersja z 01:45, 24 lip 2007 edytuj Szymon wro (dyskusja \| edycje) 557 edycji Nie podano opisu zmian ← poprzednia edycja		Wersja z 02:40, 24 lip 2007 edytuj anuluj edycję Szymon wro (dyskusja \| edycje) 557 edycji →‎Myślenie zorientowane obiektowo następna edycja →
Linia 1: == Myślenie zorientowane obiektowo == ''Zorientowany obiektowo'' to chwytliwe określenie. Określenie czegokolwiek jako "zorientowane obiektowo" brzmi naprawdę mądrze. Ruby mieni się językiem skryptowym zorientowanym obiektowo; ale co to naprawdę znaczy "zorientowany obiektowo"? Linia 26: 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. Zazwyczaj robimy jeszcze jeden krok w abstrakcji, ponieważ okazuje się, że równie łatwo jak naszą maszynę można zbudować całą fabrykę która tworzy takie maszyny. Prawdopodobnie nie budowalibyśmy bezpośrednio pojedynczego tripmetera, raczej zbudowalibyś dowolną ilość tripmeterów z pojedynczego wzorca. Ten wzorzec (lub jak wolisz, fabryka tripmeterów) odpowiada temu co nazywamy klasą, i indywidualny tripmeter wygenerowany z tego wzorca (lub zbudowany przez fabrykę) odpowiada obiektowi. Większość języków OO wymaga by klasa była zdefiniowana nim będziemy mogli uzyskać nowy rodzaj obiektu, ale nie Ruby. 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. Warto tu zanotować, że użycie języka zorientowanego obiektowo nie wymusza odpowiedniego zorientowanego obiektowo projektu. W rzeczy samej, pisanie kodu, który jest niejasny, niechlujny, źle zaczęty, pełny błędów i chwiejący się dookoła, możliwe jest w każdym języku. To co Ruby robi dla ciebie (szczególnie w przeciwieństwie do C++) to to, że praktyka programowania zorientowanego obiektowo jest na tyle naturalna, że nawet gdy pracujesz w małej skali nie czujesz potrzeby by uciec się brzydkiego kodu by zaoszczędzić sobie wysiłku. Będziemy omawiać sposoby, w których Ruby osiąga ten wspaniały cel w miarę postępu tego podręcznika. Następnym tematem będą "przełączniki i potencjometry" (metody obiektów) a stamtąd przeniesiemy się do "fabryk" (klas). Jesteś wciąż z nami? 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>

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