Skocz do zawartości

Witaj!

Zaloguj lub Zarejestruj się aby uzyskać pełny dostęp do forum.

Zdjęcie
- - - - -

[Kurs] Objective C/Cocoa - 03. Obiekty. Składnia. Typy zmiennych.


  • Zaloguj się, aby dodać odpowiedź
111 odpowiedzi w tym temacie

#1 genshi.wa

genshi.wa
  • 67 postów

Napisano 05 grudnia 2008 - 00:32

Witam wszystkich po długim czasie jaki minął od ostatniej części.
Problemy techniczne - internet też rzecz i czasami siada :), ale nie ma co się rozpisywać w innym temacie.
Bierzemy się już za programowanie.

Obiektowość. Klasy -z czym to się je


Aby dobrze pojąć takie coś jak obiekt (object) i klasa (class) potrzebne nam jest na początek tylko i wyłącznie poprawne rozumowanie obiektów otaczających nas dookoła. A dokładnie chodzi o proste powiązania rzeczy/istoty żywej oraz to co mogą robić czy jak się zachowywać.
Weźmy np. człowieka. Ów człowiek jest klasą (class), Ogólna postać człowieka opisuje nam każdego człowieka jak np. "Józek", który jest obiektem tej klasy (człowieka).
Człowieka potrafi chodzić, mówić, jeść etc. - są to funkcje które mu przypisujemy. Funkcje te w klasach są nazywane metodami. Człowiek nasz posiada także różne cechy takie jak: kolor, imię i nazwisko, wiek etc.
Idąc dalej tym tropem mamy:
  • Klasa: człowiek
  • Cechy: nazwisko, wiek
  • Funkcje/Metody: chodzenie, mówienie
Z klasy (człowiek) tej wywodzi się nasz obiekt (Józek),
Jak widać klasa (class) to opis obiektu (object).

Człowiek należy również do jakiegoś gatunku t.j. ssak naczelny. I wywodzi się właśnie z niego. Można powiedzieć, że dziedziczy pewne cechy oraz funkcje od tego gatunku, czyli jest jakby jego potomkiem. W programowaniu nazywamy to inheritance czyli dziedziczenie - praktycznie nierozłączna część programowania w Objective C.
Już od samego początku poznamy i zaprzyjaźnimy się z dziedziczeniem, ale tylko w podstawowej jego części - reszta w dalszych częściach kursu.

Każdego człowieka możemy zapytać np o wiek czy o nazwisko czy również możemy także, jeśli np jest to nasz pracownik polecić aby coś zrobił, chociaż nie zawsze musi wiedzieć jak (o tym będzie w innej części kursu). Możemy nawet zmienić ich cechy (chociaż nie zawsze :) ). Tak samo jest w programowaniu obiektowym, możemy zapytać obiekt o różne jego cechy lub je nawet zmienić, jak i polecić coś zrobić. Czynność taka nazywa się w ObjC messages, czyli inaczej hmm... wiadomość dla obiektu - ja to zawsze sobie biorę za polecenie.
Polega to na zasadzie, iż jeśli chcemy komuś wysłać wiadomość/polecenie musimy wiedzieć do kogo ją zaadresować. Ten ktoś jest nazywany odbiorcą - receiver, a nadawca - sender.
Wygląda to tak:

[odbiorca wiadomosc/polecenie]

Gdzie wiadomość/polecenie to metoda obiektu, czyli naszego odbiorcy. A odbiorca to obiekt.

Myślę, że tak krótki opis co to jest obiekt wystarczy.
Przejdziemy teraz do tworzenia obiektów w Objective C oraz ich używania.

Składnia


Od tej pory będę tylko używał określenia metoda dla określenie polecenia czy funkcji, czy wiadomość (tu message) klasy/obiektu.
Każda klasa jest deklarowana poprzez

@interface NaszKlasa: KlasaPoKtorejDziedziczymy
{
// cechy klasy
}

//metody/polecenia
@end

Cechy klasy tworzymy poprzez normalne deklaracje zmiennych, czyli np:

int wiek;
NSString *nazwisko;

Metody/polecenia obiektu (nie klasy) tworzy się poprzez:

-(typ jaki zwraca metody) metoda;
-(typ jaki zwraca metody) metoda: (typ argumentu) argument;
-(typ jaki zwraca metody) metoda: (typ argumentu) argument iDrugiAgrument:(typ drugiego argumentu) drugiArgument;

Gdzie "typ jaki zwraca metoda" może zostać pominięty. Ale ten temat zostawimy na cześć kursu o dziedziczeniu.
"metoda" jest także nazwą argumentu, jeśli takowy istnieje, bądź wskazówką dla pierwszego argumentu.
W 3 przykładzie metody nazwa "iDrugiArgument" jest opcjonalna, ale dla czytelności kodu lepiej używać nazw argumentów. Przykład:
Z nazwą argumentu:

-[czlowiek ustawNazwisko: @"nazwisko" iWiek: 25]

I bez nazwy argumentu:

-[czlowiek ustawNazwisko: @"nazwisko" : 25]

Także sam/a stwierdź, który sposób jest lepszy -czyt. bardziej czytelny.

Natomiast definicja/implmentacje naszej klasy wyglada tak:

@implementation NaszaKlasa: KlasaPoKtorejDziedziczymy
// definicje metod/implementacje
-(type jaki zwraca metoda) metoda
{
}


-(typ jaki zwraca metoda) metoda: (typ argumentu) argument
{
}

@end



Na podstawie tych wiadomości możemy już stworzyć klasę naszego Człowieka

