JAVA Programmeren

[Jazzcrime]

Beste mensen!

Ik ben een opdracht aan het maken waarbij ik met gebruik van java een schrikkeljaarcalculator moet maken met daarom heen gebouwd een GUI. Nu heb ik een GUI gemaakt, en de basis functies (exit/clear field) werken, ik heb ook een formule gemaakt om een schrikkeljaar te bereken maar door mijn slechte kennis in java weet ik niet hoe ik deze moet toepassen!

Als er mensen zijn met verstand van java zou ik hem/haar hulp echt heel erg op prijs stellen! (ik gebruik trouwens netbeans)

Groetjes!

Men neme een voorbeeldprogramma dat qua concept lijkt op wat jij wil, bestudeert het voorbeeld.. en als het goed is, kun je de rest zelf

http://java.sun.com/docs/books/tutor...arn/index.html

Event listeners gebruiken:

http://java.sun.com/docs/books/tutor...arn/logic.html

http://java.sun.com/docs/books/tutor...nts/intro.html

[Jazzcrime]

Hey! bedankt voor je reactie, Ik heb mn programma iets aangepast zodat het meer op de CelsiusConverter lijkt.

een - JButton naam: BerekenenButton
- jTextField1 naam: jTextfield1
- JLabel naam: SchrikkeljaarLabel

de formule om een schrikkeljaar te berekenen is:

((year%4!=0)||(year%4==0)&&(year%100==0)&&(year%400!=0))

Ik heb van alles geprobeerd maar ik krijg hele tijd meldingen dat er fouten zitten in mn script. Ik heb niet veel tijd meer voordat het programma moet worden ingeleverd dus ik zou het erg op prijs stellen als je me nog een stap verder zou kunnen helpen

[Chimera]

Ja want met "er zitten fouten in m'n script" komen we een heel eind

[Jazzcrime]

Oke, mijn App ziet er als volgt uit: 'http://img490.imageshack.us/my.php?image=javaappms6.jpg'
'http://img237.imageshack.us/my.php?image=javaapp2mr4.jpg'

