Keskustelu: Ohjelmointikysymykset: Odottaminen (Java)

Rupesin nyt vihdoin opetteleen tota javaa ja tein tuosta hello worldista pienen muunnoksen. Eli tuossa vaan 3 eri lausetta eri väreillä.

Nyt ois tarkotuksena saaha appletista sellanen, että se tulostaa ensiksi tuon Moro maailmalle, sitten se odottaa vaikka 5 sekuntia ja tulostaa sen jälkeen Jee tämähän toimii By dain jne.

Koitin jotain apua netistä ettiä mutta mitään mieltäylentävää en löytänyt. Jotain sleep tai wait juttua sielä oli, mutta sitä en tajunnut.

koodia:

import java.applet.Applet;
import java.awt.Graphics;
import java.awt.*;
public class tekstintulostus extends Applet {
		public void paint (Graphics x)  {
		Color vihrea = new Color(0,225,0);
		Color sininen = new Color(0,0,225);
		Color punainen = new Color(225,0,0);
		x.setColor(vihrea);
				x.drawString("Moro maailmalle !!!",20,20);
				x.setColor(sininen);
				x.drawString("Jee tämähän toimii By Dain !!!",20,50);
			x.setColor(punainen);
			x.drawString("Ja tämähän on siis java-appletti",20,80);

			}
}

ps. Miten saan sillai, että toi näyttää ton koodin sillai järkevästi rivitettynä niinkuin olen joidenkin nähnyt tekevän.

Mod. lisäsi kooditagit!

Tässä on metodi, joka odottaa halutun ajan (millisekunteina):

public void odotus (int aika) {
    try {
        Thread.sleep(aika);
    } catch (Exception e) {
    }
}

Esimerkiksi voit odottaa viisi sekuntia kutsumalla metodia näin:

odotus(5000);

Antti Laaksonen kirjoitti:

Tässä on metodi, joka odottaa halutun ajan (millisekunteina):

public void odotus (int aika) {
    try {
        Thread.sleep(aika);
    } catch (Exception e) {
    }
}

Esimerkiksi voit odottaa viisi sekuntia kutsumalla metodia näin:

odotus(5000);

Muuten hyvä paitsi:

http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#sleep(long)

Paitsi että mitä?

Sami kirjoitti:

Paitsi että mitä?

Thread.sleep() parametri on long eikä int.

_Pete_ kirjoitti:

Sami kirjoitti:

Paitsi että mitä?

Thread.sleep() parametri on long eikä int.

Harvemmin sitä kumminkaan on tarvetta odotella 23 päivää enempää.

Joo, mutta tuossahan otettiin kantaa tuohon, että tuo oli integer tuo aika.
Itse en ota kantaa onko se vai ei. En tiedä, en käyttänyt koskaan odotusta.

Kyllä Java castaa sen intin longiksi.

byte -> short, short -> int, int -> long ja float -> double -muunnokset (eli muunnokset pienemmästä tietotyypistä suurempaan) onnistuvat aina, eikä tästä tule edes varoitusta. Sen sijaan käänteisesti muunnos ei välttämättä onnistu ja kääntäjä antaakin tästä virheen, mutta muunnoksen voi silti pakottaa itse jos haluaa.

Ja luulen että olet itsekin antanut tuolle sleep-metodille aika usein, ellet aina, int-tyyppisen arvon. Vai oletko kutsunut sitä ja muita long-tyyppiä haluavia metodeita aina sleep(1000l) tai sleep((long)1000)?

Sami kirjoitti:

byte -> short, short -> int, int -> long ja float -> double -muunnokset (eli muunnokset pienemmästä tietotyypistä suurempaan) onnistuvat aina, eikä tästä tule edes varoitusta. Sen sijaan käänteisesti muunnos ei välttämättä onnistu ja kääntäjä antaakin tästä virheen, mutta muunnoksen voi silti pakottaa itse jos haluaa.