@interface Czlowiek: NSObject
{
int wiek;
NSString *nazwisko;
}
-(void) ustawNazwisko: (NSString *) n;
-(void) ustawWiek: (int) w;
-(void) ustawNazwisko: (NSString *) n iWiek: (int) w;

-(NSString *) nazwisko;
-(int) wiek;
@end

@implementation Czlowiek
-(void) ustawNazwisko: (NSString *) n
{
nazwisko = n;
}

-(void) ustawWiek: (int) w
{
wiek = w;
}

-(void) ustawNazwisko: (NSString *) n iWiek: (int) w
{
nazwisko = n;
wiek = w;
}

-(NSString *) nazwisko
{
return nazwisko;
}

-(int) wiek
{
return wiek;
}

@end


NSObject jest obiektem bazowym. Którego będziemy używać na razie jak coś co musi być :). Kiedy przejdziemy do dziedziczenia to omówimy sobie go.
NSString jest klasą napisów z biblioteki Foundation. Będziemy jej używać do manipulacji tekstem.
Napisy z NSString tworzy się w ten sposób:

NSString *napis1 = @"Tworzy sie je jeszcze inaczej";
NSString *napis2 = @"Ale dla naszych potrzeb wystarczy";

A żeby użyć tego napisu przez np. funkcje printf, potrzebujemy wysłać metodę o napis w stylu C:

printf("%s", [napis1 cString]);


Metody ustawNazwisko, ustawWiek oraz ustawNazwisko: iWiek są tak zwanymi setterami.
Nazwa wzięła się z angielskiego i znaczy to ustaw (set). Normalnie by to wygladało tak:

-(void) setName: (NSString *) n;
...

a (int) wiek; to tak zwany getter, czyli pobierz od angielskiego get. Zauważ, że nazwa metody gettera jest taka sama jak cechy/zmiennej klasy. Możesz użyć nazwy jakiej chcesz, ale użycie tej samej nazwy jest bardziej czytelne i zrozumiałe.

Klasa człowieka, którą stworzyliśmy poprzez @interface, to tylko informacja co zawiera nasz klasa. Do tego potrzeba jeszcze dorobić implementacje.
Implementację umieszcza się zazwyczaj w plikach do kompilacji czyli w przypadku Objective C są to pliki z końcówką .m Natomiast pełną deklarację (@interface) umieszczamy w standardowym pliku nagłówkowym z C czyli .h
Aczkolwiek nie jest to wymóg i można umieszczać i deklaracje i implementację w jednym pliku .m, jak i my to zrobimy dzisiaj (tylko dla celów edukacyjnych :) ), lepszą praktyką jest umieszczanie deklaracji w osobnym pliku nagłówkowym t.j. .h, który nie jest kompilowany, a tylko dołączany poprzez dyrektywę #import

Teraz jak już mamy nasz opis (klasę) człowieka możemy stworzyć "Józka".
Wygląda to mniej więcej tak:

Czlowiek *jozek;
jozek = [Czlowiek alloc];
jozek = [jozek init];

Wszystkie obiekty podczas ich deklaracji muszą być poprzedzone gwiazdką "*", ponieważ są to wskaźniki (referencje) do tych obiektów. Więcej na ten temat w dalszych częściach kursu.
Każdy obiekt musi mieć przydzieloną pamięć - alloc oraz być zainicjowanym - init.
Pamięć przydziela się poprzez wywołanie metody alloc z klasy, która jest dziedziczona po NSObject.
Metoda alloc jest metodą klasy nie obiektu - o tym trochę później, który zwraca typ. Natomiast metoda init jest wywołana już dla naszego obiektu. Jest ona dziedziczona również poprzez NSObject.
Na razie musimy tylko wiedzieć, że za każdym razem jak tworzymy obiekt to musimy go w ten sposób utworzyć :).

Powyższy zapis tworzenia obiektu możemy skrócić do:

Czlowiek *jozek = [[Czlowiek alloc] init];

Pilega to na tym, iż możemy zagnieżdżać wysyłanie wiadomości do obiektów pamiętając, że najpierw pierwszeństwo w dostawaniu wiadomości ma obiekt bliżej środka. Czyli najpierw Czlowiek potem obiekt przez niego stworzony w naszym przypadku "jozek".

Po stworzeniu naszego obiektu musimy go zawsze zwolnić poprzez wysłanie do obiektu metody release:

[jozek release];


Na sam koniec już dzisiejszej części kursu zostało nam zrobić jeszcze program który to przetestuje:


#import
#import
#import

ZAMIAST TEGO TEKSU WSTAW KLASE CZLOWIEK

int main(int argc, char *argv[])
{
Czlowiek *jozek = [[Czlowiek alloc] init];

[jozek ustawNazwisko: @"panaNazwisko"];
[jozek ustawWiek: 25];

printf("%s ma %d lat.\n", [[jozek nazwisko] cString], [jozek wiek]);

[jozek ustawNazwisko: @"paniNazwisko" iWiek: 24];
printf("A %s ma %d lat.\n", [[jozek nazwisko] cString], [jozek wiek]);


[jozek release];

return 0;
}



Pozdrawiam.


*****************************************************************************************************
Ćwiczenie:
Stworzyć kilka klas oraz po kilka metod do nich razem z cechami.
Może to być: samochód, telewizor, mp3 itp itd;

Tylko pamiętajcie żeby dziedziczyć po NSObject.


POPRZEDNIE CZĘŚC KURSU:
01. Wprowadzenie
02. Konfiguracja i instalacja

#2 radekw

radekw
  • 266 postów
  • SkądKraków

Napisano 05 grudnia 2008 - 10:34

