13. november 2005 - 15:06Der er
19 kommentarer og 1 løsning
Må argumenter til constructor være null?
Titlen på spørgsmålet er måske lidt misvisende. Men jeg kunne godt tænke mig, at få jeres holdning om, hvorvidt det normalt er ok, at kalde en constructor (som man ikke kender) med defaultværdier som alle argumenter. Med defaultværdier mener jeg null for alle objekter, 0 for int, false for boolean osv osv...
Det lyder måske som et mærkeligt spørgsmål, men jeg er igang med at lave et framework som automatisk skal instanciere nogle af "brugerens" klasser. Og hvis disse klasser ikke har en default constructor, vil jeg gerne lave en "nødløsning". Derfor spørgsmålet: hvis det nu er en klasse DU har lavet. Har du så taget højde for muligheden at argumenterne til din constructor kan være null? Og hvis ikke, vil du så mene at det er OK, at du får en nullpointer exception i det tilfælde?
De 200 point bliver delt ud på alle der har en relevant holdning til spørgsmålet!
Jah. Hvis constructoren ikke kan klare en null-værdi skal den give en exception. Enten IllegalArgumentException (pænest) men evt. også null-pointer exception.
Men hvis det er rimeligt at værdier kan være null, 0, "" etc., vil jeg udstyre klassen med flere constructors med færre argumenter. Evt en parameterløs.
Normalt tager jeg ikke højde for null værdier i min constructor. Hvis jeg laver en constructor der tager nogle argumenter med, er det fordi jeg skal bruge disse argumenter. Og hvis de er null, vil jeg smide en exception.
Jeg vil mange gange også lave muligheden for, som Erik skriver, at lave overloads på min constructors.
Super! Tak for svarene indtil videre. For lige at komme med lidt mere insider-viden:
Det er et persistensframework (ala Hibernate) jeg er ved at lave. Så efter instancen er blevet oprettet (med default constructor eller ej) bliver samtlige fieldværdier i objektet sat med reflection / get-set metoder.
Set i lyset af det, vil jeg jo selv mene at det er ok, at kalde constructoren med null-værdier, da de værdier jeg oftest kræver i en constructor er værdier til fields der ikke kan "tåle" at være null.
Så vidt jeg husker, så kræver Hibernate, at man har en default tom constructor. Det samme kunne du jo kræve af klasser der bruges i dit framework. Jeg synes stadig ikke det er pænt "bare" at kalde en constructor med null værdier. Der kan være mange forskellige grunde til at en klasse ikke kan håndtere dette.
Hvis du opretter instanser med null værdier i constructoren, skal du jo i hvert fald kunne håndtere de eventuelle exceptions der bliver smidt. Og hvad vil du gøre, hvis der bliver smidt en null-pointer? Ignorere den? (I så fald vil klassen muligvis ikke virke korrekt)
Det er rigtigt! Jeg kunne sagtens kræve at man har en default tom constructor. Og det har jeg faktisk også gjort indtil videre. Men grunden til at jeg startede denne tråd, var jo netop at jeg ville høre om jeg kunne undgå dette krav, og så stadig være ret sikker på ikke at være skyld i nogle drastiske fejl i programmer :)
Og det er jo også den potentielle nullpointer execption du omtaler, jeg ikke ved hvad jeg skal gøre ved. Netop derfor har jeg ikke bare implementeret denne feature (eller bug ;) ).
Med en default tom constructor tvinger du vedkommende der laver denne persistensklasse til at tage højde for at parametrerne ikke nødvendigvis har en værdi fra starten af.
Men i mine øjne er en constructor der bliver kaldt med null værdier ikke mere værd, end en tom constructor.
Ja, langt de fleste persistens frameworks kræver en default constructor. Dog er jeg stødt på XStream, som ikke gør. XStream er dog "kun" et XML-seriliseringsværktøj, og ikke til relationelle databaser.
mikkelbm: Du kan godt have ret i, at en constructor der bliver kaldt med null-værdier ikke er mere værd end en tom constructor. Men hvis nu et system med 1000+ klasser skal til at skifte persistens framework. Så vil det da være en umulig opgave at forlange at disse klasser skal tilføjes en default constructor (blot det at chekce om de har en, ville være uoverskueligt).
Det er netop derfor, jeg gerne vil stille så få krav til brugerne som muligt! Fordi det skal være simpelt og ligetil, at skifte til mit framework.
Men pointen er noteret, og indtil videre er jeg også enig! Jeg lader dog lige spørgsmålet stå, hvis nu der skulle være flere der har en mening...
Jah, okay. Hvis det er eksisterende klasser du vil ha' til at skifte, så kan det godt være det bliver en svær opgave. Men hvis du i dokumentationen skriver klart og tydeligt, at disse klasser vil blive oprettet med null-værdier kan det måske gå an (du kan i hvert fald fralægge dig noget ansvar så :)). Men gør så også opmærksom på, at det er at foretrække, at der er en default tom constructor.
Hvis det er eksisterende klasser man vil persistere. Hvad enten man fra frameworkets side enten har kravet om at der skal være en tom constructor eller at der skal tages højde for at alle argumenter kan være null, så vil der være meget arbejde med at lave om de 1000+ klasser om.
Jeg tvivler på at ret mange udviklere som default tager højde for at argumenterne i deres constructor kan være null, da argumenterne sikkert spiller en vigtig rolle i initialiseringen af objektet, og derfor ikke må være null.
Jeg tror derimod at der er større chance for at udviklere har lavet en tom constructor.
Derfor er kravet om en tom constructor nok det bedste, da det ville kræve færre modifikationer.
Krav om constructor uden argumenter er normalt fordi det er en del af bean konvention & serializable.
Om kald af constructor med null (eller en set metode med null) er acceptabelt og hvorvidt en default constructor f.eks. skal sætte String field til "" eller null må være op til projektet.
nej tak - jeg havde jo kun en lille bemaerkning om yhvor kravet om en constructor uden argumenter oprindeligt kommer fra
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
