Tak jak w temacie. Dla mnie ten temat jest nie do przeskoczenia! Siedzę nad tym działem po nocach, słuchając kursu setki razy i nic! No nie mogę tego w żaden sposób ugryźć. Nie rozumiem na co są te wszystkie klasy abstrakcyjne, dlaczego mam rozszerzać klasę "Dom" klasą abstrakcyjną "Pilot", potem tworzyć jeszcze interfejsy przycisków, żeby na końcu wszystkie te informacje i tak przeciążyć znowu do "Domu". Czy nie można tego zrobić od początku w głównej klasie, bez zabawy w interfejsy i inne? Dla mnie to czarna magia! A nie chcę przechodzić w dalsze tematy kursu bez zrozumienia tego, bo obawiam się że to będzie używane cały czas. A jak jest z wami? Co dla was podczas początków uczenia się okazało się tym najtrudniejszym?
0
3
cały czas się korzysta
nie ma niczego w programowaniu obiektowym czego nie można by było zrobić w strukturalnym
tak samo jak możesz trzymać wszystkie pliki na dysku twardym w jednym folderze - chodzi tylko o porządek
wydzielanie abstrakcji czyli części wspólnych służy upraszczaniu rozwiązania do wspólnych cech żeby potem te cechy połączyć do opisu w jednym miejscu. Potem nie musisz w każdej klasie podobnych do siebie obiektów implementować od nowa części wspólnych - to naprawdę proste, rób po swojemu, potem jak już się rozkręcisz przejrzyj dostępne wzorce projektowe, które to też nie są niczym szczególnym a tylko prostym ułożeniem hierarchii klas na którym można się wzorować. Z pewnością się okaże że do kilku "wzorców projektowych" doszedłeś sam podczas zabawy z programowaniem obiektowym bez ich znajomości
0
a da się w javie pisać nie obiektowo ?
0
Trochę taki gwóźdź do trumny. No nic, kubeł zimnej wody i do przodu. Trzeba sobie udowodnić, że Ja też potrafię!:D
0
niezdecydowany napisał(a):
a da się w javie pisać nie obiektowo ?
na pewno da się pisać pseudoobiektowo
2
Ale... ja trochę nie jestem sobie w stanie wyobrazić z czym Ty możesz mieć problemy w tej obiektowości. Wydaje mi się że sam stwarzasz sobie taki problem które tak naprawdę nie ma.
3
Nie rozumiem na co są te wszystkie klasy abstrakcyjne, dlaczego mam rozszerzać klasę "Dom" klasą abstrakcyjną "Pilot", potem tworzyć jeszcze interfejsy przycisków, żeby na końcu wszystkie te informacje i tak przeciążyć znowu do "Domu". Czy nie można tego zrobić od początku w głównej klasie, bez zabawy w interfejsy i inne?
Zmień książkę. Jeśli zaczynasz naukę obiektówki od klas abstrakcyjnych i czytasz jakieś głupoty (rozszerzanie klasy Dom klasą Pilot? WTF?), to nic dziwnego, że ci się miesza w głowie. Widocznie materiał, z którego się uczysz jest tragicznie podany.
2
Hm, jeżeli tego nie rozumiesz, to wydaje mi się że autor materiałów coś zyebał, bo to powinno być proste - bo po się pisze obiektowo.
Może jeżeli nie wiesz po co, jest klasa abstrakcyjna, to zacznij od podstaw raz jeszcze:
https://docs.oracle.com/javase/tutorial/java/concepts/
1
Z tego co pamiętam to w kursie Xiona było to dobrze wytłumaczone (co prawda C++, ale tu chodzi o pojęcia, więc może to ci pomoże)
http://xion.org.pl/files/texts/mgt/html/1_7.html
Jak nie to, to poszukaj sobie lepszego kursu/książki.
0
Dziękuję każdemu za zainteresowanie tematem i chęć pomocy.
ja trochę nie jestem sobie w stanie wyobrazić z czym Ty możesz mieć problemy w tej obiektowości.
Być może tak jak mówicie, problem leży w samym instruktażu. Sam autor mówi, że sprawa może wydawać się skomplikowana gdyż wszystkie podane przez niego przykłady nie mają żadnego sensu a wszystkie podane wartości są fikcyjne i nie mają żadnego znaczenia.
Z tego co pamiętam to w kursie Xiona było to dobrze wytłumaczone (co prawda C++, ale tu chodzi o pojęcia, więc może to ci pomoże)
Zabieram się za czytanie. Materiał wydaje się być faktycznie sensownym. Dzięki wielkie!
0
nie da się zrobić czegoś NIEOBIEKTOWO
Nie masz pojęcia na czym programowanie obiektowe polega. O.o
Zabieram się za czytanie.
Daruj sobie czytanie tutoriala sprzed 10 lat na dodatek nie do tego języka co potrzebujesz (serio, w C++ to inaczej wygląda) :|
0
nz napisał(a):
nie da się zrobić czegoś NIEOBIEKTOWO
Nie masz pojęcia na czym programowanie obiektowe polega. O.o
Zabieram się za czytanie.
Daruj sobie czytanie tutoriala sprzed 10 lat na dodatek nie do tego języka co potrzebujesz (serio, w C++ to inaczej wygląda) :|
huehue, witam gimbo-specjaliste,
paradygmat programowania, w którym programy definiuje się za pomocą obiektów
Zdefiniuj mi w Javie funkcje która nie jest elementem klasy/obiektu - zdefiniuj COKOLWIEK co nie jest własnością klasy albo obiekty.
0
paradygmat programowania, w którym programy definiuje się za pomocą obiektów
Jak mi wskażesz gdzie tu widzisz jakiś obiekt zdefiniowany w celu stworzenia tego programu to spoko: http://ideone.com/DKPeKz Ale jak widać niezbyt nawet definicje przytoczoną przez samego siebie zrozumiałeś.
0
nz napisał(a):
paradygmat programowania, w którym programy definiuje się za pomocą obiektów
Jak mi wskażesz gdzie tu widzisz jakiś obiekt zdefiniowany w celu stworzenia tego programu to spoko: http://ideone.com/DKPeKz Ale jak widać niezbyt nawet definicje przytoczoną przez samego siebie zrozumiałeś.
uahuhauha, za stary jestem na dyskusje z gimnazjalistami :D nie mam na to siły.
P.S nie musisz dodawać import java.lang.*; - ten package jest importowany z defaulta
btw.
jak widać niezbyt nawet definicje przytoczoną przez samego siebie zrozumiałeś
COKOLWIEK co nie jest własnością klasy albo obiektu.
0
Daruj sobie czytanie tutoriala sprzed 10 lat na dodatek nie do tego języka co potrzebujesz (serio, w C++ to inaczej wygląda) :|
Ja chcę po prostu poznać pojęcia. Chcę wiedzieć czym jest interfejs, czym jest klasa abstrakcyjna. A w tym wypadku nie ma znaczenia czy używamy Javy czy C++, tak?
0
. Chcę wiedzieć czym jest interfejs, czym jest klasa abstrakcyjna. A w tym wypadku nie ma znaczenia czy używamy Javy czy C++, tak?
W C++ nie ma interfejsów :| Za to jest na przykład wielodziedziczenie, które Ci nie jest do niczego potrzebne. Metody wirtualne trzeba jawnie oznaczać, a w javie sa by-default, etc. Lepiej jakbyś po prostu wziął jakieś materiały do javy.
@msm, @furious programming, @Koziołek Mógłby ktoś kolegą @niezdecydowany bo chyba znowu dziś proszków nie wziął.
0
Lol. Obiektówka to nie kwestia nazewnictwa. A jeśli język nie wspiera obiektów, bo jest to np. ANSI C to znaczy, że nie da się pisać w C obiektowo?
I odwrotnie. Jak ktoś weźmie Javę, i potraktuję klasy jak zwykłe przestrzenie nazw i każdą metodę i zmienną zrobi statyczną i publiczną, i będzie w ten sposób programować, to raczej OOP to nie będzie.
Tak samo i inne paradygmaty. Np. paradygmat funkcyjny. Nie wystarczy, żeby ktoś porobił funkcje, żeby to było programowanie funkcyjne.
0
niezdecydowany napisał(a):
Zdefiniuj mi w Javie funkcje która nie jest elementem klasy/obiektu - zdefiniuj COKOLWIEK co nie jest własnością klasy albo obiekty.
Utożsamiasz klasę z obiektem?
public class Obiekty {
public static int f() {
return 5;
}
public static void main(String[] args) {
System.out.println(f());
}
}
Klasa jedna, a ile obiektów podczas wykonania tego programiku?
1
Spokojnie, zębatka w głowie za jakiś czas zaskoczy ;)
0
Spokojnie, zębatka w głowie za jakiś czas zaskoczy ;)
Myslisz, że powinienem spędzić jakiś tydzień, dwa zatrzymując się na tym i próbując zrozumieć temat? Czy lepiej iść na przód i przy okazji poznawania nowych rzeczy zacznę tego używać chcąc nie chcąc?
No jak trudno się nie domyślić, dopiero zaczynam przygodę z programowaniem. Siedzę w tym z 5 dni, stąd takie "głupie" pytania.
1
Obiektówkę najłatwiej się poznaje pisząc jakieś gierki.
Robisz arkanoida, i paletka to jeden obiekt, piłka to drugi obiekt, i każdy klocek na górze to osobny obiekt.
Robisz pacmana, to obiektem jest pacman, każdy duszek jest obiektem, obiektem może być każda kropka itp.
Wtedy to zaczyna mieć sens.
Np. dziedziczenie - klasa bazowa Człowiek, i klasy potomne Żołnierz albo Bandyta, które z niej dziedziczą (i implementują inne zachowania: tzw. polimorfizm)
agregacja - np. główna postać może posiadać inne obiekty, np. pistolet albo kuszę.
itp. itd.
Chyba tak najłatwiej. Bo jak będziesz robić nudne programy w stylu kalkulatora czy inne, to możesz nawet tych obiektów nie zauważyć (mało wątków się pojawia tutaj na forum, że ktoś robi aplikację i nie wie jak podzielić program na obiekty? To wcale nie jest takie łatwe, jeśli się nie miało z tym do czynienia wcześniej. Na prostych gierkach jednak bardziej widocznie widać co ma być obiektem)
0
m4rku1s spokojnie, większość ludzi miała z tym problemy i większość tej większości dziś tego nie pamięta albo udaje że żadnych problemów nie miała ;) Osobiście uważam że jednoczesna nauka o obiektowości, abstrakcji i interfejsach jest zła. Na początek radził bym pominąć takie zagadnienia jak interfejsy i wrócić do nich jak już w pełni będziesz rozumiał podstawy (tu ktoś może polemizować że interfejsy to przecież też podstawy OOP). Żeby zrozumieć w ogóle sens programowania obiektowego klepnij jakiś prosty programik w konsoli, np. wypożyczalnia pojazdów gdzie będziesz miał różne typy pojazdów dziedziczące po klasie bazowej Vehicle.
Pamiętaj również jedną ważną rzecz- uczysz się podstaw na prostych przykładach które jedynie mają zaprezentować pewne mechanizmy i zagadnienia, naturalnie więc większość nie ma sensu bo "w prostszy sposób było by lepiej". To tylko pozory jako że widzisz tylko mechanizm ale nie przydatne jego zastosowanie.
0
No to i jeszcze ja dorzucę swój kamyczek ;)
Tak chyba każdy ma na początku problem ze zrozumieniem po co, na co. O ile w małych projektach typu kalkulator różnica w napisaniu tego bez użycia obiektowości, a z jej użyciem jest mała. To o tyle w dużych projektach gdzie masz 100 czy 500 okienek które są bardzo podobne do siebie jest znacząca. Chodzi o to, że używając np. dziedziczenia możesz wyodrębnić powtarzające się funkcje w oknach jako klasę abstrakcyjną i potem dołożenie nowego okna to szybsza robota, bo podstawowe funkcje już masz zaimplementowane. Jeśli byś nie użył tego dziedziczenia to w każdym oknie musiałbyś pisać (np. metodą Ctrl+C Ctrl+V) te same funkcje, co by było uciążliwe.
Teraz weź przykład. Masz program gdzie jest 200 okien. Chcesz w każdym z nich dodać możliwość jego zamknięcia za pomocą klawisza Esc. Gdybyś program napisał metodą Ctrl+C Ctrl+V, to w każdym z tych okien musiałbyś znowu napisać obsługę zamknięcia za pomocą Esc. Strasznie dużo czasu. Jakbyś miał klasę abstrakcyjną po której dziedziczą wszystkie okna w systemie, to byś napisał obsługę zamknięcia okna tylko w klasie abstrakcyjnej. Chyba widać korzyść?
0
Co prawda to nie Java, ale jeśli chodzi o programowanie obiektowe, to całkiem dobrze tłumaczy.
0
mi 'przeskoczylo' dopiero w pierwszej pracy, wczesniej uwazalam ze np. interfejsy to przerost formy nad trescia. wynikalo to glownie z tego ze rzeczy ktore tworzylam byly zawarte w kilku-kilkunastu procedurach :)
mysle ze dobrym pomyslem jest przejrzenie jakiegos mniejszego przykladowego projektu, bo wiele przykladow na obiektowosc w ksiazkach/kursach jest beznadziejna i wcale nie pomaga (np. na zwierzatkach :)
1
To poczytaj sobie Head First Design Patterns - zrozumiesz po co stosuje się paradygmaty - i od razu wzorce. Jeśli to za ciężki jeszcze dla Ciebie będzie materiał, to spróbować możesz jeszcze
Head First Object-Oriented Analysis and Design.
0
Ja nie korzystam praktycznie z programowania obiektowego i radze sobie bardzo dobrze. Wypadało je poznać, bo na studiach pełno jest zadań dotyczących programowania obiektowego (no i pewnie w pracy też trzeba będzie się z tym męczyć), ale w domu do niczego to się nie przydaje, tak samo jak zarządzanie pamięcią, garbage collector, wzorce programowe itp.
0
Ja nie wiem czy połowa osób tutaj troluje, czy mówi serio...
0
Jeżeli ktokolwiek trafi na ten temat i będzie szukał pomocy w programowaniu obiektowym: http://galaxy.eti.pg.gda.pl/katedry/ksg/pracownicy/Marcin.Kulawiak/PO/po_lab_java1.pdf Zdecydowanie polecam. Po przeczytaniu tego artykułu wszystko już stało się zrozumiałe, a przynajmniej takie się byc wydaje.
0
Jak często korzystacie z programowania obiektowego?
NEVER.