Bardzo się cieszę, że ktoś ruszył temat podstaw programowania w objective C. U nas cały czas posucha na tym polu. Przykłady kodu przejżyste i jasne. Natomiast w tekście jest po prostu gigantyczna ilość literówek, które mi przeszkadzają.
Druga sprawa:

Wszystkie obiekty podczas ich deklaracji muszą być poprzedzone gwiazdką "*", ponieważ są to wskaźniki (referencje) do tych obiektów

To zdanie mocno nadszarpnęło moje zaufanie do szanownego Autora i nie jestem już taki pewny czy wie o czym pisze. Mam nadzieję że to tzw. "skrót myślowy" ;) ponieważ referencje, mimo podobnego efektu, to jednak są inną metodą manipulowania danymi niż wskaźniki i np w C++ dysponują własnym operatorem (&) dla odróżnienia od wskaźnika (*)

#3 MyKreska

MyKreska
  • 12 postów

Napisano 05 grudnia 2008 - 10:44

Wielkie dzięki sannindan. Naprawdę robisz dobrą robotę.

#4 Smuggi

Smuggi
  • 63 postów

Napisano 05 grudnia 2008 - 12:01

sannindan: Niby wszystko ok, kawal dobrej roboty. Ale... Po pierwsze po jaka cholere wprowadzasz polskie nazewnictwo w "setterach": np.: "ustawWiek:". Co to w ogole jest? Po drugie. Programistom, ktorzy uzywaja MacOSX wprowadzasz troche zamieszania. Metoda "cString" klasy NSString jest deprecated, a w iPhone SDK w ogole jej nie ma. Zaleca sie takze stosowanie NSLog zamiast printf... Nie wiem jak pod innymi platformami, ale moze chociaz jest "UTF8String" - tej metody mozna smialo uzywac na OSX, (w iPhoneSDK tez jej niestety nie ma, jest za to "cStringUsingEncoding:").

#5 genshi.wa

genshi.wa
  • 67 postów

Napisano 05 grudnia 2008 - 12:53

@radekw
Pamiętaj, że ty mówisz o referencjach w C++ - a tutaj to coś nowego i innego.
Natomiast w programwoaniu obiektowym (z garbage collectors) wszystkie obiekty które są tworzone są tylko referencjami! do danego obiektu. Tzn nazwa zmiennej która reprezentuje dany obiekt jest referencją.
Jest tak w Java, jest tak w C# i jest tak w Objective C. Z tym, że w tych dwu pierwszych nie ma czegoś takiego jako operator * przed deklaracją zmiennej obiektowej,
Zauważ jeszcze, że C++ nie jest jezykiem obiektowym, a tylko posiada jako taką obiektowść jako jeden z paradygmatów programwoania.
No i co najważniejsze aby dobrze pojąć Objective C, bardzo dobrze byo by się wyzbyć przyzwyczajeńz innych jezyków, które oferują obiektowość takich jak m.in. C++. A najlepiej by było nie umieć żadnego z nich.

@Smuggi
Widzę, że już się czepiłeś mnie od samego początku i do konća nie wiem za co. Bo jeśli tylko za to, że prowadzę ten kurs, to ehh szkoda gadać.

Po pierwsze po jaka cholere wprowadzasz polskie nazewnictwo w "setterach": np.: "ustawWiek:". Co to w ogole jest?

Jak wiesz, to jest pierwsza lekcja z programowania. I nie każdy potrafi po angielsku.
Jakie jest nazewnictwo, to każdy sobie robi po swojemu! Pamiętaj, że, to że jest w angielskiej literaturze słowo set i jest napisane, ze się powinno tego używać do setterów, to nie znaczy że tak musi być w innym języku! Jesli mi się podoba uzywać ustaw zamiast set słowa ustaw to moja sprawa.
I zauważ jeszcze raz: JEST TO ROBIONE DLA CZYTELNOŚCI I UŁATWIENIA POCZĄTKUJĄCYM!

Po drugie. Programistom, ktorzy uzywaja MacOSX wprowadzasz troche zamieszania. Metoda "cString" klasy NSString jest deprecated, a w iPhone SDK w ogole jej nie ma. Zaleca sie takze stosowanie NSLog zamiast printf..

Niby masz racje, ale zobacz sobie co produkuje NSLog. W przeciwieństwie do NSlog printf nie drukuje na ekranie nam nie potrzebnych rzeczy i jest przyjanze dla C i oczywiście dla konsoli jeśli chcemy coś zrobić z konsolą więcej niż tylko Logi.
No i po drugie to nie jest tylko kurs na iPhona a też na Mac OS X, gdzie jest to system Unixwoy i korzysta sie dużo z konsoli, dlatego też printf jest bardzo przydatne.
No i jeśli chodzi o NSString, to z tego co mi wiadomo to jest ono domyślnie unicode.

Po trzecie, malo istotne z pozoru. Ale sa ogolne dyrektywy dotyczace konwencji zapisu programu w Obj-C. NIe uzywa sie np. w naglowkach metod takiej ilosci spacji . Zaciemnia to kod i wprowadza zle nawyki. Niby malo istotne ale przy pracy kilku osob nad jednym kodem, potrafi byc cholernie uciazliwe.


No i znowu. To kto jaki ma styl pisania jest zależne tylko i wyłącznie od programisty. Pamiętaj jeszcze raz to jest pierwsza część i jest ona dla początkujących również. Dlatego też dla czytleności kodu jest tak a nie inaczej. A ja zawsze preferuje taki style:

-(void)setName:(NSString *) n andAge:(int) a;

a ten twój:

-(void)setName:(NSString *)n wiek:(int)w;

