Jak wypada kodować w Rubym xD?

Dyskusje
1

Jestem programistą Javy, a od kilku dni param się DataMapperem i JRuby. Nareszcie wszystko działa, umiem już chyba większość rzeczy osbługiwać, więc mogę zacząć klepać aplikację.
Chciałem się dlatego zapytać, jak wypada programoać w Rubym. Jeśli będę miał jakieś pytania dopiszę je w tym temacie.

Narazie zastanawia mnie, jak się porządkuje kod w Rubym.
W Javie mam pakiety, każdy pakiet to folder, każda klasa to plik, więc kod się sam porządkuje.
W Rubym są moduły, są pliki i teraz tak - Jeśli piszę aplikację desktopową (nie żadne biblioteki, tylko aplikację), naturalnie mam klasy odpowiadające za dane - połączenie z bazą danych i za okienka.
Więc w głównym pliku programu wczytuję plik z okienkami “gui” i plik “datastore”.

I teraz tak, czy jeśli dzielę program na pliki to dodatkowo powinienem używać też modułów.
Czyli mam plik “gui” i w nim od razu Window1, Window2, czy może mam plik, a w nim moduł GUI i w nim GUI::Window1, GUI::Window2.

Dodatkowo, czy plik “gui” powinien sam wczytywać wszystkie podpliki odpowiadające za gui, czy sam powinienem sobie w miarę potrzeb wczytywać “gui/dialogs”, “gui/core”, “gui/controls”?

Moje dylematy mogą się wydać głupie, ale chcę programować w Rubym w stylu Rubiego xD

2

Jeden plik, jedna klasa. Używanie modłułów nie jest obowiązkowe, ale według mnie fajnie jak są, jest czyściej.

Może poszukaj czegoś o budowaniu gemów w Rubym. Pamiętam, ze w którejś książce to było ładnie wytłumaczone (rozmieszczenie pliów itp) przy okazji budowania gemów.

3

polecam przeglądnąć jakieś open sourcowe aplikacje napisane w rubym.
Lektura do poduszki:
http://www.caliban.org/ruby/rubyguide.shtml#style - nie ma tam co prawda o organizacji plików, ale jest troszkę innych konwencji :wink:

4

Bodajże to właśnie java spopularyzowała taki styl z nazewnictwem pakietów i klas. I jest to bardzo przejrzysty sposób, bardzo często stosowany także w przypadku rubiego. Zatem dobrze jest, gdy katalog przekłada się na moduł, a plik na klasę (lub moduł jeśli ma służyć jako mixin). Łatwo jest wtedy połapać się w strukturze projektu.

5

Moja przygoda z Rubym się jeszcze na dobre nie rozpoczęła, jeszcze wszystkiego nie “czuję”, aczkolwiek jestem na dobrej drodze.
Czy ktoś mogłby mi jednak wytłumaczyć, jakie były motywacje do stworzenia tak “dziwnego” systemu widoczności metod?

  1. W Javie dziedziczyłem po klasie i nie obchodziła mnie implementacja. W Rubym podklasa ma dostęp do prywatnych metod nadklasy, dlaczego?
  2. Dlaczego obiekt klasy A nie może wywoływać prywatnych metod okiektu klasy A, tylko stosuje się protected?

Co do pierwszego to ja to widzę tak, że w Rubym skupiamy się na typach (jakie obiekt ma metody), a nie na klasach, więc nie musimy dziedziczyć. Więc w rezultacie dziedziczymy tylko po swoich własnych klasach. Mam rację?
Jak jest z punktem 2?

6

[quote=Crane]1. W Javie dziedziczyłem po klasie i nie obchodziła mnie implementacja. W Rubym podklasa ma dostęp do prywatnych metod nadklasy, dlaczego?
2. Dlaczego obiekt klasy A nie może wywoływać prywatnych metod okiektu klasy A, tylko stosuje się protected?[/quote]
http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Declaring_Visibility

sekcja Protected cię interesuje

pozdrawiam

7

Jedna ważna rzecz, która być może Ci nieco rozjaśni to to, że w Ruby nie ma klas! Klasa też jest obiektem, tylko dziedziczącym z Class, Powstaje więc nam drzewko obiektów - wszystkie pochodzą z Class.

Polecam Ci serię filmików Dave Thomasa: Ruby Object Model and Metaprogramming: http://www.pragprog.com/screencasts/v-dtrubyom/the-ruby-object-model-and-metaprogramming
Jeszcze dziś chyba jest możliwość zakupienia ich za prawie pół ceny: http://www.pragprog.com/news/40-off-thanksgiving-pragsale-now-through-1125

Model obiektowy w Ruby daje więcej swobody programiście, to jest fakt.

8

Za późno, do 11:59 AM GMT, czyli do trzynastej naszego czasu.
Ale nie musisz kupować filmików, dobre materiały pisane o modelu obiektowym w Ruby bardzo łatwo znaleźć na sieci :slight_smile:

9

Nie przesadzajmy. Klasy oczywiście, że są, inaczej jak tworzyłbyś nowe obiekty? To, że klasa jest obiektem nie przeszkadza jej w… byciu klasą.

Object.is_a?(Class) => true Object.is_a?(Object) => true Class.is_a?(Class) => true Class.is_a?(Object) => true

10

Oj, Radarek, wyciągnąłeś metodę (is_a?), która jest fajna w kodzie, ale dydaktycznie tylko mąci :wink:

Object.class => Class Class.class => Class Class.superclass => Module Class.superclass.superclass => Object

11

Rzuć proszę jakimiś linkami :slight_smile:

12

Why’s Poignant Guide to Ruby.
Ostatni post Yehudy o modelu obiektowym i metaprogramowaniu w Ruby “it’s all about the self”.
Książka z Kilofem.

13

W JavaScript nie ma klas, podobnie w innych językach bazujących na prototypach. W takim wypadku tworzysz nowy obiekt przez klonowanie już istniejącego. Ustawia to też macierzysty obiekt jako prototyp nowego, dzięki czemu w nowym masz dostęp do pól (i np. metod) obiektu macierzystego.

Po tym jak popracowałem parę miesięcy w języku prototypowym znacznie roszerzył się mój sposób pojmowania języków. Ciekawe jest obserwować ludzi zamkniętych w świecie klas :slight_smile:

14

W następnym miesiącu: Bragi odkrywa lispa i obserwuje ludzi zamkniętych w świecie prototypów :wink:

15

W JavaScript nie ma klas, podobnie w innych językach bazujących na prototypach. W takim wypadku tworzysz nowy obiekt przez klonowanie już istniejącego. Ustawia to też macierzysty obiekt jako prototyp nowego, dzięki czemu w nowym masz dostęp do pól (i np. metod) obiektu macierzystego.

Po tym jak popracowałem parę miesięcy w języku prototypowym znacznie roszerzył się mój sposób pojmowania języków. Ciekawe jest obserwować ludzi zamkniętych w świecie klas :)[/quote]
Oczywiście, masz rację. Jednakże w rubym obiekty tworzone są przez klasy (tudzież jako literały) i pisanie, że ruby takowych nie posiada jest błędem. Gdyby ich nie było to po co byłaby konstrukcja:

class Foo end
? (a takowej właśnie w javascript nie ma, chociaż słówko class jest zarezerwowane)

Zatem nie mąćcie panowie nowicjuszowi takimi stwierdzeniami.