(Newbie) Jak bardzo obiektowo programować w Javie?

0

Witam serdecznie wszystkich.
Od niedawna uczę się Javy i jest to pierwszy obiektowy język z którym mam do czynienia. Starając się od początku wpajać sobie dobre nawyki, chciałbym się zapytać Was, bardziej doświadczonych, o radę. Mianowicie, jak bardzo obiektowo programować? Jak bardzo rozbijać wszystko na poszczególne klasy?

Żeby wyjaśnić nieco co mam na myśli posłużę się przykładem. Uczę się z czego mogę i różne kursy/książki różnie "projektują" swój kod. Np. "Head First: Java". Dosyć popularna książka, więc myślę, że wielu z Was będzie kojarzyć przykłady aplikacji tam pisane. Mamy np. statki, gdzie cały kod rozbity jest na 3 klasy (jak dobrze pamiętam to mamy główną klasę gry, klasę statków i taką klasę "obsługi" gry typu losowe przydzielanie miejsca. Każda z tych klas ma po kilka metod.). Albo aplikacja do grania muzyczki MIDI wedle zaznaczonych checkboxów, mamy też klasę głównego programu, mamy klasę gui i klasę tworzącą zdarzenia MIDI wedle zaznaczonych checkboxów i tak samo jak w statkach każda klasa ma po kilka metod zajmujących się poszczególnymi zadaniami.

A dla kontr-przykładu podam kod z javastart.pl. Weźmy np prosty programik do interpretowania HTMLa (http://javastart.pl/static/grafika_awt_swing/pola-tekstowe/). Analizując ten kod mam wrażenie, że kod jest bardzo (może nawet tak na siłę) rozbijany na poszczególne klasy, gdzie sporo funkcjonalności można by było rozbić na metodach - bez tworzenia osobnych klas. Inna sprawa, że nienaturalne wydaje się dla mnie upychanie sporej ilości zadań, funkcjonalności wewnątrz samych konstruktorów klasy (wg. mnie metody byłyby po prostu... czytelniejsze).

Ale tak jak na początku wspomniałem, obiektowości tak naprawdę dopiero się uczę i dlatego zwracam się o pomoc do ludzi doświadczonych - jak starać się uczyć, w jaki sposób wyrabiać swój styl klepania kodu - starać się jak najczęściej rozbijać kod na osobne klasy czy raczej tworzyć kod gdzie klasa reprezentuje cały główny dział funkcjonalności danego programu, np klasa na GUI, klasa na obsługiwanie MIDI itd. a zadania wewnątrz tych klas rozbijać na metody. Co będzie "zdrowym nawykiem", jak wy na to patrzycie? :)

(Mam nadzieję, że w miarę zrozumiale opisałem swoją zagwostkę.)

0

Takie hasła na początek: SRP, DRY, KISS, YAGNI, Prawo demeter, enkapsulacja, MVC, MVP, god object. Spotykałem się z różnymi liczbami, które definiują ile mniej więcej linii powinna mieć klasa czy metoda i liczby, które pamiętam to 300 linii dla klasy i 30 dla metody, ale to tylko suche liczby ;) Co do przykładu, który podałeś realizuje on zasadę SRP - pewnie, można by było wepchnąć to do jednej klasy, ale byłaby ona zbyt ogólna. Jeśli to byłby cały program to nie byłoby to aż tak rażące, ale normalnie programy są większe i są pisane przez różne osoby, więc dobra nazwa klasy opisująca jej funkcjonalność jest przydatna - np. w tamtym przykładzie wystarczy spojrzeć na nazwy klas żeby wiedzieć, która za co jest odpowiedzialna - LoginPanel, UserValidator etc.

Tak więc co do pytania - to zapoznaj się z pojęciami z początku mojego posta i tak naprawdę czytaj kod innych - np. czy to open source czy przykłady z książek lub kursów i mniej więcej staraj się wbić w konwencje, które są tam stosowane.

2

object oriented programming to bullshit - Wojciech Seliga
:)

1 użytkowników online, w tym zalogowanych: 0, gości: 1