jest mniej zalecane nawet przez te Twoje materiały, które mi kiedyś rzekomo polecałeś.
Ten pierwszy(mój) jest bardziej czytleny niż ten drugi (twój). I wiadomo co jest robione.

PAMIĘTAJ SĄ TO POCZĄTKI I MUSI BYĆ PROSTE I ZROZUMIAŁE.
I JEST TO MOJA METODA PROWADZENIA KURSU.
Jeśli chcesz zrób po swojemu. Ja mam cel w tym kursie, który obrałem sobie poprzez włąśnie taki a nie inny układ dydaktyczny. Prowadzać poprzez bardzo proste i spójne rzeczy, aż w końcu to tych bardziej zawansowanych.
No i na samym końcu część kursu pt.: "Poprawny i niepoprawny styl kodowania - sugestie"

Pozdrawiam.

PS.
Jak chcesz, to możesz jeszcze ponarzekać na to iż można settery i gettery tworzyć z automatu bo tak jest w Obejctive C 2.0, no i może jeszcze że nie warto zaczynać nauki od pierwszej jego wersji.

#6 Optiv

Optiv
  • 188 postów

Napisano 05 grudnia 2008 - 13:16

No z polonizacja settera to trochę przesada ale mi to bez różnicy... "Przejdziemy teraz do tworzenia obiektów w Objective C oraz ich używania." Piszesz takie zdanie, na końcu pierwszej sekcji, a tak naprawdę przechodzisz do tworzenia całej klasy, a dopiero pożniej tworzysz obiekt.

#7 BilboBaggins

BilboBaggins
  • 398 postów
  • SkądWrocław

Napisano 05 grudnia 2008 - 13:18

Nie, zebym sie czepial, ale chcialem na cos zwrocic uwage.

Jesli w ten sposob zakodujesz setter:
-(void) ustawNazwisko: (NSString *) n
{
    nazwisko = n;
}
to mozesz sie obudzic z reka w nocniku, jesli okaze sie, ze gdzies indziej w kodzie ktos zwolni obiekt przekazany jako parametr. Poza tym nie zwalniasz aktualnego obiektu przechowujacego nazwisko, co moze doprowadzic do wycieku pamieci.
Generalnie poleca sie cos takiego:
-(void) ustawNazwisko: (NSString *) n
{
    [nazwisko release];
    nazwisko = [n retain];
}
A juz w ogole idealem byloby tworzenie kopii obiektu podanego jako parametr, ze wzgledu na ewentualna zmiane wartosci, ale to juz wyzsza szkola jazdy, co oczywiscie rozumiem.

Jak rozumiem konstruktor i destrukor dopiszesz pozniej? Bo zapomniales tu o destruktorze, co tez moze doprowadzic do wycieku pamieci :(.

Ostatnia uwaga jest prosta - badz konsekwentny i jak raz w przykladowym kodzie piszesz
-(typ jaki zwraca metody) metoda;
to trzymaj sie tego do konca...

Generalnie to milo sobie przypomniec podstawy i sprawdzic ile sie jeszcze pamieta z poczatkow :). Dobrze, ze taka inicjatywa powstala. Szkoda, ze odzew nijaki.

#8 Smuggi

Smuggi
  • 63 postów

Napisano 05 grudnia 2008 - 13:22

Dlatego wlasnie usunalem to dotyczace konwencji zapisu kodu i sie nie czepiam (odpowiedziales szybciej niz ja to usunalem). Apple zaleca inna, ale to jak juz ktos siadzie do kodowania na OSX bedzie mialo znaczenia.

Co do "setterow", jest to kluczowe. KeyValue coding jest w kazdym miejscu w OSX. Dlatego ma to takie znaczenie. Dlatego nauka dobrych nawykow jest taka wazna, a nie jak sie komu podoba. Twoj kurs, wiec prowadz jak chcesz.

BTW w Objective C 2.0 gettery i settery nie tworza sie z automatu :-) Musisz zadeklarowac "property".

---- Dodano 05-12-2008 o godzinie 12:25 ----

No z polonizacja settera to trochę przesada ale mi to bez różnicy...


O i to jest wlasnie przyklad tworzenia zlych nawykow i ignorancji. Odczujesz roznice jak siadziesz i zaczniesz pisac pod OSX.

#9 micha_pl

micha_pl
  • 179 postów
  • SkądŁódź

Napisano 05 grudnia 2008 - 13:58

@BilboBaggins - odzew jest, bardzo mnie to wciągnęło, bo choć jak dotąd nie miałem nic wspólnego z programowaniem to zaczynam sie do tego przymierzać. Jak dla mnie świetna robota, jasno i czytelnie. Bardzo dobre przykłady. Czekam na następne części . Pozdrawiam

#10 BilboBaggins

BilboBaggins
  • 398 postów
  • SkądWrocław

Napisano 05 grudnia 2008 - 15:30

Co do "setterow", jest to kluczowe. KeyValue coding jest w kazdym miejscu w OSX. Dlatego ma to takie znaczenie. Dlatego nauka dobrych nawykow jest taka wazna, a nie jak sie komu podoba. Twoj kurs, wiec prowadz jak chcesz.

Absolutnie sie z kolega zgadzam.
Dobrze zaimplementowana klasa && Cocoa Bindings == Oszczednosc czasu programisty :).

Naprawde nie wiem, jak zylem kiedys bez Cocoa Bindings...

#11 malibumilk

malibumilk
  • 1 postów

Napisano 05 grudnia 2008 - 15:36

[url]http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf[/url]

#12 Optiv

Optiv
  • 188 postów

