Objektno-Orientisani Dizajn

Objektno-Orientisani Dizajn
Glava 6 Objektno-Orientisani Dizajn

Objektno-Orijentisani Dizajn
Sada mozemo prosiriti nasu diskusiju dizajna na klase i objekte Glava 6 razmatra: Aktivnosti kod razvoja softvera Odredjuje klase i objekte potrebne za neki program Odnose koji mogu postojati izmedju klasa Modifikator static Pisanje interfejsa Dizajniranje enumerativnih tipova Dizajniranje metoda i preopterecenje (overloading) metoda Dizajn GUI i upravljanje layout-om © 2004 Pearson Addison-Wesley. All rights reserved

Pregled Aktivnosti kod razvoja softvera Prepoznavanje klasa i objekata
Staticke varijable i metode Odnosi izmedju klasa Interfejs Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn GUI i Layout © 2004 Pearson Addison-Wesley. All rights reserved

Razvoj programa Kreiranje softvera obuhvata cetiri osnovne aktivnosti:
Postavljanje zahtjeva Kreiranje dizajna Implementacija koda Testiranje implementacije Ove aktivnosti nisu strogo linearne – one se presijecaju i medjusobno reaguju © 2004 Pearson Addison-Wesley. All rights reserved

Zahtjevi Softverski zahtjevi specificiraju poslove koje program mora uraditi sta uraditi, ne kako to uraditi Cesto se uvodi neki osnovni skup zahtjeva, ali oni moraju biti kriticki razmotreni I prosireni Tesko je postaviti detaljne, nedvosmislene I kompletne zahtjeve Delikatno pazenje na zahtjeve moze smanjiti troskove i vrijeme cijelog projekta © 2004 Pearson Addison-Wesley. All rights reserved

Dizajn Dizajn softvera specificira kako ce program realizovati zahtjeve T.j., dizajn softvera odredjuje: Kako ce rjesenje biti podijeljeno u manje module Sta ce svaki modul raditi OOD odredjuje koje su klase i koji objekti poterebni, te specificira kako ce oni medjusobno reagovati Detalji dizajna odredjuju kako ce individualne metode realizovati svoje poslove © 2004 Pearson Addison-Wesley. All rights reserved

Implementacija Implementacija je proces koji prevodi dizajn u izvorni kod Novi programeri cesto misle da pisanje tog koda predstavlja srce razvoja softvera, ali stvarno to treba biti zadnji kreativni korak Gotovo sve vazne diskusije se vode tokom faze zahtijeva i faze dizajniranja Implementacija se treba koncentrisati na detalje kodiranja, ukljucujuci stil i dokumentaciju © 2004 Pearson Addison-Wesley. All rights reserved

Testiranje Testiranje proba obezbijediti da program rjesava ciljani problem ukljucujuci sva ogranicenja specificirana u zahtjevima Program treba biti detaljno testiran sa ciljem pronalazenja gresaka Debagiranje je proces odredjivanja uzroka problema i njihovo ispravljanje Mi cemo ponovo razmotriti proces testiranja kasnije u ovoj glavi © 2004 Pearson Addison-Wesley. All rights reserved

Pregled Aktivnosti pri razvoju softvera
Identifikacija klasa i objekata Staticke varijable i metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metoda Testiranje Dizajn GUI i layout-a © 2004 Pearson Addison-Wesley. All rights reserved

Prepoznavanje klasa i objekata
Osnovna aktivnost pri objektno-orijentisanom dizajniranju je utvrdjivanje klasa i objekata koji ce dati rjesenje Klase mogu biti dio biblioteke klasa, reupotrijebljene iz prethodnog projekta, ili nanovo napisane Jedan nacin da utvrdimo potencijalne klase je preko identifikacije objekata koji su diskutovani u zahtjevima Objekti su uglavnom imenice, a servisi (metode) su uglavnom glagoli © 2004 Pearson Addison-Wesley. All rights reserved

Identifikovanje klasa i objekata
Dio dokumenta sa zahtjevima: Korisnik mora biti ovlasten da specificira svaki proizvod preko njegovih primarnih karakteristika, ukljucujuci njegovo ime i broj proizvoda. Ako barkod ne odgovara proizvodu, tada mora biti generisana greska, na prozoru za poruke i unesena u error log. Zavrsni raport svih transakcija mora biti struktuiran prema specifikaciji u sekciji 7.A. Naravno, nece sve imenice odgovarati nekoj Klasi ili objektu u konacnom rjesenju. © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa i objekata
Znamo da klasa predstavlja grupu (klasifikacija) objekata sa istim ponasanjem Uopste, klasama koje predstavljaju objekte treba dati imena koja su imenice u jednini Primjeri: Novcic, Student, Poruka Klasa predstavlja koncept jednog takvog objekta Mi imamo slobodu da instanciramo onoliko objekata koliko nam je potrebno © 2004 Pearson Addison-Wesley. All rights reserved