de code om de berekening voor elkaar te krijgen zal wel niet veel groter zijn dan het eerder gegeven voorbeeld door ******** (http://java.sun.com/docs/books/tutor...arn/logic.html)

en het principe is vrijwel hetzelfde, er moet namelijk informatie gelezen worden van het jTextfield1.

vervolgens moet er dus berekend worden of het een jaartal is en of het voldoet aan de eisen van een schrikkeljaar (zie formule).

Als laatste moet er bij mijn jLabel1 een output komen in de zin van 'ja' of 'nee'

ik vond http://www.terranovaconsulting.ca/java/sampleprogs3.htm een sample van iets dat redelijk in de buurt komt.

ik hoop dat deze extra info wat meer helpt

thx in advance!

[Chimera]

Ik zie niet waarom we moeite zouden doen als je zelf niet de code + de foutmeldingen post.

[Jazzcrime]

int schrikkeljaar = (int)((Double.parseDouble(jTextField1.getText())) (((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0)) ? 1 : 0; SchrikkeljaarLabel.setText (schrikkeljaar);

Read year as input
IF year is NOT divisible by 4
Display "not a leap year"
otherwise, IF year is divisible by 100 AND NOT divisible by 400
Display "not a leap year"
otherwise, Display "leap year"

ik weet dat er een if/else gedeelte in moet zitten ik heb alleen geen flauw benul en ja ik heb tig examples gezien en van alles doorgelezen hoe ik het moet toepassen in mn formule.

[Chimera]

Jazzcrime schreef op 13-08-2007 @ 14:17 :
int schrikkeljaar = (int)((Double.parseDouble(jTextField1.getText())) (((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0)) ? 1 : 0; SchrikkeljaarLabel.setText (schrikkeljaar);

Read year as input
IF year is NOT divisible by 4
Display "not a leap year"
otherwise, IF year is divisible by 100 AND NOT divisible by 400
Display "not a leap year"
otherwise, Display "leap year"

ik weet dat er een if/else gedeelte in moet zitten ik heb alleen geen flauw benul en ja ik heb tig examples gezien en van alles doorgelezen hoe ik het moet toepassen in mn formule.

*zucht*

Ik vraag je de SOURCE en de FOUTMELDINGEN te posten. Ik weet niet wat voor'n opleiding je doet maar hij is overduidelijk niet geschikt voor je.

Dat je foutmeldingen krijgt verbaast me niks want ik zie nergens year gedefinieerd staan. Verder is dat stukje onder "Read year as input" geen Java code.

//Lees invoer
int jaar = Integer.parseInt(jTextField1.getText());
boolean isSchrikkeljaar;

//Bepaal of de invoer een schrikkeljaar is.
if(jaar % 4 == 0)
{
	if(jaar % 100 == 0 && jaar % 400 != null)
	{
		isSchrikkeljaar = false;
	}
	else
	{
		isSchrikkeljaar = true;
	}
}
else 
{
	isSchrikkeljaar = false;
}

//Vul text van Label
if(isSchrikkeljaar)
{
	schrikkeljaarLabel.setText (input + " is een schrikkeljaar.");
}
else
{
	schrikkeljaarLabel.setText (input + " is geen schrikkeljaar.");
}

Dit zou moeten werken, ik heb het niet gechecked verder. Let wel: ik heb schrikkeljaarLabel met een kleine letter gebruikt zoals het hoort, members zijn case-sensitive en horen met een kleine letter geschreven te worden, zoals jTextField1. Verder raad ik je aan de code te begrijpen (als je iets niet begrijpt moet je dat maar laten weten), maar het enige wat je bereikt met het inleveren van voorgekauwd huiswerk is dat je later grandioos op je bek gaat.

[Jazzcrime]

ik heb een paar kleine dingen veranderd:

int jaar = Integer.parseInt(jTextField1.getText());
boolean isSchrikkeljaar;


if(jaar % 4 == 0)
{
if((jaar % 100 == 0) && (jaar % 400 != 0))
{
isSchrikkeljaar = false;
}
else
{
isSchrikkeljaar = true;
}
}
else
{
isSchrikkeljaar = false;
}


if(isSchrikkeljaar)
{
schrikkeljaarlabel.setText (jaar + " is een schrikkeljaar.");
}
else
{
schrikkeljaarlabel.setText (jaar + " is geen schrikkeljaar.");
{



en het werkt allemaal naar behoren nu, dus bij deze thanks voor je script,

zoals je zelf al 'scherp' opmerkte is dit niks voor mij, en moet ik nog 1 jaar ict voordat ik begin aan hbo pedagogiek dus je hoeft niet wakker te liggen met de gedachten dat ik later op mijn bek ga

danku wel!

[Chimera]

Goeie keuze Succes verder

[Jazzcrime]

er is overigens nog 1 ding, op het moment dat ik een ongeldige waarde invoer gaat mijn programma, heel logische stijgeren omdat hij weet wat hij met de ongeldige waarde moet.

is er een 'eenvoudige' functie in te bouwen zal wel iets met 'if' zijn waardoor op het moment dat ik bijvoorbeeld '23av' of '@#@*' invoer en op mijn 'berekeken' knop druk, het programma niet doorgaat met berekenen maar gelijk zegt 'ongeldige waarde ' met als output mijn schrikkeljaarlabel

gegroet!

[Chimera]

Lees even een stukje over try-catch blokken en het afvangen van exceptions. Er moet een try-catch blok om dat inlezen van die int (Integer.parseInt) maar hoe dat moet ga ik niet ook nog eens voorkauwen

[Jazzcrime]

ik heb de smaak enigsinds te pakken gekregen, mijn try catch block werkt als een trein ik heb wel het script weer iets aangepast het ziet er nu als volgt uit:

try
{
int jaar=Integer.parseInt(jTextField1.getText());

boolean isSchrikkeljaar;

//input

if(jaar % 4 == 0)
{
if((jaar % 100 == 0) && (jaar % 400 != 0))
{
isSchrikkeljaar = false;
}
else
{
isSchrikkeljaar = true;
}
}
else
{
isSchrikkeljaar = false;
}

//output
if(isSchrikkeljaar)
{
schrikkeljaarlabel.setText ( jaar + " is een schrikkeljaar.");
}
else
{
schrikkeljaarlabel.setText ( jaar + " is geen schrikkeljaar.");
}

} // catch blok

catch (NumberFormatException e)
{ schrikkeljaarlabel.setText("Sorry, \""+jTextField1.getText()+"\" is geen geldig jaartal");


nogmaals bedankt voor je gegeven script als startpunt voor mij!

[Chimera]

Graag gedaan. Het is overigens de bedoeling dat je een try-catch alleen om het stuk zet waarin je die integer probeert te parsen (je zult die integer dat wel buiten het block moeten definieren) maar het is goed dat je er zelf uitgekomen bent

[Klaas B.]

PHP-code:

int jaar=Integer.parseInt(jTextField1.getText());  
               {  schrikkeljaarlabel.setText("Sorry, \""+jTextField1.getText()+"\" is geen geldig jaartal"); 


Niet erg netjes, tweemaal dezelfde methode gebruiken om een waarde te verkrijgen. Je kunt beter gewoon je int gebruiken, dan weer opnieuw je tekstveld uit te lezen.

[Chimera]

Klaas B. schreef op 15-08-2007 @ 03:08 :

Niet erg netjes, tweemaal dezelfde methode gebruiken om een waarde te verkrijgen. Je kunt beter gewoon je int gebruiken, dan weer opnieuw je tekstveld uit te lezen.

Dat kan dus niet, want die integer wordt niet gevuld als er een exception gegooid wordt omdat het geen parsebare integer is

[Klaas B.]

Chimera schreef op 15-08-2007 @ 12:47 :
Dat kan dus niet, want die integer wordt niet gevuld als er een exception gegooid wordt omdat het geen parsebare integer is

Oeps oeps oeps, blunder, hehe.

Sorry Jazzcrime, dat was een domme opmerking. En bedankt, Chimera.

Nog een paar kanttekeningen. Als je een GUI om iets heen moet bouwen, bestaat er een grote kans dat je wat hebt aan het model view controller patroon.

Daarbij valt er ook nog het een en ander te refactoren aan je code.

if(jaar % 4 == 0) {
	if((jaar % 100 == 0) && (jaar % 400 != 0)) {
		isSchrikkeljaar = false;
	} else {
		isSchrikkeljaar = true;
	}
} else {
	isSchrikkeljaar = false;
}

Overtuig jezelf ervan dat dit hetzelfde is als:

isSchrikkeljaar = (jaar % 4 == 0) && ((jaar % 100 != 0) || (jaar % 400 == 0));

In je if-else stel je dat een jaar hoe dan ook deelbaar moet zijn met 4 om in ieder geval een schikkeljaar te kunnen zijn. Het eerste gedeelte van de boolse expressie van de gerefactorde assign vangt dit op. Indien dit al niet waar is, wordt de rest van de expressie niet ge-evalueerd en bevat isSchikkeljaar meteen false (dit noemt men ook wel shortcircuit/lazy evaluation dmv assymetrische binaire operatoren (in dit geval de &&), dit itt bitwise binaire operatoren waarbij beide operanden ge-evalueerd worden).

Volgens je code geldt vervolgens dat het niet een schikkeljaar betreft als jaar deelbaar is door 100 of deelbaar is door 400. Dit concludeer je door negatie toe te passen op (jaar % 100 == 0) && (jaar % 400 != 0), immers moest dit gelden om NIET een schrikkeljaar te zijn. Negatie toepassen levert dan zoiets op als NIET NIET schrikkeljaar (de morgan's law of double negation), ofwel, WEL een schrikkeljaar.

Er volgt dan dat bovenstaande predicaat opgaat voor of iets een schikkeljaar is, alleen compacter en imho leesbaarder , maar dat laatste is discutabel. Het laat iig zien hoe je ook overweg kan met boolse expressies ipv hardcoded true/false assignen.

Chimera schreef op 13-08-2007 @ 16:26 :
Lees even een stukje over try-catch blokken en het afvangen van exceptions. Er moet een try-catch blok om dat inlezen van die int (Integer.parseInt) maar hoe dat moet ga ik niet ook nog eens voorkauwen

Hoewel ik het eens met je ben dat het in deze situatie voor de TS misschien het makkelijkste is, is het qua programmeren wel een slechte gewoonte.

Het zit hem al in de naam "exception". Exceptions horen niet voor te komen. Het is dus netter om de input eerst te valideren, voordat je gaat parsen. Dit kun je o.a. doen met regular expressions.

Zo is dat eigenlijk met alles. Ik kijk ook altijd eerst of een bestand bestaat, voordat ik het probeer te openen in plaats van er een try-catch omheen te kwakken om dat maar af te vangen (ik zet hem er vaak wel omheen bij file i/o, maar het gaat om het idee).

Try-catch gebruik ik voor de situaties waar ik geen controle over heb, zoals server timeouts en security exceptions waar je niet altijd op kunt testen.

Voorkomen is altijd beter dan genezen

[Chimera]

******** schreef op 24-08-2007 @ 08:57 :
Het zit hem al in de naam "exception". Exceptions horen niet voor te komen. Het is dus netter om de input eerst te valideren, voordat je gaat parsen. Dit kun je o.a. doen met regular expressions.

Het is onzin dat exceptions niet voor horen te komen. Het zijn exceptions, een onverwachte status. Foute invoer is een exception, een file die niet bestaat ook, etc. Exception != error.

En wat betreft files openen e.d. in Java: je zult wel MOETEN omdat Java je gewoon dwingt een exception af te vangen of hem anders door te geven, en vrijwel alle file operaties kunnen een IOException opleveren.

Chimera schreef op 24-08-2007 @ 11:01 :
1. Het is onzin dat exceptions niet voor horen te komen. Het zijn exceptions, een onverwachte status. Foute invoer is een exception, een file die niet bestaat ook, etc. Exception != error.

2. En wat betreft files openen e.d. in Java: je zult wel MOETEN omdat Java je gewoon dwingt een exception af te vangen of hem anders door te geven, en vrijwel alle file operaties kunnen een IOException opleveren.

1. Ik zie foute invoer niet als een exception, maar als slecht ontwerp. In een goed ontworpen programma kun je niet eens foute invoer geven.

2. Alleen maar omdat je een exception moet afvangen by design, betekent nog niet dat je hem niet kunt voorkomen.

[Chimera]

******** schreef op 24-08-2007 @ 11:44 :
1. Ik zie foute invoer niet als een exception, maar als slecht ontwerp. In een goed ontworpen programma kun je niet eens foute invoer geven.

2. Alleen maar omdat je een exception moet afvangen by design, betekent nog niet dat je hem niet kunt voorkomen.

1. Je bedoelt dat je het controleren van invoer door deze af te laten handelen door middel van een exception slecht ontwerp vindt. Foute invoer krijg je toch.

In veel systemen is het control dat de invoer ontvangt de control die die onvoer omzet in valide data. In veel gevallen weet zo'n control niet wat er moet gebeuren als de invoer fout is, daarom wordt een exception gegeven. Die control doet z'n ding, en als er door de gebruiker een fout gemaakt wordt, moet het overkoepelende systeem dat probleem maar op gaan lossen. Door dat lokaal af te vangen verminder je de herbruikbaarheid van een control. In een systeem dat er vanuit gaat dat een control bij foute invoer een exception gooit (en dat is dus normaal, veel java/.net content management systemen werken gewoon zo), is het juist fout om geen exception te gooien als de gebruiker iets verkeerd doet.

Dus het is leuk en aardig dat je het 'fout ontwerp' vind, maar in het echte leven is het gewoon gangbaar dat een onderdeel van het systeem een exception gooit bij foute invoer. Dat kan dan op de juiste plek gewoon afgehandeld worden.

2 Je wordt niet voor niets gedwongen die exceptions af te vangen, dat is met een reden gedaan.

Chimera schreef op 24-08-2007 @ 12:22 :
1. Je bedoelt dat je het controleren van invoer door deze af te laten handelen door middel van een exception slecht ontwerp vindt.

2. In veel systemen is het control dat de invoer ontvangt de control die die onvoer omzet in valide data.
..
Door dat lokaal af te vangen verminder je de herbruikbaarheid van een control.

3. Dus het is leuk en aardig dat je het 'fout ontwerp' vind, maar in het echte leven is het gewoon gangbaar dat een onderdeel van het systeem een exception gooit bij foute invoer. Dat kan dan op de juiste plek gewoon afgehandeld worden.

4. Je wordt niet voor niets gedwongen die exceptions af te vangen, dat is met een reden gedaan.

1. Ja.

2. Dat hoeft niet. Een control kan ook flexibel zijn. In het voorbeeld van dit topic, zou je een control zo kunnen maken, dat het door middel van een extra property die je zet, alleen positieve numerieke invoer toelaat.

Control niet minder herbruikbaar - juist flexibeler - en het probleem van je int parse in 1 keer opgelost (voor de zekerheid zou je nog een maxlength kunnen zetten, maar je begrijpt wat ik bedoel).

3. Het echte leven? Bij mijn vorige baan was het zelfs verplicht om invoer te valideren, voordat het aan het systeem werd aangeboden.

Met .NET raden ze ook aan om het gebruik van exception handling te minimaliseren, omdat het nogal een performance impact heeft. Het throwen en catchen van exceptions kost namelijk nogal wat memory in .NET.

4. Uiteraard, maar dat komt omdat er bij file i/o nog tientallen andere dingen mis kunnen gaan. Dat betekent niet dat je het maar quick and dirty voor alles moet gaan gebruiken.

Exceptions zijn zoals de naam al zegt uitzonderingen, en als je weet hoe exceptions afgehandeld worden weet je dat ze vrij duur zijn. Voorkomen is altijd beter dan genezen, en als je weet hoe je een exception throw moet voorkomen moet je dit ook zeker doen: sterker nog, anders komt onze software engineer professor langs om je er van langs te geven.

Met design by contract kun je dit al goed voorkomen. Dit is gebaseerd op het idee van de Hoare triple, i.e. (preconditie, code, postconditie). Indien je je aan de preconditie houdt van een methode, dan kan deze garanderen dat hij je niet een exception tegen je kop aan zal gooien. In alle andere gevallen -i.e. uitzonderingen- belooft het niets, en kan het dus heel goed een exception ook gooien (het is immers dan een uitzonderingsgeval, waar je ook de exception voor gebruikt).

In het geval van Integer.parseInt(String str) zou de preconditie misschien gespecificeerd kunnen zijn als "voor elke i >= 0 && i < str.length moet gelden dat (int) str.charAt(i) >= 0 && (int) str.charAt(i) <= 9" voor positieve string integers. Een voorbeeldje dus van dat je het dus wel relatief eenvoudig kan controleren, maar je moet ook de afweging maken tussen wanneer dat wat minder goed mogelijk is. Indien je code er significant complexer van wordt bijvoorbeeld, kan de afweging van het eerst controlleren v.s. de exception voor lief nemen best wel moeilijk zijn. Het hangt dan even af van de situatie.

Verder moet er nog onderscheid gemaakt worden tussen 2 soorten exceptions, namelijk runtime exceptions en compiletime exceptions. Exceptions die je hoe dan ook moet afvangen zijn compile-time exceptions, omdat deze dmv compiler assistance ook afgedwongen worden. Met andere woorden, je code zal anders niet compileren. Runtime exceptions daarentegen zijn wat meer flexibel en vereisen niet dat je het per definitie afvangt, en dat is gedaan omdat ze tijdens runtime pas kunnen optreden en eventueel al voorkomen kunnen worden wanneer waarden bekend zijn. Integer.parseInt is hier een goed voorbeeld van, die een NumberFormatException gooit die ook een RuntimeException is, i.e. new NumberFormatException() instanceof RuntimeException.

Je kan deze dus prima voorkomen, maar ik zou het niet doen als het gewoon snel af moet, wat vaak in het echte leven moet