Napisano 05 grudnia 2008 - 18:36

Smuggi, mi nie przyszło do głowy aby to spolszczać, sam używam ang nazwa ale nie przeszkadza mi to w czytaniu tego kursu, choć przyznaje, że nie jest to do końca poprawne.

#13 genshi.wa

genshi.wa
  • 67 postów

Napisano 05 grudnia 2008 - 21:52

Ehh.
czy to jest takie ciężkie do zrozumienia, że jak się kogoś uczy, to nie mówi się od razu wszystkiego!
Trzeba podejść do tego ze strony laika a nie kogoś, kto już coś programował.
Zaznaczę tylko ostatni raz, że jest to pierwsza część poświęcona programowaniu i aby było to czytelne i szybsze do przyswojenia celowo użyłem polskich odpowiedników. Jest czytelniej i widać o co w tym wszystkim chodzi. To że ma jest inna konwencja nazewnictwa to już co innego. Nie jest zabronione że mam używać polskich nazw. Nie jest też nigdzie tak napisane. A mianowicie jest napisane, żeby używać nazw odpowiadające ich przeznaczeniu.
Druga sprawa, jak już napisałem wcześniej. Proponowany i zalecany styl omówię prawie na końcu kursu o Objective C, zaraz przed przejściem do Cocoa. Jest to celowe i z namysłem.
Jest prościej nauczyć się z polskiego nazewnictwa o co tutaj chodzi i potem przestawić się na angielski, niż od razu sypać anglikiem i tych co nie znają męczyć czymś jeszcze oprócz programowania.

@BilboBaggins
Może i dobrze piszesz. Ale zauważ, że ja użyłem takiej składni:

NSString * string = @"cos tam napisane";

A w tym wypadku nie zwalniasz pamięci.

@optiv
Ale powiedz mi co złego jest w zdaniu

Przejdziemy teraz do tworzenia obiektów w Objective C oraz ich używania"

Skoro proces tworzenia obiektu zaczyna się właśnie od klasy - tak właśnie zacząłem następną sekcję.
I na końcu jest pokazane jak to się robi w całości.
Zazwyczaj jest tak że w instrukcji jak zbudować np. silnik jest najpierw jak się składa różne jego części (nie silnik) a dopiero potem pokazane jak to pozbierać w całość (tłoki etc) i w ten sposób otrzymujesz silnik. Tak i w tej instrukcji budowy jest napisane: "Budowa silnika" bądź "Jak zbudować silnik".

Mam tylko takie pytanie do was. Czy kiedykolwiek braliście udział w jakimś projekcie przy pomocy Objective C, bo ja tak i wiem jak wygląda kod w większości wypadków.

A inna sprawa, żeby nie być gołosłownym. To nie ocenia się czegoś/kogoś po tym jak zaczyna tylko po tym jak skończy. I dlatego też zapewniam, ze z tego kursu wyrosną programiści.

Plan tego kursu układałem przez ponad 3 miesiące. Przegadałem z ludźmi, którzy na co dzień nie programują oraz z tymi po "drugiej stronie". Z tego wyniosłem coś co przeleje na tym kursie, jest to moja taktyka nauczania czegoś co wielu ma trudności z przyswojeniem, ze względu na trudność zagadnienia.


Części o Objective C i podstawie Foundtation będzie jeszcze 3 + "Zalecenia stylowe programowania".
Po tym będzie jakiś mały konkursik na ciekawą aplikację (oczywiście konsolową) i wtedy się okaże ile kto wyniósł z tego kursu.
Następnie będzie już okienkowo przez ponad 13 części (długich części) (w tym audio, video, gl) i znowu konkursik.
A po tym już tylko iPhone przez 8 części i także konkursik.
Po tym wszystkim będą części poświęcone programowaniu zaawansowanemu - czyli sztuczki i kruczki

Pozdrawiam.

#14 Smuggi

Smuggi
  • 63 postów

Napisano 06 grudnia 2008 - 00:25

Mam tylko takie pytanie do was. Czy kiedykolwiek braliście udział w jakimś projekcie przy pomocy Objective C, bo ja tak i wiem jak wygląda kod w większości wypadków.


:-)

Części o Objective C i podstawie Foundtation będzie jeszcze 3 + "Zalecenia stylowe programowania".
Po tym będzie jakiś mały konkursik na ciekawą aplikację (oczywiście konsolową) i wtedy się okaże ile kto wyniósł z tego kursu.
Następnie będzie już okienkowo przez ponad 13 części (długich części) (w tym audio, video, gl) i znowu konkursik.
A po tym już tylko iPhone przez 8 części i także konkursik.
Po tym wszystkim będą części poświęcone programowaniu zaawansowanemu - czyli sztuczki i kruczki


Zamysl dobry, ale pozwol sie troche poprzyczepiac czasem.:-)

Pozdrawiam i naprawde bez zlosliwosci trzymam kciuki.

#15 genshi.wa

genshi.wa
  • 67 postów

Napisano 06 grudnia 2008 - 02:24

Hehe. Poprzyczepiać zawsze się można. Do wszystkiego - ja tak zresztą też zawsze robię. Ale i odpowiedzieć na zaczepki też trzeba :)Zwłaszcza jeśli chodzi o taką dziedzine jak programowanie. Bo tutaj zawsze przydaje się taka dyskusja. I czasami też mogę popełnić jakąs gafę, ze względu, ze piszę to w tak jakby w "czasie rzeczywistym". Także każde obiekcję się przydadzą. Pozdrawiam.

#16 normanek

normanek
  • 10 postów
  • SkądTychy, Krakow

Napisano 06 grudnia 2008 - 02:28