Ponekada je tesko odluciti da li nesto treba biti predstavljeno kao klasa Na primjer, treba li adresa zaposlenog biti predstavljena preko instanciranja varijabli ili kao objekat Address Sto vise ispitujemo problem I njegove detallje sve vise ce biti jasnije ovo pitanje Kada neka klasa postane suvise kompleksna, cesto je treba razbiti na vise manjih klasa da se raspodijeli odgovornost © 2004 Pearson Addison-Wesley. All rights reserved

Zelimo definisati klase sa potrebnom kolicinom detalja Na primjer, moze biti nepotrebno kreirati posebne klase za svaki tip aparata u kuci Moze biti dovoljno definisati opstiju klasu Apliance sa odgovarajucim instancama podataka Sve to zavisi od detalja problema koji se rjesava © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa i objekata
Dio procesa identifikacije klasa jeste i dodjela odgovornosti svakoj klasi Svaka aktivnost koju program mora izvrsiti mora biti predstavljena jednom ili vise metoda u jednoj ili vise klasa Koristicemo glagole za imena metoda U ranim fazama nije potrebno definisati svaki metod svake klase - pocnite sa osnovnim odgovornostima i razvijajte metod © 2004 Pearson Addison-Wesley. All rights reserved

Pregled Aktivnosti kod razvoja softvera
Identifikacija klasa i objekata Staticke Varijable i metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn i Layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Staticki clanovi klase
Staticki metod je onaj koji moze biti pozvan preko imena klase Na primjer, metode klase Math su staticke: result = Math.sqrt(25) Varijable isto tako mogu biti staticke Odredjivanje treba li neka metoda ili varijabla biti staticka je vazna odluka prilikom dizajniranja © 2004 Pearson Addison-Wesley. All rights reserved

Staticki modifikator Staticke metode I varijable deklarisemo koristeci staticki modifikator static On pridruzuje metod ili varijablu klasi, a ne objektu te klase Staticke metode ponekad nazivamo class methods, a staticke varijable ponekad nazivamo class variables Razmotrimo pazljivo posljedice uvodjenja svake od njih © 2004 Pearson Addison-Wesley. All rights reserved

Staticke varijable Normalno, svaki objekat ima svoj vlastiti prostor podataka, ali ako je varijabla deklarisana kao staticka, tada postoji samo jedna kopija te varijable private static float cijena; Memorijski prostor za staticku varijablu se kreira prilikom prvog referrenciranja klase Svi objekti instancirani iz klase dijele njene staticke varijable Promjena staticke varijable u jednom objektu mijenja je I za sve ostale objekte © 2004 Pearson Addison-Wesley. All rights reserved

Staticke metode class Helper { public static int cube (int num)
return num * num * num; } Posto je deklarisan kao staticki, metod moze biti pozvan kao value = Helper.cube(5); © 2004 Pearson Addison-Wesley. All rights reserved

Staticki clanovi klase
Redoslijed modifikatora moze biti izmijenjen, ali po konvenciji modifikatori vidljivosti dolaze prvi Podsjetimo da je metoda main staticka – ona se poziva preko Java interpretera tako da se pri tome ne kreira neki objekat Staticke metode ne mogu referisati varijable za instanciranje, jer te varijable ne postoje dok se ne kreira neki objekat Ipak, staticka metoda moze referisati staticku varijablu ili lokalnu varijablu © 2004 Pearson Addison-Wesley. All rights reserved

Staticki clanovi klasa
Staticke metode i staticke varijable cesto rade zajedno Slijedeci primjer vodi evidenciju o broju objekata Slogan kreiranih koristenjem staticke varijable, i cine tu informaciju dostupnom koristeci staticku metodu Vidi SloganCounter.java (strana 294) Vidi Slogan.java (strana 295) © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa i objekata Staticke varijable i metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn i Layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Odnosi izmedju klasa Klase u softverskim sistemima mogu imati razne tipove odnosa medju sobom Tri najcesca odnosa su: Zavisnost: A koristi B Agregacija: A ima neko B Nasljedjivanje: A je neko B Dalje cemo diskutovati zavisnost i agregaciju Nasljedjivanje se obradjuje detaljno u 8. glavi © 2004 Pearson Addison-Wesley. All rights reserved