Ja luulen että olet itsekin antanut tuolle sleep-metodille aika usein, ellet aina, int-tyyppisen arvon. Vai oletko kutsunut sitä ja muita long-tyyppiä haluavia metodeita aina sleep(1000l) tai sleep((long)1000)?

Olet oikeassa. Mutta jos tekee utility-metodia sen ei kuulu kätkeä varsinaisen
metodin arvoa.

Paint-metodissa nukkuminen ei ole kovin hyvä idea, koska se blokkaa koko käyttöliittymän. http://en.wikipedia.org/wiki/Event_dispatching_thread

_Pete_ kirjoitti:

Olet oikeassa. Mutta jos tekee utility-metodia sen ei kuulu kätkeä varsinaisen
metodin arvoa.

Antti näyttää koodanneen Dainin speksaaman metodin, eli vastanneen kysymykseen.

Tuo metodi toimii nimenomaan annetun luokan metodina ja tuottaa toivottua suuruusluokkaa olevan viiveen. Se ei toimi staattisesta luokasta kutsuttuna, vaan silloin sille pitää antaa myös määre static.

Tiettyyn tarkoitukseen tehdyssä metodissa käytetään tarkoitusta vastaavia parametreja, joilla ei ole mitään tekemistä niiden arvojen kanssa, joita metodi sisäisesti käyttää. Mitään "varsinaista" metodia tässä ei ole, eikä yleensäkään ole, vaikka jokainen vähänkin monimutkaisempi metodi toki kutsuu useaakin muuta metodia.

hk kirjoitti:

_Pete_ kirjoitti:

Olet oikeassa. Mutta jos tekee utility-metodia sen ei kuulu kätkeä varsinaisen
metodin arvoa.

Antti näyttää koodanneen Dainin speksaaman metodin, eli vastanneen kysymykseen.

Varmasti onkin. Jos tällainen ehdotelma tulisi töissä vastaan review-listalla
-> failed

Sen takia koska utility-metodin ei kuulu/saa kätkeä tällä tavalla parametrintyyppiä varsinaiseen kutsuun. Vaikka virheen mahdollisuus on se on
-> FAIL

Ohjelmoinnissa syy "toimii about oikein" on kaikista huonoin vaihtoehto.

Kyllä se sisäisen rakenteen piilottaminen on päinvastoin enemmänkin olio-ohjelmoinnin perusperiaatteita kuin kiellettyä. Useinkin Javan valmiiden luokkien parametrit tai paluuarvot eivät vastaa sovelluksen tarvetta, jolloin on syytä kirjoittaa konversio väliin koodin lyhentämiseksi ja selkeyttämiseksi. Samanlaisiin ratkaisuihin päädytään välillä valmista koodia hyödynnettäessä. Silti usein kannattaa käyttää pohjana valmista luokkaa sen sijaan, että kirjoittaisi koko homman itse. Sisäisen ja ulkoisen datan erilaiselle muodolle voi olla monia hyviä tai jopa pakottavia syitä silloinkin, kun käsitellään primitiivityypin arvoja.

Em. metodissa ei ole minkäänlaista "virheen mahdollisuutta" sen takia, että kutsussa annetaan int eikä long. Koodin kirjoittaja ei ehkä ollut tarkoituksella valinnut suppeampaa arvoaluetta kuin olisi ollut mahdollista, mutta arvoalueen rajaaminen päinvastoin vähän ehkäisee ylipitkiä odotusaikoja, kun kerran tiedetään, että halutaan viivettä, jonka ajan käyttäjä jaksaa tuijottaa ruutua. Tässä ei siis ole mitään "about oikein toimivaa". Ei ole olemassakaan mitään "varsinaisia" kutsuja. Metodi voi kutsua toisia metodeja tai olla kutsumatta.

Sain jo avun :D voittehan te jatkaa rakentavaa väittelyänne tästä jos haluatte ei se minua haittaa...