sannindan, nie rozumie, skad sie wziely Twoje slowa do Smuggi "Widzę, że już się czepiłeś mnie od samego początku i do konća nie wiem za co. Bo jeśli tylko za to, że prowadzę ten kurs, to ehh szkoda gadać." - to jest bardzo niedydaktyczne. Na uczelni, gdy tylko ktos zwroci uwage prowadzacemu, ten dziekuje, poniewaz oznacza to, ze studenci uwazaja. Czesto tez wytkniete nam bledy doprowadzaja do poprawy jakosci. Uwazam, ze tlumaczenie Obj-C komus, kto nie zrozumie setAge, poniewaz nie zna angielskiego, jest celowaniem z procy w lodz podwodna - jak taki biedak poradzi sobie z dokumentacja? Chyba ze przytoczysz tu cale API, to zwroce honor ;] Smuggi, nie wiem, czy cos przegapilem, ale wydaje mi sie (za najnowszym wydaniem "Cocoa Programming in Mac OS X" Pana Aarona Hillegassa), ze settery bez deklaracji rowniez dzialaja (przynajmniej u mnie dzialaly, gdy programowalem uzywajac KVC, a dopiero potem autor przeszedl do deklaracji ;]), natomiast slowo @property sluzy jednoznacznemu wskazaniu, w jaki sposob maja one funkcjonowac (np. copy).

#17 genshi.wa

genshi.wa
  • 67 postów

Napisano 06 grudnia 2008 - 02:42

@normanek
Do smugiego wzieło się to, że już miał jakieś "obiekcje" w pierwszej części kursu. Przeczytaj na http://www.myapple.p...wadzenie-3.html , to zrozumiesz dlaczego tak napisałem.
Ale jak to bywa w życiu są zawsze krytycy na dobre i na złe :) I tak powinno być. A autor zawsze musi się bronić i dlatego ja tak też robię.
A co do angielskiego, to już pisałem tyle razy i chyba napisze to ostani raz. Jest to dlatego, że są jednak osoby którę nie znają jeszcze tego języka na tyle dobrze aby zrozumie niektóre rzeczy. A w pierwszej lekcji programowania, to chyba jest bardziej zrozumiałe dla początkującego jak coś jest po polsku. A potem już jak zrozumie o co tu chodzi można lecież a anglikiem.

Pozdrawiam.

#18 Tojot

Tojot
  • 1 187 postów

Napisano 06 grudnia 2008 - 05:09

inicjatywę popieram, ale czepiać się będę:

co do j. angielskiego to dołożę jeszcze argumenty czysto dydaktyczne:
- albo będziesz go używał systematycznie (kilka słów na kurs), albo przywalisz całym słownictwem na koniec (zapominając o połowie słów które powinieneś wykorzystać)

jeszcze kilka uwag dydaktycznych:
- jednym z największych grzechów dydaktyki, jest zmiana konwencji (np. językowej) w środku kursu, gdyż zawsze kilka osób przegapia taki moment i uważa te dwie konwencje za dwa całkowicie odrębne byty
- masz rację pisząc że początkującym nie mówi się wszystkiego od razu, ale mówienie nieprawdy by później ją odwołać jest już poważnym błędem. Po pierwsze jak zwykle kilka osób przegapi moment kiedy tą nieprawdę odwołujesz, a po drugie ci którzy nie przegapią, będą się musieli oduczyć czegoś czego się niedawno nauczyli, a później nauczyć czegoś innego (3 razy więcej pracy dla nich).

Przykład:

NSObject jest obiektem bazowym. Którego będziemy używać na razie jak coś co musi być :). Kiedy przejdziemy do dziedziczenia to omówimy sobie go.

Poprawne uproszczenie: wspominasz że jest to uproszczenie i piszesz że wytłumaczysz je później.

Implementację umieszcza się zazwyczaj w plikach do kompilacji czyli w przypadku Objective C są to pliki z końcówką .m Natomiast pełną deklarację (@interface) umieszczamy w standardowym pliku nagłówkowym z C czyli .h
Aczkolwiek nie jest to wymóg i można umieszczać i deklaracje i implementację w jednym pliku .m, jak i my to zrobimy dzisiaj (tylko dla celów edukacyjnych :) ), lepszą praktyką jest umieszczanie deklaracji w osobnym pliku nagłówkowym t.j. .h, który nie jest kompilowany, a tylko dołączany poprzez dyrektywę #import

Niepoprawne uproszczenie: pliki .h nie są niekompilowane, a wręcz przeciwnie są kompilowanie i to wielokrotnie!

używa się ich z zupełnie innych powodów (w szczególności: czystości kodu, ochrony kodu, kompilacji częściowej)

zamiast tego co napisałeś mógłbyś napisać:

Deklarację (@interface) umieszcza się zazwyczaj w standardowych plikach nagłówkowych z C czyli ".h", natomiast pozostałą część implementacji, w przypadku Objective-C umieszczamy w plikach z rozszerzeniem ".m".
Dobrą praktyką jest umieszczanie deklaracji w osobnym pliku nagłówkowym t.j. .h, który jest dołączany do reszty kodu poprzez dyrektywę #import "nazwapliku.h", aczkolwiek jak i my to zrobimy dzisiaj, w bardzo prostych programach można umieszczać deklaracje i implementację w jednym pliku .m.



#19 pieczony

pieczony
  • 135 postów
  • SkądGrojec Osada

Napisano 06 grudnia 2008 - 09:54