Zavisnost Zavisnost postoji kada se jedna klasa na neki nacin oslanja na drugu, obicno koristeci metode druge klase Mi smo vidjeli zavisnost u vise prethodnih primjera Mi ne zelimo brojne ili kompleksne zavisnosti medju klasama Takodje ne zelimo slozene klase da ne zavise od drugih Dobar dizajn trazi dobar balans © 2004 Pearson Addison-Wesley. All rights reserved

Zavisnost Neke zavisnosti se pojavljuju izmedju objekata iste klase
Neka metoda klase moze prihvatiti objekat te same klase kao parametar Na primjer, metoda concat klase String uzima kao prametar drugi objekat tipa String str3 = str1.concat(str2); Ovo se izvodi slijedeci ideju da je servis zahtijevan iz partikularnog objekta © 2004 Pearson Addison-Wesley. All rights reserved

Zavisnost Slijedeci primjer definise klasu zvanu Rational da bi predstavio racionalan broj Racionalan broj je vrijednost koja moze biti predstavljena kao kolicnik dva cijela broja Neke metode klase Rational prihvataju drugi Rational objekat kao parametar Vidi RationalTester.java (strana 297) Vidi Rational.java (strana 299) © 2004 Pearson Addison-Wesley. All rights reserved

Agregacija Neka agregacija je objekat koji je napravljen od drugih objekata Prema tome agregacija je jedan ima odnos Auto ima sasiju U softveru, agregacija sadrzi reference na druge objekte kao instance podataka Objekat sa agregacijom je djelimicno definisan i preko drugih objekata koji ga cine Ovo je specijalan vid zavisnosti – agregacija obicno pociva na objektima koji je sastavljaju © 2004 Pearson Addison-Wesley. All rights reserved

Agregacija U slijedecem primjeru, objekat Student je sastavljen, djelimicno, od objekta Address Student ima adresu (u stvari svaki student ima dvije adrese) Vidi StudentBody.java (strana 304) Vidi Student.java (strana 306) Vidi Address.java (strana 307) Agregacija se predstavlja u UML dijagramima pomocu nepopunjenog dijamanta na kraju agregacije © 2004 Pearson Addison-Wesley. All rights reserved

Agregacija u UML StudentBody Student Address - firstName : String
+ main (args : String[]) : void + toString() : String Student - firstName : String - lastName : String - homeAddress : Address - schoolAddress : Address - streetAddress : String - city : String - state : String - zipCode : long Address © 2004 Pearson Addison-Wesley. All rights reserved

Referenca this Referenca this dopusta objektu da referise na samog sebe Znaci, referenca this, upotrijebljena unutar metode, referise na objekat preko kojeg se metod izvodi Pretpostavimo da je referenca this upotrijebljena u metodu zvanom tryMe, koji se poziva na slijedeci nacin: obj1.tryMe(); obj2.tryMe(); U prvom pozivu, referenca this referise na obj1; u drugom na obj2 © 2004 Pearson Addison-Wesley. All rights reserved

Referenca this Referenca this moze se koristiti za razlikovanje instance varijable klase od odgovarajuceg parametra metode koji ima isto ime Konstruktor klase Account (iz glave 4) moze biti napisan na slijedeci nacin: public Account (Sring name, long acctNumber, double balance) { this.name = name; this.acctNumber = acctNumber; this.balance = balance; } © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa i objekata Staticke varijable i metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn I Layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi Java interfejs je skup abstraktnih metoda i konstanti
Neka abstraktna metoda je naslov metode bez tijela Abstraktna metoda moze biti deklarisana koristenjem modifikatora abstract, ali posto su sve metode u interfejsu abstraktne, to se obicno izostavlja Interfejs se koristi za uspostavljanje skupa metoda koje ce jedna klasa implementirati © 2004 Pearson Addison-Wesley. All rights reserved

