---

Jeg er rimeligt ny inden for Java så undskyld, hvis det er et
begynderspørgsmål.

Jeg vil lave en klasse der stærkt forsimplet ser således ud:

class PortTrans {
private String TransId = new String();
}

public PortTrans(final String TransId) {
this.TransId = TransId
}

Mit spørgsmål opstår fordi feltet TransId skal være én af følgende for
at være valid: HDLOBL, HDLUDT, HDLAKT osv.

Min frygt er nu at én eller anden kommer til at skrive f.eks. HLDOBL
hvorefter mit objekt er invalidt.

Hvordan kan jeg sikre mig allerede i constructor-kaldet?

Jeg er klar over, at jeg kunne lave en default constructor og en
stribe set-metoder, som kunne validere inputtet og returnere
bool-værdier. Men jeg vil helst undgå, at man overhovedet kan
instantiere min klasse i en invalid tilstand.

Mvh. Tony

---

On 3 Mar 2004 04:20:44 -0800
Vipstjert@yahoo.com (Motacilla Alba) wrote:

> Jeg er rimeligt ny inden for Java så undskyld, hvis det er et
> begynderspørgsmål.
>
> Jeg vil lave en klasse der stærkt forsimplet ser således ud:
>
> class PortTrans {
> private String TransId = new String();
> }
>
> public PortTrans(final String TransId) {
> this.TransId = TransId
> }
>
> Mit spørgsmål opstår fordi feltet TransId skal være én af følgende for
> at være valid: HDLOBL, HDLUDT, HDLAKT osv.
>
> Min frygt er nu at én eller anden kommer til at skrive f.eks. HLDOBL
> hvorefter mit objekt er invalidt.
>
> Hvordan kan jeg sikre mig allerede i constructor-kaldet?

Smid en exception

public PortTrans( final String TransId)throws Exception{
if( TransId is not valid ){
throw new Exception("Bad value for TransId: " + TransId);
}
}

>
> Jeg er klar over, at jeg kunne lave en default constructor og en
> stribe set-metoder, som kunne validere inputtet og returnere
> bool-værdier. Men jeg vil helst undgå, at man overhovedet kan
> instantiere min klasse i en invalid tilstand.

Velbekomme.

> Mvh. Tony

vh. ld

---

Lars Dam wrote:
> Smid en exception
>
> public PortTrans( final String TransId)throws Exception{
> if( TransId is not valid ){
> throw new Exception("Bad value for TransId: " + TransId);
> }
> }

Det er en programmørfejl hvis der gives et ugyldigt TransId som argument, så
jeg vil foretrække en unchecked exception såsom java.lang.IllegalArgument
exception.

Alternativt kan man gøre brug af en enumeration:

public final class TransId implements java.io.Serializable {
public static final TransId HDLOBL = new TransId("HDLOBL");
public static final TransId HDLUDT = new TransId("HDLUDT");
public static final TransId HDLAKT = new TransId("HDLAKT");

private String id;

private TransId(String id) { this.id = id; }

public String getValue() {
return id;
}
}

Så skal PortTrans-klassen se således ud:

public PortTrans {
private TransId transId;

public PortTrans(TransId transId) {
this.transId = transId;
}

...
}

Klienterne kan bruge den på følgende måde:

PortTrans portTrans = new PortTrans(TransId.HDLAKT);
....

PS: Bemærk det er kutyme i Java-verdenen at variable starter med et lille
begyndelsesbogstav.

--
Jonas Kongslund

---

In article <20040303132738.13f61563.larsdam@post2.tele.dk>, Lars Dam
<larsdam@post2.tele.dk> wrote:

> On 3 Mar 2004 04:20:44 -0800
> Vipstjert@yahoo.com (Motacilla Alba) wrote:
>
> > Jeg er rimeligt ny inden for Java så undskyld, hvis det er et
> > begynderspørgsmål.
> >
> > Jeg vil lave en klasse der stærkt forsimplet ser således ud:
> >
> > class PortTrans {
> > private String TransId = new String();
> > }
> >
> > public PortTrans(final String TransId) {
> > this.TransId = TransId
> > }
> >
> > Mit spørgsmål opstår fordi feltet TransId skal være én af følgende for
> > at være valid: HDLOBL, HDLUDT, HDLAKT osv.
> >
> > Min frygt er nu at én eller anden kommer til at skrive f.eks. HLDOBL
> > hvorefter mit objekt er invalidt.
> >
> > Hvordan kan jeg sikre mig allerede i constructor-kaldet?
>
> Smid en exception
>
> public PortTrans( final String TransId)throws Exception{
> if( TransId is not valid ){
> throw new Exception("Bad value for TransId: " + TransId);
> }
> }
>
> >
> > Jeg er klar over, at jeg kunne lave en default constructor og en
> > stribe set-metoder, som kunne validere inputtet og returnere
> > bool-værdier. Men jeg vil helst undgå, at man overhovedet kan
> > instantiere min klasse i en invalid tilstand.
>
> Velbekomme.
>
> > Mvh. Tony
>
> vh. ld

Eller benytte det nye assert keyword:

public PortTrans( final String TransId)throws Exception{
assert transid valid : "Transid not vailid";
}

---

Mike wrote:

> Eller benytte det nye assert keyword:
>
> public PortTrans( final String TransId)throws Exception{
> assert transid valid : "Transid not vailid";
> }

En assert er en ret voldsom fejlmelding (den giver en fejldialogboks og
trækker programmet ned), og kan ikke køre i ældre VM'er end 1.3.

Hvis der ikke var disse bagudkompabilitetsproblemer var assert og java
1.5 meget mere interessant for os.
--
Thorbjoern Ravn Andersen "...plus...Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:
> Hvis der ikke var disse bagudkompabilitetsproblemer var assert og java
> 1.5 meget mere interessant for os.

Måske er problemet ikke så stort igen. Jeg faldt lige over denne nyhed:

Retroweaver: Compile 1.5 source to 1.4 bytecode
<http://www.theserverside.com/news/thread.tss?thread_id=24452>

Retroweaver is a bytecode weaver that enables you to take advantage of the
new Java 1.5 language features, while still retaining total binary
compatability with 1.4 virtual machines. Retroweaver operates by
transforming Java class files compiled by a 1.5 compiler into version 1.4
class files which can then be run on any 1.4 virtual machine.

--
Jonas Kongslund

---

Mike wrote:
> Eller benytte det nye assert keyword:
>
> public PortTrans( final String TransId)throws Exception{
> assert transid valid : "Transid not vailid";
> }

Hvis du spørger Sun, så bør man ikke bruge assert til at verificere
præbetingelserne i en public metode eller konstruktør. Se
<http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html#usage>.

Jeg vil meget nødig have en J2EE applikationsserver kørende, hvor nogle af
de idriftsatte komponenter udøver denne strategi. I tilfælde af
assertionfejl så lukkes VM'en ned, hvilket ikke just er så godt for
driftsstabiliteten. Man kan selvfølgelig fange den konkrete AssertionError,
men så begynder det virkeligt at blive grimt og hele ideen med assertions
ryger fløjten.

Udover det så skal man explicit enable assertions ved opstart af den
virtuelle maskine. Er de ikke enablet så er der ikke længere noget tjek,
hvilket kan have fatale konsekvenser.

--
Jonas Kongslund