Części o Objective C i podstawie Foundtation będzie jeszcze 3 + "Zalecenia stylowe programowania".
Po tym będzie jakiś mały konkursik na ciekawą aplikację (oczywiście konsolową) i wtedy się okaże ile kto wyniósł z tego kursu.
Następnie będzie już okienkowo przez ponad 13 części (długich części) (w tym audio, video, gl) i znowu konkursik.
A po tym już tylko iPhone przez 8 części i także konkursik.
Po tym wszystkim będą części poświęcone programowaniu zaawansowanemu - czyli sztuczki i kruczki


No to na to nie mogę się już doczekać. Dzieki wielkie za kurs!

#20 genshi.wa

genshi.wa
  • 67 postów

Napisano 06 grudnia 2008 - 10:40

@Tojot
Plik .h - one są tylko dołączane, do plików kompilowanych. Ale zawartośc potem z tego pliku jest kompilowana w pliku .c .
W tym zdaniu

... lepszą praktyką jest umieszczanie deklaracji w osobnym pliku nagłówkowym t.j. .h, który nie jest kompilowany, a tylko dołączany poprzez dyrektywę #import

człon zdania zaczynający się od który jest zdaniem podrzędnym, a dokładnie wtrąconym, który tylko tłumaczy że się go nie kompiluje i się dołącza przez dyrektywę.
Zdanie jesty logiczne i spójne. I nie musiałem tutaj wspominać o tym, że jego zawartość jest kompilowana, ponieważ z dedukcji tego zdania:

Implementację umieszcza się zazwyczaj w plikach do kompilacji czyli w przypadku Objective C są to pliki z końcówką .m Natomiast pełną deklarację (@interface) umieszczamy w standardowym pliku nagłówkowym z C czyli .h

wyciągnie się, że zawartość dołączona z pliku .h jest kompilwoana, ale tylko w pliku .c.
A takie rzeczy jak, to że co się powinno znadjować w pliku .h a co .c i jaki jest tego powód, to nie temat na pierwszą część o programowaniu.
No i druga sprawa zauważ, że takie rzeczy powinni ci co się uczą z tego kursu wiedzieć, ponieważ już w pierwszęj części wyraziłem się jasno, że podstawą aby zacząć ten kurs jest podstawowa wiedza z jezyka C. Nawet była specjalnie dłuższa przerwa pomiędzy częścią 1 a 3, aby dać czas na zapoznianie się chociaż częściowo z jezykiem C.

A pmiętasz jak pani na matematyce w szkole mówiła, że nie ma pierwsiastka z liczb ujemnych?
Kłamała czy tylko nie mówiła całej prawdy po to żeby nie mieszać uczniom w szkole?

Jak już coś to nie skłamałm w żadnym aspekcie.
Pokaż w którym.
Jeśli chodzi ci o używanie języka polskiego np. w nazewnictwie metod, to tylko można się przyczepić ew. do setterów, gdzie z przyjętego założenia pisza się set. I nie wiem czy to będzie 3x więcej pracy jeśli powie się każdemu potem, że można zamienić ustaw na set! Pewnie i tak wielu już samemu zmieniła nazewnictwo! Ze względu właśnie na, to język angielski jest bardziej pod programowanie niż polski.

No i jeszce jedno na koniec,
Czy na prawdę sądzicie, że używanie polskich nazw jest aż takim problemem dla was i dla reszty?


No i trzeba sobie jszcze jedną rzecz uświadomić. To jak będzimy nazywać, jaki styl będziemy używać i tak tylko zależy od firmy w której pracujemy. Bo to ta firma wybiera styl kodowania oraz nazewnictwa. I chcąc nie chcąc musimy się do tego przyzwyczaić. I będą mięli to gdzieś, co zaleca pewna firma (chodzi o styl kodowania nazewnictwa)


Pozdrawiam,
PS.
No ale absurdem i paranoją było by na pewno używanie notacji węgierskiej w językach stricte obiektowych.

#21 Smuggi

Smuggi
  • 63 postów

Napisano 06 grudnia 2008 - 12:13

Smuggi, nie wiem, czy cos przegapilem, ale wydaje mi sie (za najnowszym wydaniem "Cocoa Programming in Mac OS X" Pana Aarona Hillegassa), ze settery bez deklaracji rowniez dzialaja (przynajmniej u mnie dzialaly, gdy programowalem uzywajac KVC, a dopiero potem autor przeszedl do deklaracji ;]), natomiast slowo @property sluzy jednoznacznemu wskazaniu, w jaki sposob maja one funkcjonowac (np. copy).


Nie przegapiles, to dziala bo KVC uzywa metody:
- (id)valueForKey:(NSString *)key


Jednak dopiero deklaracja @property pozwala okreslic:
- jak ma dzialac przypisanie wartosci na te zmienna (assign - jest domyslnie), masz wlasnie copy czy tez retain.. Oprocz tego mozesz ustawic czy to jest zmienna tylko do odczytu, oraz czy jest ona atomic
- oraz pozwala Ci po prostu na dostep do tej zmiennej w inny sposob niz przez valueForKey (np. przez standardowe settery lub z uzyciem kontrowersyjnej ".")

#22 genshi.wa

genshi.wa
  • 67 postów

Napisano 06 grudnia 2008 - 13:26

No ta "kontrowersjyna "."", to tylko dlatego jest, że jednak Apple chce się przypodobać za bardzo reszcie programistów z innych języków. Ale to wszystko robi się po to aby było "lepiej". Chociaż dla mnie przerabianie czegoś, żeby wyglądało jak coś innego, to nie jestdobry pomysł. Pozdrawiam.

#23 BilboBaggins

BilboBaggins
  • 398 postów
  • SkądWrocław