interface je rezervisana rijec
Interfejsi interface je rezervisana rijec Nijedna metoda interfejsa nije Definisana (nema tijelo) public interface Doable { public void doThis(); public int doThat(); public void doThis2 (float value, char ch); public boolean doTheOther (int num); } Tacka-zarez odmah slijedi svaki naslov metode © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi Interfejs ne moze biti instaliran
Metode u interfejsu po difoltu imaju javnu vidljivost Klasa formalno implementira interfejs ako: Kaze to u naslovu klase Uvede implementaciju za svaku abstraktnu metodu interfejsa Ako neka klasa tvrdi da implementira interfejs, to znaci da mora definisati sve metode interfejsa © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi public class CanDo implements Doable {
public void doThis () // sta bilo } public void doThat () // itd. implements je Reservisana rijec Svaka metoda navedena u Doable dobiva definiciju © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi Klasa koja implementira neki interfejs moze takodje implementirati i druge metode Vidi Complexity.java (strana 310) Vidi Question.java (strana 311) Vidi MiniQuiz.java (strana 313) Dodatno (ili umjesto) abstraktnih metoda, neki interfejs moze sadrzati konstante Kada klasa implementira neki interfejs, tada ona dobiva pristup svim njegovim konstantama © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi Klasa moze implementirati vise interfejsa
Interfejsi su navedni u klauzuli implements Klasa mora implementirati sve metode u svim interfejsima navedenim u naslovu class ManyThings implements interface1, interface2 { // sve metode iz oba interfejsa } © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi Standardna biblioteka klasa Jave sadrzi vise korisnih interfejsa interfejs Comparable sadrzi jednu abstraktnu metodu zvanu compareTo, koja se koristi za poredjenje dva objekta Metodu compareTo klase String razmatrali smo u glavi 5 Klasa String implementira Comparable, dajuci nam mogucnost da stavimo stringove u leksikografski poredak © 2004 Pearson Addison-Wesley. All rights reserved

Interfejs Comparable Svaka klasa implementira Comparable za uvodjenje mehanizma poredjenja objekata tog tipa if (obj1.compareTo(obj2) < 0) System.out.println ("obj1 is less than obj2"); Vrijednost vracena iz compareTo treba biti negativna ako je obj1 manji nego obj2, 0 ako su jednaki, a pozitivna ako je obj1 veci od obj2 Kada programer dizajnira klasu koja implementira interfejs Comparable, treba slijediti ovaj zahtjev © 2004 Pearson Addison-Wesley. All rights reserved

Interfejs Comparable Na programeru je da odredi sta cini jedan objekat manjim od drugog Na primjer, moze se definisati metoda compareTo za klasu Employee da uredi zaposlene po imenu (alfabetski) ili po brojevima zaposlenih Implementacija metode moze biti jednostavna ili slozena zavisno od situacije © 2004 Pearson Addison-Wesley. All rights reserved

Interfejs Iterator Kao sto je receno u glavi 5, iterator je objekat koji daje znacenje obradi kolekcije objekata, jedan po jedan Iterator se formalno kreira implementacijom interfejsa Iterator, koji sadrzi tri metode Metoda hasNext vraca boole-ovski rezultat – true ako je ostalo komada za obradu Metoda next vraca slijedeci objekat u iteraciji Metoda remove brise objekat koji je zadnji bio vracen metodom next © 2004 Pearson Addison-Wesley. All rights reserved

Interfejs Iterator Implementacijom interfejsa Iterator, klasa formalno postavlja objekte tog tipa za iteratore Programer mora odluciti kako je najbolje implementirati metode iteratora Nakon sto se jednom postavi, verzija za-svaki petlje for moze biti koristena za obradu podataka u iteratoru © 2004 Pearson Addison-Wesley. All rights reserved

Interfejsi Programer bi mogao napisati klasu da implementira odredjene metode (kao compareTo) bez formalne implementacije interfejsa (Comparable) Ipak, formalno postavljanje odnosa izmedju klase I interfejsa dozvoljava Javi da radi sa objektom na odredjene nacine Interfejsi su kljucni aspekti objektno-orijentisanog dizajna u javi Ove ideje bice dalje razmotrene u glavi 9 © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa I objekata Staticke varijable I metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn I Layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Enumerativni tipovi U trecoj glavi uveli smo enumerativne tipove, koji definisu novi tip podataka i ispisuju sve moguce vrijednosti tog tipa enum Season {winter, spring, summer, fall} Jednom uveden, novi tip moze biti koristen za deklaraciju varijabli Season time; Jedine vrijednosti koje mogu biti dodijeljene toj varijabli su one uvedene u enum definiciji © 2004 Pearson Addison-Wesley. All rights reserved

Enumerativni tipovi Definicija enumerativnog tipa je specijalna vrsta klase Vrijednosti enumerativnog tipa su objekti tog tipa Na primjer, fall je jedan objekt tipa Season Zbog toga je slijedeca dodjela ispravna time = Season.fall; © 2004 Pearson Addison-Wesley. All rights reserved

Enumerativni tipovi Definicija enumerativnog tipa moze biti interesantnija nego prosta lista vrijednosti Posto su enumerativni tipovi slicni klasama, mozemo ukljuciti dodatne instance podataka i metode Mi takodje mozemo definisati jedan enum konstruktor Svaka vrijednost nabrojana u enumerativnom tipu poziva konstruktor Vidi Season.java (strana 318) Vidi SeasonTester.java (strana 319) © 2004 Pearson Addison-Wesley. All rights reserved

Enumerativni tipovi Svaki enumerativni tip sadrzi jedan staticki metod zvani values koji vraca listu svih mogucih vrijednosti za taj tip Lista koju vraca values je iterator, tako da for petlja moze biti koristena za njihovu jednostavnu obradu Enumerativni tip ne moze biti instanciran izvan njegove vlastite definicije Pazljivo definisan enumerativni tip daje visestruk i siguran mehanizam za upravljanje podacima © 2004 Pearson Addison-Wesley. All rights reserved

Identifikovanje klasa i objekata Staticke varijable i metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn i Layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Dizajn metode Kao sto smo diskutovali, predmet dizajna visokog nivoa je: Identifikovanje osnovnih klasa i objekata Dodjela osnovnih odgovornosti Nakon utvrdjivanja predmeta dizajna visokog nivoa, vazno je razmotriti predmet dizajna na najnizem nivou kao sto je dizajn kljucnih metoda Za neke metode potrebno je pazljivo planiranje da bi utvrdili da one doprinose efektivnom i elegantnom dizajnu © 2004 Pearson Addison-Wesley. All rights reserved

Dizajn metode Algorithm je korak-po-korak proces za rjesavanje problema Primjeri: recept, plan putovanja Svaki metod implementira algoritam koji odredjuje kako metod ostvaruje cilj Algoritam se moze predstaviti u pseudokodu, nekoj mjesavini komandi programa i obicnog jezika koji saopstavaju o koracima koje treba preduzeti © 2004 Pearson Addison-Wesley. All rights reserved

Dekompozicija metode Metoda treba biti relativno mala, tako da se moze shvatiti kao poseban entitet Potencijalno velike metode treba rastaviti u vise malih metoda ako je to potrebno za jasnost Javna servis metoda nekog objekta moze pozivati jednu ili vise privatnih metoda koje ga podrzavaju u dostizanju cilja Podrzavajuci metod moze zvati druge podrzavajuce metode ako je to potrebno © 2004 Pearson Addison-Wesley. All rights reserved

Dekompozicija metode Pogledajmo primjer koji zahtijeva dekompoziciju metode – prevodjenje engleskog u “Pig Latin” “Pig Latin” je jezik u kome je svaka rijec modofikovana premjestanjem pocetnog glasa rijeci na kraj i dodavanjem "ay" Rijeci koje pocinju samoglasnicima imaju "yay" glas dodat na kraj book ookbay table abletay item itemyay chair airchay © 2004 Pearson Addison-Wesley. All rights reserved

Dekompozicija metode Osnovni cilj (prevodjenje recenice) je takodje komplikovano da bi ga mogli ostvariti jednom metodom Dakle, mi trazimo prirodne puteve da razlozimo rjesenje u komade Prevodjenje recenice moze biti razlozeno u proces prevodjenja svake rijeci Proces prevodjenja rijeci moze biti razdvojen u prevodjenje rijeci koje: Pocinju samoglasnikom Pocinju slivenim suglasnicima (sh, cr, th, itd.) Pocinju jednim suglasnikom © 2004 Pearson Addison-Wesley. All rights reserved

Dekompozicija metode Vidi PigLatin.java (strana 320)
Vidi PigLatinTranslator.java (strana 323) U UML dijagramu klasa, vidljivost neke varijable moze biti pokazana koristenjem specijalnih znakova Public clanovi su prefiksovani znakom plus Private clanovi su prefiksovani znakom minus © 2004 Pearson Addison-Wesley. All rights reserved

Dijagram klasa za Pig Latin
+ main (args : String[]) : void + translate (sentence : String) : String - translateWord (word : String) : String - beginsWithVowel (word : String) : boolean - beginsWithBlend (word : String) : boolean PigLatinTranslator © 2004 Pearson Addison-Wesley. All rights reserved

Objekti kao parametri Druga vazna stvar povezana sa dizajnom metoda, obuhvata prenos parametara Parameteri u Java metodu se prenose po vrijednosti Kopija aktuelnog parametra (vrijednost koja se unosi) stavlja se u formalni parametar (u naslovu metode) Dakle prenosenje parametra slicno je komandi dodjele Kada je objekat prenesen nekoj metodi, aktuelni parametar i formalni parametar postaju alijasi (pseudonimi) jedan drugom © 2004 Pearson Addison-Wesley. All rights reserved

Prenosenje objekata u metode
To sto neka metoda radi sa parametrom moze imati ili nemati stalni efekat (van metode) Vidi ParameterTester.java (strana 327) Vidi ParameterModifier.java (strana 329) Vidi Num.java (strana 330) Primijetimo razliku izmedju promjene unutrasnjeg stanja nekog objekta, nasuprot promjeni na koju pokazuje objekt referenca © 2004 Pearson Addison-Wesley. All rights reserved

Preopterecenje (Overloading) metode
Preopterecenje metode je proces davanja jednom imenu metode vise definicija Ako je neka metoda preopterecena, ime metode nije dovoljno da odredi koja je metoda pozvana Signatura svake preopterecene metode mora biti jedinstvena Signatura obuhvata broj, tip i poredak parametara © 2004 Pearson Addison-Wesley. All rights reserved

Preopterecenje metode
Kompajler analizirajuci parametre odredjuje koja ce metoda biti pozvana float tryMe(int x) { return x ; } result = tryMe(25, 4.32) Poziv float tryMe(int x, float y) { return x*y; } © 2004 Pearson Addison-Wesley. All rights reserved

Preopterecenje metode
Metoda println je preopterecena: println (String s) println (int i) println (double d) i tako dalje... Slijedece linije pozivaju razne verzije println metode: System.out.println ("The total is:"); System.out.println (total); © 2004 Pearson Addison-Wesley. All rights reserved

Preopterecenje metoda
Tip return komande metode nije dio signature To jest, preopterecene metode ne mogu se razlikovati samo po tipu koji vracaju Konstruktori mogu biti preoptereceni Preoptereceni konstruktori daju vise nacina na koje mozemo inicijalizirati neki novi objekat © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa i objekata Staticke varijable i metode Odnosi izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn i Layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Testiranje Testiranje moze znaciti razne stvari
Ono svakako ukljucuje izvodjenje kompletnog programa sa raznim ulazima Ono takodje ukljucuje svaku evaluaciju izvedenu od strane kompjutera ili covjeka sa ciljem da se poboljsa kvalitet Neke evaluacije mogu se desiti i prije nego sto pocne kodiranje Sto prije nadjemo gresku, to ce jednostavnije i jeftinije biti njeno popravljanje © 2004 Pearson Addison-Wesley. All rights reserved

Testiranje Cilj testiranja je nalazenje gresaka
Kada mi nadjemo i popravimo greske, mi podizemo nasu uvjerenost da ce program raditi kao sto smo predvidjeli Mi nikada ne mozemo biti sigurni da ce sve greske biti uklonjene Kada onda zavrsiti testiranje? Konceptualni odgovor: Nikada Grub odgovor: Kada istrosimo vrijeme Bolji odgovor: Kada zelimo rizikovati da neotkrivene greske jos uvijek postoje © 2004 Pearson Addison-Wesley. All rights reserved

Pregled Pregled (Review) je sastanak na kojem vise ljudi ispituju dizajn dokumenat ili dio koda To je uobicajena i efektivna forma testiranja zasnovanog na ljudskom faktoru Prezentiranje dizajna ili koda drugima: Tjera nas da pazljivije mislimo o poslu Daje jednu spoljnu perspektivu Pregledi se nekad nazivaju inspekcije ili prezentacije ili prolaz kroz projekat © 2004 Pearson Addison-Wesley. All rights reserved

Test slucajeva Test slucajeva je skup ulaza i akcija korisnika, spojen sa ocekivanim rezultatima Cesto je test slucajeva organizovan formalno u test nizova koji se cuvaju i koriste kada treba Za srednje i velike sisteme, testiranje mora biti pazljivo vodjen proces Mnoge firme imaju poseban Quality Assurance (QA) departman (Odjel kontrole kvaliteta) koji provodi testiranje © 2004 Pearson Addison-Wesley. All rights reserved

Testiranje defekta i regresija
Testiranje defekta je izvodjenje testnih proba za otkrivanje gresaka Popravljanje jedne greske moze uvesti nove greske Nakon popravljanja skupa gresaka mi trebamo izvesti regresiono testiranje – izvodjenje prethodnog niza testova da bismo osigurali da nove greske nisu uedene Nije moguce kreirati testne primjere za sve moguce ulaze i sve akcije korisnika Dakle mi trebamo dizajnirati testove da bismo maksimizirali njihovu sposobnost da nadju greske © 2004 Pearson Addison-Wesley. All rights reserved

Black-Box testiranje U black-box (crna kutija) testiranju, testne probe su razvijene bez uzimanja u obzir unutrasnje logike programa One se baziraju na ulazu i ocekivanom izlazu Ulaz (Input) moze biti organizovan u klase ekvivalentnosti Dvije ulazne vrijednosti u istoj klasi trebaju dati slicne rezultate Dakle dobar testni okvir ce pokriti sve klase ekvivalencije i fokusirati se na granice izmedju klasa © 2004 Pearson Addison-Wesley. All rights reserved

White-Box (bijela kutija) testiranje
White-box testiranje fokusira se na unutrasnju strukturu programa Cilj je osigurati da je svaki put kroz program testiran Putevi kroz program kontrolisani su bilo kojom uslovnom komandom ili komandom petlje u programu Dobro planirano testiranje ukljucuje oba black-box i white-box testove © 2004 Pearson Addison-Wesley. All rights reserved

Identifikacija klasa i objekata Staticke varijable i metode Relacije izmedju klasa Interfejsi Jos o enumerativnim tipovima Dizajn metode Testiranje Dizajn i layout GUI © 2004 Pearson Addison-Wesley. All rights reserved

Dizajn GUI Mi moramo zapamtiti da je cilj softvera pomoci korisniku da rijesi problem U tu svrhu, GUI dizajner bi trebao: Poznavati korisnika Sprijeciti greske korisnika Optimizirati mogucnosti korisnika Biti konzistentan Diskutujmo svaku tacku sa vise detalja © 2004 Pearson Addison-Wesley. All rights reserved

Poznavati korisnika Poznavanje korisnika povlaci razumijevanje:
Pravih potreba korisnika Uobicajenih akcija korisnika Korisnikov nivo razumijevanja u domenu problema i u kompjuterskom procesiranju Mi cemo takodje primijetiti da se ove stvari mogu razlikovati kod razlicitih korisnika Zapamtimo, za korisnika, interfejs je program © 2004 Pearson Addison-Wesley. All rights reserved

Sprijeciti greske korisnika
Kada god je moguce, mi bismo trebali dizajnirati korisnicki interfejs koji minimizira moguce greske korisnika Mi trebamo izabrati najbolje GUI komponente za svaki posao Na primjer, u situaciji gdje postoji samo nekoliko valjanih opcija, koristenje menija ili radio dugmeta bice bolje nego koristenje otvorenog polja za unos Poruke o gresci (Error messages) trebale bi voditi korisnika na odgovarajuci nacin © 2004 Pearson Addison-Wesley. All rights reserved

Optimizirati mogucnosti korisnika
Nisu svi korisnici isti – neki mogu biti familijarniji sa sistemom nego drugi. Korisnike sa znanjem ponekad nazivamo power users Mi uvodimo visestruke puteve da obavimo posao kada god je to moguce “carobnjake” (“wizards“) da prosetamo korisnika kroz neki proces short cuts za power korisnike Help osobine trebale bi biti pristupacne, ali ne intruzivne © 2004 Pearson Addison-Wesley. All rights reserved

Budi konzistentan Konzistentnost je vazna – korisnik se navikava na stvari koje se javljaju i rade na odredjeni nacin pa ih treba koristiti konzistentno za indiciranje slicnih tipova informacije i procesiranja Layout ekrana treba biti konzistentan u svim dijelovima sistema Na primjer, poruka o gresci treba se pojavljivati na jednoj istoj lokaciji © 2004 Pearson Addison-Wesley. All rights reserved

Upravljanje Layout - om
Layout menadzer je objekat koji odredjuje nacin aranziranja komponenti u kontejneru Postoji vise predefinisanih menadzera layouta u standardnoj biblioteci klasa Jave: Flow Layout Border Layout Card Layout Grid Layout GridBagLayout Definisan u AWT Box Layout Overlay Layout Definisan u Swing © 2004 Pearson Addison-Wesley. All rights reserved

Menadzeri layout - a Svaki kontejner ima default menadzer layout - a
Svaki menadzer layout-a ima svoja vlastita pravila upravljanja nacinom aranziranja komponenti Neki menadzeri posvecuju paznju preferovanoj velicini ili poravnanju komponenti, a drugi ne Menadzer layout - a pokusava prilagoditi layout svaki put kada dodajemo komponente i kada kontejner mijenja velicinu © 2004 Pearson Addison-Wesley. All rights reserved

Menadzeri layout - a Mozemo koristiti setLayout metodu nekog kontejnera radi promjene layout menadzera JPanel panel = new JPanel(); panel.setLayout(new BorderLayout()); Slijedeci primjer koristi tabulirani panel, vrstu kontejnera koji dozvoljava da jedan od vise panela bude Vidi LayoutDemo.java (strana 340) Vidi IntroPanel.java (strana 341) © 2004 Pearson Addison-Wesley. All rights reserved

Flow Layout Flow layout stavlja koliko je moguce komponenti u jedan red, a tada prelazi na slijedeci red Redovi se kreiraju po potrebi da bi smjestili sve komponente Komponente se prikazuju redom kojim su stavljene u kontejner Svaki red komponenti je po difoltu centriran horizontalno u prozoru, ali takodje moze biti poravnat lijevo ili desno Takodje, horizontalni i vertikalni razmaci izmedju komponenti mogu se eksplicitno postaviti Vidi FlowPanel.java (strana 343) © 2004 Pearson Addison-Wesley. All rights reserved

Border Layout Svaka oblast prikazuje jednu komponentu (koja moze biti kontejner kao JPanel) Svaka od ostalih oblasti povecava se ako je potrebno da bi smjestila komponentu koja joj je dodata Ako ostalim oblastima nije nista dodato, one ne zauzimaju prostor i ostale oblasti se rasiruju da bi popunile praznine Centralna oblast se rasiruje da bi popunila prostor ako je to potrebno Vidi BorderPanel.java (strana 346) © 2004 Pearson Addison-Wesley. All rights reserved

Grid Layout Grid layout prikazuje komponente kontejnera u pravougaonoj mrezi redova i kolona Jedna se komponenta postavlja u svaku celiju mreze, a sve celije imaju iste dimenzije Kako se komponente dodaju u kontejner, one popunjavaju mrezu sa lijeva u desno i odozgo na doli (po difoltu) Velicina svake celije je odredjena velicinom cijelog kontejnera Vidi GridPanel.java (strana 349) © 2004 Pearson Addison-Wesley. All rights reserved

Box Layout Box layout organizuje komponente horizontalno (u jedan red) ili vertikalno (u jednu kolonu) Komponente se postavljaju odozgo na doli ili sa lijeva u desno u poretku u kojem su dodate u kontejner Kombinujuci visestruke kontejnere koji koriste box layout, mogu se kreirati razne konfiguracije Visestruki kontejneri sa box layout-om se radije i cesce upotrebljavaju nego jedan kontejner koji koristi komplikovaniji gridbag layout menadzer © 2004 Pearson Addison-Wesley. All rights reserved

Box Layout Nevidljive komponente mogu se dodati na box layout kontejner da bi popunile prostor izmedju komponenti Rigid areas imaju fiksnu duzinu Glue specifikuje gdje moze ici visak prostora Rigid area se kreira koristeci createRigidArea metodu klase Box Glue se kreira koristeci createHorizontalGlue ili createVerticalGlue metode Vidi BoxPanel.java (strana 352) © 2004 Pearson Addison-Wesley. All rights reserved

Borders (granice) border se moze staviti oko svake Swing komponente da definise kako se crtaju grane komponente Granice mogu biti efektno koristene za vizualno grupisanje komponenti Klasa BorderFactory sadrzi vise statickih metoda za kreiranje objekata granice Granicna linija se stavlja na komponentu koristeci metodu setBorder © 2004 Pearson Addison-Wesley. All rights reserved

Borders (konture, granice)
empty border (prazna granica) Baferuje prostor oko grane neke komponente Inace nema vizualni efekat line border (linijska granica) Okruzuje komponentu jednostavnom linijom Boja i debljina linije mogu se specificirati Etched border Kreira efekat groove oko komponente Koristi boje za osvjetljavanje i sjencenje © 2004 Pearson Addison-Wesley. All rights reserved

A bevel border Moze biti podignuta ili spustena Korisiti boje za spoljasnje i unutrasnje osvjetljavanje ili sjencenje A titled border Postavlja naslov na ili oko konture Naslov moze biti orijentisan na razne nacine A matte border specifikuje odvojeno velicine gornje, lijeve, donje, i desne grana konture Koristi boju ili sliku © 2004 Pearson Addison-Wesley. All rights reserved

Sazetak Glava 6 razmatra: Aktivnosti pri razvoju softvera
Odredjivanje klasa i objekata koji su potrebni za program Odnose koji mogu postojati izmedju klasa Modifikator static Pisanje interfejsa Dizajn enumerativnih tipova klasa Dizajn metoda i preopterecenje metoda Dizajn GUI i menadzera layout-a © 2004 Pearson Addison-Wesley. All rights reserved

Objektno-Orientisani Dizajn

Similar presentations

Presentation on theme: "Objektno-Orientisani Dizajn"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Objektno-Orientisani Dizajn

Similar presentations

Presentation on theme: "Objektno-Orientisani Dizajn"— Presentation transcript:

Similar presentations

About project

Feedback