Kaikella kunnoituksella: tämä rakentava väittely on paljon hyödyllisempää kuin tuo alkuperäisen ongelman ratkaseminen :)

Ite en ymmärrä, mitä vikaa tuossa Antin metodissa nyt muka oli: jos joku tahtoo nukkua yli 23 päivää, kutsukoot Thread.sleepiä suoraan.

hk kirjoitti:

Kyllä se sisäisen rakenteen piilottaminen on päinvastoin enemmänkin olio-ohjelmoinnin perusperiaatteita kuin kiellettyä.

Tuo on eriasia. Piilottamisen tarkoitus ei ole kuitenkaan se että sen avulla mahdollistetaan virhetilanne. Tai jos se tietentahtoen tehdään se pitää julkisessa metodikutsussa selvästi dokumentoida/perustella.

En ymmärrä vieläkään, mikä virhetilanne metodiini liittyy.

Tarkoitus ei ollut tehdä metodia, jonka kautta voi käyttää Thread.sleep-metodia, vaan metodi, jonka avulla voi odottaa halutun ajan.

Ehkö Pete ajatteli väärin päin, että kutsussa on laajempi arvo kuin sisäisessä metodissa, jolloin voisi tulla virhetilanne? Näin ei ole.

Olisi kiva kuitenkin kuulla häneltä, mikä on utility-metodi, ja mitä lainalaisuuksia hänen mielestään sellaiseen liittyy. Koska utility-metodi ei ole mikään yleisesti tunnettu käsite. Haluaisin muös kuulla perustelun / tutkimuksen / lähteen, jonka mukaan tällaisen metodin pitäisi olla jotenkin tietynlainen.

Kääntäjä kyllä kertoo, jos argumentti on väärää (liian suurta) tyyppiä. Tuolle voi toki yrittää antaa long-arvon, aivan kuten Thread.sleep-funktiolle voi yrittää antaa liukuluvun. Molemmista tulee virheilmoitus. Niinpä tähän ei liity (parametrin tyypin puolesta) sen suurempaa virheen mahdollisuutta kuin tavalliseen sleep-kutsuunkaan.

Sen sijaan poikkeus olisi turvallisinta käsitellä jotenkin, edes tulostaa sen viesti virhevirtaan. Koska kyseessä on InterruptedException, voisi olla hyvä myös kutsua Thread.currentThread().interrupt(), tosin aloittelijan ohjelmassa tuskin on niin hienoa koodia, että tällä olisi merkitystä.

Eikös se nyt ole jo moneen kertaan todettu, että parametri on ihan ok, kuten koko metodikin ajatellen pyydettyä käyttötarkoitusta?

Poikkeusta taas ei tässä tilanteessa saisi syntyä. Jos niin käy, ei sille oikein ole mitään tehtävissä "hienommassakaan" koodissa? Lähinnä tulee mieleen, että olisi jo viive-metodin alussa pantu ylös alkuaika, ja siinä tapauksessa voidaan odottaa haluttu aika ilman Thread.sleep()-kutsua.

Mutta Petelle esitetyt kysymykset ovat edelleen vastausta vailla.

hk kirjoitti:

Eikös se nyt ole jo moneen kertaan todettu, ...

Onhan se. Esitin kuitenkin perustelun, jota ei ole vielä suoraan sanottu; kaikki keskustelijat eivät välttämättä tiedä asiaa ennestään.

hk kirjoitti:

Poikkeusta taas ei tässä tilanteessa saisi syntyä. Jos niin käy, ei sille oikein ole mitään tehtävissä "hienommassakaan" koodissa?

Esimerkiksi monisäikeisessä ohjelmassa säikeen kuuluu usein sulkeutua. Jos poikkeus vain napataan, tieto keskeytyksestä ei välity. Seuraava säie jäisi siis ikuiseen silmukkaan:

class Tyo extends Thread {
  public void run() {
    while (!Thread.interrupted()) {
      // Tee jotain...
      odota(1000);
    }
  }
}