Java har jo klassen Object som altid er øverst i hierakiet. Derfor kan bare bare bruge Object som parametertype, så kan metoden kaldes med alle typer af objekter. Dog skal objektet så downcastes til en specifik type før du kan anvende de metoder objektet har (bortset fra equals, toString osv som jo ligger i Object klassen) Men det er jo lidt besværligt at skulle caste så meget, så det er nok derfor at templates kommer med i den næste version af Java
Simple typer (int, float osv) er altid by value. Objekter (inklusiv arrays) er altid by reference. Hvis man har behov for at kalde en metode med en kopi af et objekt, ligger der i Object klassen metoden clone() til selvsamme formål. Men der skal du nok lige læse i javadoc'en for den metode, da der er nogle ting man lige skal være opmærksom på - eksempelvis skal klassen implementere Clonable interfacet før man kan clone.
Objekter er strengt taget reference by value. I det fleste tilfælde er forskellen ikke stor. Men man kan kun ændre på objektet - man kan ikke udskifte objektet.
->Arne.. Jeg tror ikke at du forstod mit sidste spørgsmål korrekt.. Det jeg mente var om man kunne opnå det samme ved hjælp af at benytte interfaces, som man jo kan med multipel arv...
Ang interfaces for multipel arv: Jeg opfatter spørgsmålet på en anden måde end Arne. Og jo interfaces er en måde at opnå multipel arv i Java, idet en klasse her kan implementere et interface og derved få adgang til metoderne i interfacet, altså kan en klasse få adgang til mere end den ene klasse det er muligt at nedarve fra.
Man kan dog godt simulere multipel arv i Java vha inner classes: class Ydre extends Parent1 { private class Indre extends Parent2{ //herfra er adgang til både Parent1 og Parent2 } }
Det jeg mente med at interfaces fungerer som multipel arv er at man kan kommunikere på tværs af systemet mellem objekter som ikke har noget at gøre med hinanden, og på den måde dele funktionalitet fra flere objekter. Jeg er udemærked klar over at funktionaliteten skal være implemteret i begge objekter og har initialiseringen i det fælles interface.. For mig ser jeg den samme funktionalitet som eksisterer i multipel arv.. Jeg kan i hvert fald opnå det samme langt hen ad vejen..
Men der er gode grunde til at Java (og C# !) har fjernet multipel implementations arv. Det bliver ofte noget forfærdeligt roderi. Og de tilfælde hvor det er en god løsning i C++ er få.
Ja, det her du ret i Arne, men du kan godt se at du faktisk kan det samme som multipel arv.. Og jo, multipel arv er noget roderi, men det handler jo om at modulere virkeligheden og det er det en styrke når det behøves synes jeg. Men lad det nu ligge.. Mit næste spørgsmål går på om styrke og svagheder ved at alting er objekter i Java, og den GB collecter som jo tager sig af oprydningen, og forhindre en i at lave realtime applikationer i Java.. Hvad er jeres mening om den sag?
Jeg tror du er den eneste, der mener at man "faktisk kan det samme som multipel arv" når man bruger interfaces. Det kan man ikke. Det har Arne tydeligt demonstreret. Det er lidt skuffende du ikke kan læse det ud af hans indlæg. Hvad er det du ikke forstår?
Garbage collection undgår de fleste memory leaks, som er en plage for de fleste større C/C++ applikationer. Jeg tror at de fleste er enige om at GC er vejen frem. C# bruger også GC. Jeg tror at det bliver standard for alle nye general purpose sprog fremover.
Det er ikke godt til real time applikationer. Men det er en niche. Og det vil kræve specielle operativ systemer og speciell sprog at opnå de helt rigtige real time egenskaber.
Det jeg mener er at hvor man arver metoder fra flere klasser ved multipel arv, og på den måde har metoderne fra begge klasser, er som jeg ser det det "samme" om at lave et interface mellen to objekter og instantiere metoderne der, og så implementere metoderne i begge objekter. Altså interfacet fungere nu som en slags samlingstabel ml. de to objketer. Det er en anden måde, ja, - men jeg opnår da det samme. Nu er de pludselig i familie med hinanden. Sådan opfatter jeg det i al fald.. Er det da helt forkert opfattet..?
Jow, og jeg er sikkert også i familie med kongen af Bhutan, hvis vi går langt nok ud. Men det er jo blot ikke det samme som multipel arv. En arving til interface arver en tom skal, som han selv skal fylde ud, og hver arving gør det sikkert på sin egen måde. En arving, der deltager i en multipel arv, får det hele serveret i allerede realiserede metoder.
Der er en verden til forskel.
Men det sjove er jo så at man kan bruge interfaces til noget, og ret beset ikke savner multipel arv.
*S* Ja ja, erik.. Du er skam meget morsom.. Og jeg har aldrig påstået at multipel arv og interfaces er det samme, men kun at man kan opnå det samme som du jo åbenbart også giver mig ret i til sidst.. Når du nu åbenbart er så klog at så vær lige rar at forklarer mig at hvordan Java kompencerer for dets mangel på overloading af operators?
Jeg kan godt sætte pointene op hvis i vil.. Jeg har stadig et par spørgsmå endnu..
Overloading af operators er blot syntaktisk sukker - i Java bruger man bare metoder.
"man kan opnå det samme" - nej, jeg giver dig slet, slet, slet ikke ret i at man kan opnå det samme med interfaces som med multipel arv. Det kan man ikke, og det er det vi forsøger at få dig til at forstå. Igen: hvad er det du ikke forstår i det vi skriver?
Man laver de metoder der er brug for. Ligesom man i C++ overloader de operatorer man har brug for.
Du kunne godt lave en metode "sammenlign". Men man kalder den normalt compareTo - og der er nogen praktiske fordele ved det, da noget kode forventer at den hedder det.
Java blev designet med et formål om at være simpelt. Operator overload røg ud på den konto. Jeg bruger af og til operator overload i C++ og C#. Så jeg ville ikke have noget imod at man tilføjede det til Java i en eller anden form. Men på den anden side er det ikke noget stort problem. Det er ikke så tit at det virkeligt betyder noget for læseligheden af koden (primært når man laver klasser som der kan regnes på: matricer, komplekse tal etc.).
Hm ok, jeg syntes nu ikke der var noget der sprang i øjnene.. Men generelt er der udemærkede Java vs. C++ sider på nettet (og bøger, men i den forbindelse vil jeg fraråde Timothy Budd's Java for C++ Programmers der er en noget rodet fornøjelse)
The C++ preprocessor basically performs an intelligent search and replace all identifiers that have been declared using the #define or #typedef directives.
(det er typedef ikke #typedef)
Java forces programmers to use classes when the functionality of structures and unions is desired.
(det er ikke ligetil at lave en union med en class)
C and C++ have no built-in support for text strings.
(STL strings er altså opfundet)
Ikke fordi at de har nogen speciel betydning for sammenligningen mellem Java og C++, men det gør et lidt sjusket indtryk.
Har lige sat pointene op med 50. Er meget glad for den hjælp her..
En ulempe må vel være at downcaste vil jeg selv mene. Det er jo der Templates har sin styrke. Jeg går ud fra at Templates fungerer som OBJEKT i Java, eller det forkert da?
Nææ, ikke bare exceptions, men også errors som skulle være noget low level noget.. Synes jeg har læst om det et sted, kan bare ikke huske hvor..Hm, måske husker jeg forkert..
Afspejler alvorlige problemer (interne fejl i Java systemet) som normalt ikke forekommer i et kørende Java system
Håndteres ikke under normale omstændigheder
Er ikke underlagt 'catch or specify' princippet
Kastes kun sjældent af vore egne programmer
Eksempler: For dyb rekursion, ikke mere arbejdslager, manglende metode eller felt, instantering af abstrakt klasse
At Error exceptions ikke er underlagt catch or specify princippet betyder at disse exceptions ikke skal specificeres i metoders throws clauses
De sidstnævnte to eksempler på Errors forekommer ikke i 'normale' java programmer, idet de fanges under oversættelsen. Hvis man imidlertid tilgår objekter, som er lagret persistent på disken, eller hvis man via et klassenavn tilgår selv klassen med henblik på instantiering, kan disse fejl opstå
Okay... Jeg siger tak for denne gang og deler nogle point ud...
MVH
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.
Ny bruger
Nybegynder
Opret
Preview