Napisano 06 grudnia 2008 - 13:48

@BilboBaggins
Może i dobrze piszesz. Ale zauważ, że ja użyłem takiej składni:


NSString * string = @"cos tam napisane";

A w tym wypadku nie zwalniasz pamięci.

Gwoli scislosci. Przyczepilem sie do konstrukcji Twojego setter'a. To setter nie zwalnia aktualnie przypisanych obiektow, a co za tym idzie prowadzi on do wycieku pamieci. ObjC (jak pewnie doskonale wiesz) nie ma garbage collector'a, a co za tym idzie wymaga od Nas (czyt. programistow) liczenia referencji.

Twoj kod:

-(void) ustawNazwisko: (NSString *) n
{
nazwisko = n;
}

-(void) ustawWiek: (int) w
{
wiek = w;
}

-(void) ustawNazwisko: (NSString *) n iWiek: (int) w
{
nazwisko = n;
wiek = w;
}


W polaczeniu z:

[jozek ustawNazwisko: @"panaNazwisko"];
[jozek ustawWiek: 25];

printf("%s ma %d lat.\n", [[jozek nazwisko] cString], [jozek wiek]);

[jozek ustawNazwisko: @"paniNazwisko" iWiek: 24];
printf("A %s ma %d lat.\n", [[jozek nazwisko] cString], [jozek wiek]);

Zaowocuje tym, ze w momencie nadpisania nazwiska obiektem @"paniNazwisko" obiekt @"panaNazwisko" zostanie dalej w pamieci, pomimo braku referencji do niego. Taka sytuacja bedzie miala miejsce w ObjC 1.0. Jak bedzie w 2.0 tego nie wiem, bo jeszcze zwlekam z czytaniem o garbage collector'ach w ObjC 2.0. Wole w miejsce tego dokonczyc moja aplikacje w PyObjC i opanowac poruszanie sie po API :D. Jak to zrobie to sie doedukuje.

No chyba, ze ten kursik wczesniej zahaczy o to zagadnienie :). Dodam, ze bede sledzil Twoj kurs, poniewaz chce sprawdzic siebie i przy okazji sie czegos nowego nauczyc.

Dzieki raz jeszcze za Twoja inicjatywe :). Moje komentarze wynikaja z tego, ze sam wiem ile wysilku kosztowalo mnie opanowanie zarzadzania pamiecia w ObjC 1.0, pomimo dosc dlugiego doswiadczenia w programowaniu. Im wczesniej sie to omowi, tym lepiej :).

PS. W KVC da sie programowac uzywajac wlasnosci klas i accessor'ow. Ja tak koduje caly czas, choc nie ukrywam, ze trzymanie danych w NSMutableDictionary i zarzadzanie nimi przez valueForKey: i setObject:forKey: jest wygodniejsze. Robie tak jak robie, bo tak mi latwiej okielznac wlasny kod :).

#24 genshi.wa

genshi.wa
  • 67 postów

Napisano 06 grudnia 2008 - 14:44

Heh. Pamiec dla tych napisów jest zawsze zwalniana z końcem programu. Jak wiesz to ten zapis, to dokładnie korzystanie z NSConstantString (może i powinienem tego zapisu użyć, ale tak było prościej), jest to statyczny obiekt:

NSString *str01=@"Napis"; <=> NSConstantString *str01=@"Napis";

Dlatego też dla potrzeb tej częsci nie było potrzeby używać żadnych AutoRelasePool ani żadnych takich podobnych w setterach. Skoro i tak używałem tylko składni const. No i nie od razu na pierwszą część o zarządzaniu pamieci - to by od razu nie jednego zraziło :) Tak jest z każdą zmienną deklarowaną jako static. Dlatego nie ma mowy o wycieku pamięci ani takich innych sprawach Tym bardziej że wyciek pamięci jest tylko wtedy jeśli stracimi wzkaźnik/referencje do obiektu, ale tylko w przypdaku kiedy nie korzystamy z GC. Tu masz małe przypomnienie o zwalanianiu pamieci:

NSString *str01 = @"Napis01";
NSString *str02 = [NSString stringWith*:];      // w miejsce * wstaw cokiolwiek kończące metode np. stringWithString, stringWithCString itp
NSString *str03 = [[NSString alloc] init];

I tak: W pierwszym przypadku str01 nie trzeba zwalniać. W drugim str02 pamieć jest zwalniana poprzez NSAutoReleasePool. Trzeci przypadek, czyli str03 sam zwalniasz poprzez [str03 release]; No i dochodzi jeszcze GC, ale o tym przy okazji Objective C 2.0 Pozdrawiam. PS. Wiem wiem. cString jest deprecated, ale zawsze to przykład i jeszcze tego używają :)

#25 Tojot

Tojot
  • 1 187 postów

Napisano 06 grudnia 2008 - 17:00

nie wchodząc we wszystkie szczegóły, to właściwy kompilator nie dostaje ani pliku .c ani pliku .h ... ani żadnego innego pliku ... a tylko strumień od preprocesora. więc jeśli chcemy mówić o tym które pliki są kompilowane ... to żadne pliki nie są kompilowane a jeśli chcemy mówić o tym z których plików kod jest kompilowany, to z .m kompilujemy go raz, a z .h wiele razy Co do pierwiastka w szkole to sytuacja jest nieco bardziej skomplikowana ... a pierwiastek arytmetyczny z liczb ujemnych naprawdę nie istnieje, a twierdzenie że sqrt(-1)=i jest bardzo poważnym uproszczeniem.




Użytkownicy przeglądający ten temat: 1

0 użytkowników, 1 gości, 0 anonimowych