Mihin perinnällä pyritään? Mitä etuja/haittoja on moniperinnässä? moniperinnän ongelmia on ainakin se, että kaksi isäluokkaa määrittelee saman nimisiä kenttiä/metodeja yksi niistä.. toinen voisi olla tuo, että niillä perityillä luokilla voi olla mitä sattuu yläluokkia jolloin ne ovat mahd samojaki Moniperintä on hyödyllistä silloin, kun olio kuuluu käsitemallissa yhtäaikaa useampaan luokkaan. mut mihin muuhun perinnällä pyritään helpompaan ja loogisempaan tapaan esittää luokkahierarkiaa? kaikki isäluokasta perityt luokat voi käyttäytyä kuten itse isäluokka, mites tämän ilmaisisi... esim containerit, voit tunkea niihin mitä vaan objektista perittyä *************** Mihin rajapinnoilla pyritään ja miten siinä onnistutaan? Mitä polymorfismilla saavutetaan ja mitä ongelmia siitä seuraa? hmm.. onkohan tuohon nyt jotain parempaa selitystä kuin tuo moniperinnän toteutus ei tuo musta muuta ole toki tuolla sitten saadaan helpotettua koodausta, jos annetaan vaan rajapinnat itsenäisille koodaajille jotka toteuttavat ne joo siis tuon voisi mainita hmm polymorfismin saavutukset no tuo virtuaalinen perintä on kyllä se kaikkein kovin Funktiota sanotaan monimuotoiseksi, jos samaa funktiosymbolia voidaan käyttää eri tyyppisillä argumenteilla. Esimerkiksi aritmeettiset operaattorit +-*/ toimivat yleensä sekä kokonaisluvuilla että liukuluvuilla, ja sopeuttavat toimintansa argumenttien tyyppien mukaan. Olio- ohjelmointi toteuttaa jo kaikkein yksinkertaisimmassa muodossa polymorfismin siten, että eri luokille voidaan määritellä saman nimisiä metodeja. Esimerkiksi graafisille olioille Circle, Rectangle ja Line voi kaikille olla määriteltynä metodi Draw, joka osaa kyseisen kuvion piirtää. oleellista tällöin on se, että vaikka toimitetaankin tämä luokka sen isäluokan (Shape) esiintymänä, käytetään suorituksessa kyseisen aliluokan metodeja mitä ongelmia tuosta seuraa? ainakin, että ei voi olla varma minkä luokan metodia kutsutaan mutta esim koodia katsomalla ei voi tietää mitä metodia oikeasti kutsutaan, ellei kelaa koko perintähierarkiaa läpi no siitä voisi sanoa sen, ettei siinä voi mitenkään kontrolloida sitä, mitkä metodit toimivat tällä kyseisellä tavalla no siitä voisi sanoa sen, ettei siinä voi mitenkään kontrolloida sitä, mitkä metodit toimivat tällä kyseisellä tavalla koska voi olla tilanteita joissa tuo ei ole haluttua, vaikka mieleeni ei tosin tule mitään ******************* Arvioi Javan poikkeuksenkäsittelymekanismin vahvuuksia ja heikkouksia. Arvioi modulaarisuuden ja enkapsuloinnin onnistuneisuutta java.io-paketissa modulaarisuus http://www.cs.uta.fi/~zsjv/johoh/luennot/Funktiot.htm http://www.cs.utu.fi/knuutila/Courses/okp/luennot/modulit.pdf heh, no toi io-paketti selviää tutkimalla apidoccia no tuo poikkeuskäsittely.. Okei, tuollaisessa poikkeuksenkäsittelyssä on tosi paljon hyviä puolia helpottaa virheiden käsittelyä yksinkertaistaa koodia tuo on yhtenäinen tapa tuohon, joten sen ymmärtäminenkin on paljon helpompaa kuin joku virhekoodien palauttaminen poikkeuksenkäsittelyssä otetaan myös huomioon luokkahierarkia siis poikkeuksien puolelta jolloin kiinniotettavien poikkeuksien tasoa voi säädellä helposti jep debuggauskin helpottuu kun noista poikkeuksista saa aina stack tracet niin joo.. ja sit vielä toi poikkeuksien propagoituminen aktivaatiotietueissa eli kutsuhierarkiassa ylöspäin jep, mitä heikkouksia? saattaa olla hitaampaa? joo jossain tosi aikakriittisissä tilanteissa joissa nopeampaa olisi vain palauttaa 0 tai 1 ********************* Mitkä ovat olio-ohjelmoinnin käytön hyödyt ja haitat verkko-ohjelmoinnissa? Mikä rinnakkaisohjelmoinnista tekee vaikeaa ja miten se voidaan huomioida ohjelmointikielten suunnittelussa? hyödyt vois olla tuo nopea prototyyppäys joka saadaan aikaan serialisaatiolla, tai sit esim RMI:llä tuossa kyseisessä tilanteessa on tietenkin huonona puolena se, että se tuhlaa ihan sairaasti olio-ohjelmoinnilla voidaan myös piilottaa alla olevat protokollat ja käyttää kaikkia samalla tavalla verkkoprotokollat siis noita verkkoluokkia.. no jossain rajoissa tuo on tietysti mahdollista oleellisilta osin ne pystytään abstrahoimaan muttei välttämättä täysin prototyyppäys? eli siis testaus ratkaisun toimivuuden esim tai pelkän idean toisin sanoen noin on sairaan helppo lähettää kokonaisia luokkahierarkioita verkon yli paljon helpompaa kuin esim c:llä objekti voidaan tunnistaa just tuon takia jep kun se voidaan helposti tunnistaa sit rinnakkaisohjelmointi.. rinnakkaisuudesta tekee vaikeaa datan jakaminen joo ja yleinen lukkiintumien välttäminen joka siis liittyy tuohon resurssien jakamiseen oli resurssi sitten mitä tahahnsa tämän vuoksi myös rinnakkaisohjelmoinnissa voi olla vaikeaa saavuttaa tehokkuutta jos esim kauheesti aikaa menee johki resurssien odotteluun atlas__> kuten decentissä nähdään nyks nyks se meni kyllä varmaan täysin deadlockiin niin jossain vaiheessa kyllä esim 4:llä botilla 3 starting pointtia kentässä.. menee päällekkäin kos vaikeaa ohjelmoida, ja erittäin vaikea todistaa toimivaksi koska skeduloinnilta ei voida teoriassa olettaa _mitään_ muuta kuin että prosessi saa aikaa kielten suunnittelussa tuohon voidaan varautua antamalla valmiit semaphoret tms. esim. javassa on objektissa nuo joo ja niin että ne on suoraan käsillä wait(), sleep() ja mitä muita nyt olikaan spesiaaleilla määreillä voidaan "kaunistaa" koodia kenties t2 luentokalvoissa 13 on tuosta rinnakkaisuudesta samoin 14 ******************* Kuvaile ohjelmistoprosessi, joka soveltuu kurssin ohjelmointiprojektiin. Arvioi suunnittelumallien merkitystä ohjelmistokehityksessä. no nuo mallit on kokemuksen myötä hyväksi havaittuja tapoja tehdä softaa esim arkkitehtuurit meillä oli client-server asetetaan tavoitteet, aletaan koodata jatkuvan kommunikaation alla, testataan aluksi käytettävien kikkuloiden toiminta, aletaan suunnitelman mukaan toteuttaa projektin osia (ei ihan näin mennyt oikeesti), korjataan bugeja, tehdään lisää, korjataan taas bugeja, tuote valmis :) joo ja noita suunnittelumalleja kannattaa oikeasti käyttää heti kun hallitsee kielen muuten, koska niiden käyttäminen ei ole pelkästään hyvä tapa, mutta lisäksi se helpottaa muiden asiaan tutustuneiden koodista selvänsaamista ja ymmärrystä kun tietyt asiat koodataan aina samalla tavalla jep ja viisas ihminen oppii muiden virheistä ennen kuin tekee ne itse eli tuiossa mielessä ei olisi ollenkaan pahasta edes tietää noiden mallien tausta projektiin me sovellettiin XP:tä no joiltakin osin kuten esim se että tehdään sitä mitä seuraavaksi tarvitaan jep mutta testien osalta ei. mutta nuo on merkittäviä isojen softien kehittämisessä kyllä, koska siellä ei tämänkaltainen kommunikaatio ole enää mahdollista koska ilman suunnittelua niistä ei tule mitään ja nuo mallit on yleisesti tiedossa joita muuten voisi tosissaan joskus harjoitella.. joten kaikkien on suht helppo tajuta mitä koitetaan tehdä toistaiseksi ei tiedä kuin suunnillene singletonin :) joo, factoryihin pitää ainakin perehtyä joskus niitä käytetään kunnon engineissä http://gsraj.tripod.com/design/creational/factory/factory.html gamedev:ssä on aika usein joku sanomassa "miks teit noin? käytä xxx-factory patternia" The Problem One of the goals of object-oriented design is to delegate responsibility among different objects. This kind of partitioning is good since it encourages Encapsulation and Delegation. * Sometimes, an Application (or framework) at runtime, cannot anticipate the class of object that it must create. The Application (or framework) may know that it has to instantiate classes, but it may only know about abstract classes (or interfaces), which it cannot instantiate. Thus the Application class may only know when it has to instantiate a new Object of a class, not what kind of subclass to create. * a class may want it's subclasses to specify the objects to be created. * a class may delegate responsibility to one of several helper subclasses so that knowledge can be localized to specific helper subclasses. tlas__> noita pitää tosiaan treenaa *********************** nurtsi> Keille tai millaiseen käyttöön J2EE on tarkoitettu? Arvioi sen hyödyllisyyttä. Analysoi Servlet-API:n arkkitehtuuria. Tarkastele esimerkiksi modulaarisuutta, tiedon kapselointia sekä suunnittelumalleja (esitän epäilykseni että tätä ei kysytä.. businessmiehille tuo on jos pitää tehdä kaupallista softaa siis kaupallista == jotain tosi tylsää, kuten varastohallintaa tms. ja isoilla järjestelmille, joissa on rautaa ja ruista. Voidaan tuottaa helposti rinnakkaisia transaktiojärjestelmiä nurtsi> jep nettisovelluksia, verkkokauppoja ************************ Millaisissa ohjelmistoissa tarvitaan tapahtumankäsittelymekanismeja? Miksi? Analysoi Swing-API:n arkkitehtuuria. Tarkastele esimerkiksi modulaarisuutta, tiedon kapselointia sekä suunnittelumalleja. windowsissa :) (graafisissa)käyttöliittymissä melkein poikkeuksetta koska muuten niiden hallinta olisi yksinkertaisesti liian hankalaa sanokaas mitä tarkoittaa granularity se oli sitä rakeisuutta hienojakoisuus vai mikä tuo nyt on? eli tehdään mahd. isoja komponentteja jotka räplää keskenään j2ee:ssä The granularity of an OO program is quite small tä granularity, se katoaa mun päästä _aina_ eli se kuvaa miten isoista irrallisista komponenteista softa koostuu okei pieni granulariteetti => paljon paloja iso granulariteetti => vähän paloja noni. pidetään nyt tuo muistissa. mutta eventeistä lisää.. niin, eli koska käyttäjä sotkee kokoajan ohjelman toimintaa, ei mitään voida olettaa siksi pitää olla joku geneerinen tapa hoitaa tapahtumia => tarvitaan jokin geneerinen ratkaisu.. jossa voidaan saada käyttäjän toimista tieto. tieto voi sitten luonnollisesti olla tasoltaan vaihetelevaa,m mutta yleistä on, että saadaan tieto tapahtuman kohteesta ja sen aiheuttajasta ja vastaavista jep ja käyttöjärjestelmän komponentit voi sitten viestiä toisilleen mitä tulee tehdä esim jos isä-ikkuna suljetaan niin kaikki lapset tapetaan myös nurtsi> tai jos näytetään jotain ERROR-ikkunaa, niin se pitää sulkea ensin, ennen kuin voi tehdä muuta eli varmistetaan, että käyttäjä huomaa jotain menneen pieleen onko jo sanottu, että tapahtumat ovat tapa luoda interaktio käyttöliittymiin tai oikeastaan luoda ohjelmoijan hallittavissaoleva interaktio eli "widget set" hoitaa kyllä leijonanosan tuosta kaikesta valmiiksi, mutta se viimeinen silaus jää tapahtumankäsittelyn ja ohjelmoijan harteille lisäksi noi GUI:t on rinnakkaissovelluksia, joten eri prosessit viestii myös keskenään tuskin ne mitään api-kysymyksiä kysyy joo ei varmaan, se olisi kans älytöntä noissa pitää vaan sitten selata javadoccia mutta.. mitenkäs niitä analysoisit? kelaamalla dokkia vain? siis mitä niistä etsii niin ei olla tuota mietitty.. kattoo mitä metodeja siellä on ja luokkia koska ei niiden sisällöstä kuitenkaan mitään voi tietää en mä keksi äkkiseltään nista mitään hyvää/huonoa.. siis jotain erottuvaa ********************* Milloin arkkitehtuuria pitäisi muuttaa, mitä muuttaminen edellyttää ja mitä sillä pyritään saavuttamaan? Millä perusteella arkkitehtuurivalinta tehdään ja miten sen onnistuneisuutta voidaan arvioida? muuttaa pitää esim silloin, kun arkkitehtuuri yksinkertaisesti estää jonkin asian järkevän totutettamisen jos pitää vaihtaa niin uuden valintaan vaikuttaa muutoksen suuruus, toteuttamisriskit, paljonko saadaan lisää tehoa, kuinka kauan menee vaihtamiseen jne. onko noi suoraan kalvoista? joo luento 10 tuo ohjelmistoarkkitehtuurit kalvo? tai ei millään tavoin tue jonkin uuden ominaisuuden toteuttamista kai sillä sit pyritään poistamaan havaittuja pullonkauloja, mahdollisesti lisäämään tehoa, mitä muuta.. ******************* Täällä tankataan T3:a? joo luentotehtäviä pohditaan porukalla Hmm.. Meillä tais olla justiin toi arkkitehtuurin muuttaminen. Niin joo. Se kysymys oli tapahtumankäsittelymalleista. Tai siis siitä, että mihini niitä tarvitaan. Myös ei-graafisissa sovelluksissa.. ********************** Arvioi hyötyjä ja haittoja, joita voi seurata rajapintojen "standardoinnista" yhä spesifisemmille sovelluskohteille (tietoturva, mobiilisovellukset). no standardoinnissa paljastetaan miten kys. asiat on tehty, eli helpotetaan kräkkereiden toimintaa mutta mitäs tuolla yhä spesifisemmille oikeastaan tarkoitetaan.. ja toisaalta voidaan ajatella hyviä puolia standardoinnissa, että kun se on julkista tietoa, niin on useampia päitä miettimässä ja todentamassa mahdollisia vikoja ja reikiä mahdollisuus havaita niitä ehkä paranee jep, ja mahdollisesti standardoitu tuote on helppo portata muille alustoille joo tuo just käyttäjien ei tarvitse pohtia, että mikäköhän tapa toimii vielä ensi vuonna standardien noudattaminen on hyvä tapa juuri tuon takia kans.. kuten nää saatanan webbitekniikat ne on tässä asiassa murheellinen esimerkki web+selaimet XML on taas hyvä esimerkki loistavasta standardoinnista sen sovellukset ovat rajattomat :) nurtsi> hmm, tuosta standardoinnista yhä spesifistisemmille alustoille seuraa kyllä se, että itse standardi paisuu eli siitä tulee vaikea toteuttaa täysin eikä se välttämättä ole enää hyödyllistä standardoida tommosia pieniä asioita, koska yleensä pikkuraktaisut on jotain niin full-customeita kuitenkin ************************ Milloin kannattaa käyttää ns. sovelluskehitintä (integrated development environment, IDE), milloin ei? Miten ohjelmistotiimin toiminta muuttuu kun tiimin koko kasvaa (luokkaa 5 -> 50)? isoissa projekteissa joissa on paljon ihmisiä ja miksei vähemmälläkin ihmismäärällä IDE käytetään GUItten tekoon jos sen käytöstä jotain haittaa on, niin ehkä konegeneroidut koodit ei paljoo tuu mieleen miksi ei käyttäisi IDEä, jos sellainen on ehkä overkilliä johki pieneen testiohjelmaan, mutta ei siinäkään haittaa.. IDE voi toimia myös vaan yhdellä alustalla, joten jos pyritään porttaamaan niin jotkut makefilet tms. pitää tarjota muillekin niin no tuo porttautuvuus on yleensä idejen ongelma varsinkin suurempien graafisten kun ei oikein keksi mitään isompia haittoja tuosta.. kuin tuo porttaus ehkä vaatii koneelta paljon toisinaan mutta se on ehkä epäoleellista kuten se ibm.. nurtsi> mitäs tuosta tiimin kasvusta? ainakin kommunikaatio menee uusiksi 50 jeppeä ei irkkaa no eikös tuo iden käyttö tule juuri silloin kuumaksi aiheeksi. kaikkien pitää käyttää yhteneviä työkaluja kommunikaatiotapa täytyy standardoida eli esim luodaan jokin maililista tahi, sitten kehitetään jokin integroitu kommunakaatioratkaisu siis ideen nuo yhtenevät kalut on tärkeimmät kyllä, ja siinä nousee tuo ide asemaan ************************************ Missä ohjelmistokehityksen vaiheissa testausta tulisi suorittaa ja mihin sillä kulloinkin pyritään? Millaisia edellytyksiä automaattisen testauksen käyttö asettaa kehitettävälle ohjelmistolle sekä käytettävälle ohjelmistoprosessille? testausta pitäisi harjoittaa jatkuvasti tuo automaattinen vaatii, että testit kirjoitetaan jollain tietyllä tavalla niin kuten esim tuo junit pyrkimyksenä koodin alkuvaiheissa on vain esim todentaa ratkaisun toimivuus muutamalla erilaisella testitapauksella, jotta nähdään että potentiaalia löytyy myöhemmin sillä on tarkoitus ottaa esim. selvää siitä, ettei koodiin ole jostain yhteensattumasta ilmaantunut jotain hämärää bugia tai vaikkapa tarkastella mahdollisia suorituskyvyn taantumia, profilointia ja sen semmoista puhutaan aina netissä regressionseista siis jos koodissa on jotain taantumaa eli myöhemmin sen tarkoitus on ylläpitää ehkä sitä koodia.. onkos tuossa automaatisessa testauksessa vielä jotain muuta? käytettävälle ohjelmistoprosesille.. mitäs sillä tarkoitetaankaan nyt..