Danske Spil dropper Flash - skifter tilbage til HTML-site

Fordelene ved et site udviklet i Flash udeblev, og med en stadigt stigende andel af iOS-brugere uden Flash, besluttede Danske Spil at lave et nyt site i HTML.

For godt et års tid siden blev danskespil.dk lanceret i en ny, flot og farverig Flash-udgave. Men levetiden blev kort, for tirsdag gik et helt nyt site i luften - denne gang baseret på et HTML-framework.

»Vi konkluderede, at vi ikke fik de fordele, vi havde forventet fra Adobe Flex, der er en objektorienteret udgave af Flash. Forventningen var, at vi kunne genbruge en lang række klasser og dermed spare udviklingsressourcer og få en hurtig time to market. Samtidig er mange af vores spil udviklet i Flash, så på den baggrund gav Flash-Flex god mening,« siger it-udviklingschef Thomas Klindt fra Danske Spil til Version2.

Selv om et af argumenterne for at skifte teknologi var en hurtigere udviklingstid, endte Danske Spil med at dumpe Adobe Flex netop på grund af hastigheden:

»Det var simpelthen for langsomt at udvikle i,« siger Thomas Klindt.

Samtidig var erkendelsen hos Danske Spil også, at brugeroplevelsen blev ringere i Flash-sitet.

»Som kunde gik det simpelthen for langsomt. At loade de par megabyte, sitet fyldte, var ikke det største problem, men at rendere og behandle al den Flash sugede for meget CPU,« siger Thomas Klindt.

Endelig sagde brugerstatistikkerne også, at en stadig stigende andel af brugerne kom ind på sitet fra en enhed med iOS-styresystemet, der ikke understøtter Flash. I dag kommer 61,9 procent af mobil-trafikken på danskespil.dk enten fra iPhone eller fra iPad.

»Vi er jo til for brugerne, så vi besluttede at skifte teknologi,« var Thomas Klindts konklusion.

På tre-fire måneder har 8-10 medarbejdere i Danske Spil derfor udviklet et nyt site baseret på CMS'et OpenCMS, der benytter Java-teknologi.

»Vi har kun haft eksterne konsulenter inde over, når der var særlige problemstillinger, vi ikke kunne løse på stående fod. For eksempel har vi brugt et freelance-bureau til at finde en jQuery-specialist, der kunne hjælpe os med den del,« siger Thomas Klindt.

Hvad har været det sværeste i processen?

»Hele kompleksiteten omkring pengeflow og kontoflow. Man kan spille for rigtige penge på danskespil.dk, og derfor skal sikkerhedsniveauet være lige så højt som i en netbank. Så vi har brugt tæt på halvdelen af udviklingstiden på sikkerhedstest og performance-test. Det er afgørende for os, at kunderne har tillid os,« siger Thomas Klindt.

I forbindelse med migreringen tirsdag fra Flash til HTML blev brugerne mødt af en certifikatfejl på www.danskespil.dk. Og det ærgrer Thomas Klindt.

»Det er en længere historie, og naturligvis var det meget uheldigt. For at snyde browseren til bedre load-tider har vi lagt forskellige elementer på flere sub-sites, og der var så noget, der pegede det gale sted hen. På grund af Diginotar-sagen tidligere i år, så har certifikatudstederne strammet procedurerne, og derfor tager det længere tid end tidligere at få fejl rettet,« siger Thomas Klindt.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Martin Andersen

Hmm, jeg ved ikke rigtig hvordan jeg skal starte min kommentar her, men som fuldtids Flexudvikler, bliver jeg lidt stødt, da jeg jo selv synes det er en "god" platform at udvikle på, og jeg synes selv at jeg er forholdsvis teknologi agnostisk. Jeg kunne godt tænke mig at Thomas Klindt uddybede lidt hvorfor de mener udviklingstiden er langsommere, da jeg personligt synes at Flex SDK'et har abstraheret mange trivialiter væk, som eksisterer i HTML/Javascript. Jeg har dog forståelse for hvis det er indlæringkurven, som har knækket udviklingstiden, men sådan er det ikke beskrevet i artiklen. Så er der selve diskussionen om afviklingen af Flash, her synes jeg at Adobe siden Flash Player 10.1* har fået optimeret rigtig meget på deres runtime. Desuden har udviklere/designere tendens til at lave mere animation på en side med flash en på en side uden, hvilket selvfølgelig giver mere rendering. Men en almindelig HTML side skal jo også renderes. *Jeg sidder selv og er udvikler på en portal som har omkring 50.000 - 60.000 månedlige hr og fru danmark besøgende, hvor jeg kan se at over 90% har FP 10.1 eller højere. Dog skal de har ret i iOS problematikken, men ret skal være ret :) Jeg ser frem til Thomas Klindt's kommentar, måske kunne han eller jeg lære noget ;)

MVH Martin Andersen

  • 2
  • 7
#4 Torben Mogensen Blogger

Forventningen var, at vi kunne genbruge en lang række klasser og dermed spare udviklingsressourcer

Det er en udbredt misforståelse, at brug af objektorienterede sprog automatisk medfører øget genbrug af kode.

For det første sker den slags ikke automatisk, og for det andet er den objektorienterede struktur ikke specielt egnet til genbrug sammenlignet med f.eks. generiske (polymorfe) funktioner, typeklasser (interfaces) og de klare grænseflader mellem komponenter, som begrænsning af sideeffekter medfører.

I min erfaring er stort set det eneste genbrug, man finder i OO sprog, genbrug af biblioteksfunktioner, der omhyggeligt er skrevet med genbrug i sigte. Og disse udnytter i lige så høj grad (eller højere) polymorfi (generics, templates) og interfaces/typeklasser som objektorientering.

  • 3
  • 2
#5 Jesper Hitch

at Danske Spil overhovedet kunne finde på at udvikle hele deres site med Flash. Det må være nogen som har røde ørere over i det hele taget at have taget en sådan beslutning. Personligt mener jeg at de gik fra en rigtigt velfungerende site til noget meget langsomt og forvirrende l.... som for mit vedkommende fik mig til at holde mig væk fra at spille online på deres site.

  • 10
  • 0
#7 Martin Andersen

Jeg giver jer alle fuldt ud ret i, at det er da ikke den mest hensigtsmæssige bruger oplevelse med plugins. Dog synes jeg at folk som bare ønsker død over Flash fordi nogle udviklere har lavet nogle trælse reklamer, skal gå efter at hade udviklerne :)

Men så vel som mange synes at Apple nu har været med til at drive HTML5 frem, hvilket jeg ikke synes de har. Så er det jo faktisk Adobe som med Flash har været med til at fremdrive mulighederne for hvad der er muligt på nettet.

Det ser også mere og mere ud til at Adobe i fremtiden vil gøre så man kan compile Flash->HTML/CSS/Javascript, men Flash platformen har dog desværre bare stadig et større API end HTML5, som slet ikke er en standard endnu. Yderligere står det alle browser udviklere åbent at implementere deres egen Flash fortolker, da swf specifikationen er åben.

Mit argument er blot at jeg ikke bryder mig specielt meget om at skrive javascript, dels pga. sproget og dels pga. IDE'erne dertil. Det er nok heller ikke for sjovt at google arbejder på Dart eller lavede Google webtoolkit i sin tid.

  • 2
  • 3
#8 Flemming Hansen

Husk nu også på at HTML5 og CSS3 mv ikke er bedre end den browser der afvikler det. Flash har i det mindste en ret hurtig opdageringsfrekvens hvorimod vi stadig kæmper med gamle browsere der slet ikke kan HTML5 og CSS3. Sider som Danske Spil skal vel reelt tage lige så meget hensyn til gamle browsere som folk der ikke har flash, så selvom man går tilbage til HTML skal man jo stadig arbejde ud fra laveste fællesnævner.

Flash eller ej er en induviduel vurdering fra opgave til opgave dem der bare råber død over flash er enten Apple fanboys og/eller folk der ikke rigtig ved hvad de snakker om.

Og så husk også at Java er et plugin. God fornøjelse med din webbank mv.

  • 2
  • 2
#9 Flemming Frandsen

Flash har i det mindste en ret hurtig opdageringsfrekvens hvorimod vi stadig kæmper med gamle browsere der slet ikke kan HTML5 og CSS3.

Pladder! Alle der kører en gammel affaldsbrowser (læs: IE) kan nemt opgradere til Chrome, Firefox, Safari eller Opera og modtage masser af rettidige opdateringer.

Sammenlignet med Chrome er Flash abandonware.

  • 7
  • 2
#11 Flemming Frandsen

Der har nu aldrig været en enkelt standard som alle browsere levede op til, w3c standarderne er tættere på at være en formalisering af de eksisterende måder at gøre tingene på.

Det ville da være rart hvis de vendor-specifikke features kunne blive standardiseret noget hurtigere, men jeg vil meget hellere have et par browser specifikke CSS styles end jeg vil jeg plugins.

  • 2
  • 1
#13 Karsten Vestergaard

Stop nu det der "Død over Flash" snak. Det udstiller bare manglende forståelse for, hvilke opgaver teknologierne varetager. HTML5 er, i sin seneste version, blevet i stand til at tage ansvaret for en stor del af de opgaver, som Flash har måtte lave for den hidtil - det er noget af det bedste der er sket i lang tid.

Flash vil dog stadig være der, til at gøre alle de ting, du ikke effektivt kan med HTML5, canvas og JavaScript. Deres skrabespil, derinde ser f.eks. stadig ud til at være Flash-film, så (uden at have testet for om der er en erstatning) vil jeg mene at der ikke sker noget på min iPad, når mønterne brænder i min lomme.

Der er stor forskel på nyttelæsning og nydelseslæsning når det gælder internettet, og langt de fleste sites, der fokuserer på nyttelæsning skal og bør laves i HTML. De sites, der skal ramme følelser og give oplevelser har dog, med den seneste version af Flash Playeren, sat nye standarder for, hvad vi kan forvente af internettet.

Det er en stor fejl, indledningsvis, at basere et helt website på Flash - Flash er en plug-in (i browserøjemed). Det er en stor fordel at bruge Flash til at højne kvaliteten af et website til muligheder, som HTML5 ikke kan levere ... endnu.

At de synes det er bøvlet, fortæller måske mere om udviklerne end teknologien. Erfarne Flex udvikler vil nok mene at det nye system Danske Spil har valgt er mere bøvlet - det er meget bundet op af kvalifikationer og erfaring.

Summasummarum. Det er en god idé at rykke selve sitet ind i et HTML miljø, og det er en dårlig idé at rykke den kreative tidsalder 10 år tilbage for enhver pris, fordi man skal tilgodese bruger der har taget et bevidst fravalg. HTML5 er det eneste fornuftige valg til at præsentere grundlæggende information på nettet ... det var HTML4 også før.

P.S: Det er egentlig også en dårlig idé at blive ved med at rende rundt og synes at man er det eneste rigtige, som alle skal rette sig efter, bare fordi man bruger en iPad ... mange sites vil i fremtiden måske finde en handicap parkering til de systemer, der ikke tillader de hurtigløbende teknologier.

  • 4
  • 2
#16 Thue Kristensen

Flash vil dog stadig være der, til at gøre alle de ting, du ikke effektivt kan med HTML5, canvas og JavaScript. Deres skrabespil, derinde ser f.eks. stadig ud til at være Flash-film, så (uden at have testet for om der er en erstatning) vil jeg mene at der ikke sker noget på min iPad, når mønterne brænder i min lomme.

Jeg er helt enig i, at der er meget man ikke elegant kan lave i HTML. Mit problem er nærmere, at Flash ikke er en åben standard. Se for eksempel licens-betingelserne for at bruge flash: http://en.wikipedia.org/wiki/Gnash#Adobe_Flash_Player_End_User_License_A... :

One problem for the project is the difficulty of finding developers. The current developers have never installed Adobe's Flash player, because they fear that anyone who has ever installed the Adobe Flash Player has at the same time accepted an agreement not to modify, reverse engineer or develop a competing Flash player. Therefore, the Gnash project has only about 6 active developers.

For at sige det simpelt, så er Adobe onde, og vi bør ikke give dem kontrollen med en vigtig del af Internettet.

  • 0
  • 2
#18 Kristian Dalgård

Der er rigtig mange fordele ved at bruge W3C-standarder. Responsive design, progressive enhancement, accessibility, micro-data osv. osv. er alle buzz-words, men også vigtige ting, der er gjort muligt ved hjælp af moderne, åbne standarder og IKKE med brug af Flash/Silverlight.

  • 2
  • 1
#20 Karsten Vestergaard

Jeg er helt enig i, at der er meget man ikke elegant kan lave i HTML. Mit problem er nærmere, at Flash ikke er en åben standard. Se for eksempel licens-betingelserne for at bruge flash: http://en.wikipedia.org/wiki/Gnash#Adobe_Flash_Player_End_User_License_A... :

Så vidt jeg kan læse, står der i referencerne til konklusionen at der er en debat, om det kan betragtes som en åben standard. Tamarin projektet er et forsøg på at åbne mest muligt op for platformen, men der er samtidig en del (f.eks. komprimeringsteknologier) der er indlemmet i selve playeren, og det betyder at den ikke bare sprættes op. www.openscreenproject.org er Adobes officielle hjemmeside for deres åbne partnerskab, for dem der vil være med til at lave en fælles platform for interaktivt indhold. Der er jeg sikker på at du også kan læse mere om hvad der er restriktioner på - jeg er ikke så meget inde i det juridiske :-)

Men når det så er sagt, ser jeg egentlig ikke så meget et problem i, at der bruges noget properitært til at styre dele af indholdet. Vi bruger rask væk codec's der er beskyttet, eller hele systemer for at kunne tilgå nettet. Webkit er f.eks. open source, men jeg kan ikke, så vidt jeg er orienteret, bare lave min egen browser og få den godkendt på AppStore. Det betyder reelt, at den åbenhed som skal findes, skal samkøres med Chrome og Safari, før den er en mulighed for bruger af iOS.

Endelig nævner du at Flash kontrollerer en vigtig del af internettet. Jeg tror at folk vælger at bruge den til en vigtig del af nettet - en vigtig del, som HTML5 må og skal overtage, nu hvor den har udviklet sig til at håndtere de opgaver. Der vil dog stadig være behov for at prøve grænser og springe rammerne, og der er der vi har plug-ins der kan komme til undsætning.

Jeg er overbevist om at mange af de seriøse udviklere er glade for at kunne lave en del af de dynamiske sites i jQuery og lignende, og jeg er sikker på at mange annoncører vil trække sig væk fra flash-blockere og over i HTML og JavaScript, der bliver sværere at blokere.

Jeg elsker ALLE mine Apple produkter, men det irriterer mig lidt, at andre har taget et valg for mig, fordi de synes det ikke er godt. Jeg vil egentlig gerne kunne se flash filer på min iPad eller iPhone, men jeg har ikke lov til at vælge selv - ikke fordi det ikke er teknisk muligt, men fordi andres folks forretningsmodeller eller overbevisning skal diktere det for mig.

Resultatet af dette er at vi fjerner meget af det sjove og innovative design på nettet, og nøjes med simplere transitions og partikeleffekter. Værktøjerne til den "frie leg" er ikke udviklet - Adobe er på vej med ting som Edge og Muse, den frie animationsfølelse og skæve indfald kræver meget indsigt i udvikling. Så snart vi kaster os over canvas og laver komplekse applikationer får vi stadig problemer som søgemaskineoptimering, batteritid og varme processorer på nakken - det er jo ikke en mirakelkur, men nok mere en anden måde at gøre tingene på. Prøv at søg på "canvas demo" fra din iPhone eller lignende og prøv at afvikle nogle af dem der ikke er ren HTML og CSS, men dem der arbejder med partikler og canvas ... skriv gerne tilbage, hvordan det gik ;-)

  • 0
  • 0
#21 Thue Kristensen

Men når det så er sagt, ser jeg egentlig ikke så meget et problem i, at der bruges noget properitært til at styre dele af indholdet. Vi bruger rask væk codec's der er beskyttet, eller hele systemer for at kunne tilgå nettet.

Du gør måske, jeg og andre gør ikke hvis jeg kan undgå det. Wikipedia bruger for eksempel kun åbne codec's som Theora og WebM. HTML-standarden er også altid blevet meget strengt efterset, så den ikke indeholdt noget properitært.

Webkit er f.eks. open source, men jeg kan ikke, så vidt jeg er orienteret, bare lave min egen browser og få den godkendt på AppStore. Det betyder reelt, at den åbenhed som skal findes, skal samkøres med Chrome og Safari, før den er en mulighed for bruger af iOS.

Det er da fordi du har pantsat din frihed da du "købte" (nærmere lejede, måske?) en iPhone, hvor Apple har retten til bestemme hvilke programmer kan køre. Og Apple bruger dette mini-monopol til kun at tillade programmer, som ikke konkurrerer med dem. Af samme grund vil alle som er bare en smule interesserede i personlig frihed aldrig købe en iPhone eller en iPad.

  • 2
  • 1
#22 Karsten Vestergaard

Du gør måske, jeg og andre gør ikke hvis jeg kan undgå det. Wikipedia bruger for eksempel kun åbne codec's som Theora og WebM. HTML-standarden er også altid blevet meget strengt efterset, så den ikke indeholdt noget properitært.

Jeg synes skam også det er fint med open source, og vil til enhver tid synes at brugere skal kunne tilgå materiale på den måde som udbyderen har tiltænkt det ... og det er egentlig mere der problemet ligger, synes jeg. Indledningsvis blev der talt om at flere og flere ville tilgå systemet fra iOS - det løses ikke med åbne codec's. Så vidt jeg ved er der stadig implikationer i forhold til H.264, som du selv nævner - men din løsning vil ikke hjælpe iOS brugere, da de ikke kan få en browser med Theora, Ogg eller WebM.

Det er vigtigt at HTML standarden bliver holdt åben, men den er klar over dens begrænsninger (imodsætning til nogle af dens stærkeste fortalere). Det er grunden til at den har object (http://www.w3.org/TR/html-markup/object.html#object) og embed (http://www.w3.org/TR/html-markup/embed.html). En standard bevæger sig sikkert og roligt fremad, og integrerer mange af de tiltag, som plug-ins tidligere har varetaget for den. Hvis der er en der lige pludselig finder ud af at man kan sende dufte ud gennem højtaleren med en plug-in. Skal de så vente på at W3C tager den ind, eller er de nød til at arbejde væk fra browseren i en selvstændig applikation? (der er faktisk nogle, såsom digescent der fifler med den slags :-) )

Jeg synes man skal prøve at løse så mange internetsider som muligt med standarder, men det er vigtigt at browserne (også for deres egen skyld) får en mulighed for at udvide deres funktionalitet. Lige nu, gør de det ene og alene ved at implementere forskellige dele af standarderne og rendere fonte og afstande forskelligt og tilføje små ekstra tags, som kun virker hos dem - det er frustrerende. Derudover kommer versioneringerne af de enkelte browsere, der kun øger kompleksiteten.

Det er da fordi du har pantsat din frihed da du "købte" (nærmere lejede, måske?) en iPhone, hvor Apple har retten til bestemme hvilke programmer kan køre. Og Apple bruger dette mini-monopol til kun at tillade programmer, som ikke konkurrerer med dem. Af samme grund vil alle som er bare en smule interesserede i personlig frihed aldrig købe en iPhone eller en iPad.

Nu har jeg ikke betalt for nogle af dem, så jeg fik ikke pantsat så meget af mig selv - når det så er sagt har jeg også en del Android devices, som bruges ligeså meget. Jeg er i en position, hvor jeg er nød til at forholde mig upartisk, nærmest agnostisk til de forskellige platforme. Vi kan ikke være mere enige om Apples forretningsmetoder, så der vil vi kunne bruge en lang aften, hvor vi bare sidder og nikker af hinanden.

Men når du snakker om personlig frihed, så føler jeg den egentlig kun, at du mener det halvt, da du mener at du skal kunne tilgå alt materiale. Det overlader ikke megen frihed til udbyderen af indholdet. Jeg går ind for at brugere, såvel som udbydere har et valg til at gøre, hvad der tjener deres formål bedst. Jeg prøver lige at dele det lidt op:

Brugeren: Bør have et valg, om hvad der skal være på deres telefon. iOS er håbløs i den sammenhæng. Det er egentlig ligemeget om om du snakker ACC lydfiler i iCloud, film eller musik fra iTunes, programmer fra AppStore. Den enste vej ud til din enhed, går gennem Apple. Mange af dem, der bruger det har gjort et bevidst valg ... men også et bevidst fravalg og må leve med at være under en digital værge, der bestemmer hvad de må bruge den til. Android er mere fri i den henseende, og giver brugeren en del valg for hvad de vil have på deres device.

Udbyderen: Har en lang række af muligheder for at kommunikere. HTML5 er et fantastisk skridt fremad, men HTML5 kører langt fra endnu - i bedste fald kører det efter "godt nok" princippet (se http://www.theopensourcery.com/keepopen/2011/newest-browsers-html5-bench...) Så udbyderen kan enten bede brugeren om at skifte browser, eller opdatere den, eller de kan benytte plug-ins der virker ens på dem alle. Hver gang de kommunikerer, må de forholde sig til, den målgruppe de kommunikerer til, men man må også nogle gange lave nogle fravalg, hvis en lavere fællesnævner går på kompromis med egne kvalitetskrav, evner eller økonomi - internettet bliver et kedeligt sted, hvis det skal køre efter den laveste fællesnævner og standarder alene. Man tvinger ikke filmproducenter til at levere på DVD, hvis de har specielt indhold til Blu-ray.

Udbydere (kommercielle, i hvert fald) bør have lov til at vælge deres eget våben, og så må andelen, der er interesseret i at se det, skaffe sig adgangen - "du får ikke gratis leje af movie box med, hvis du lejer en film". Hvis der så ikke kommer nogle kunder i butikken, har de satset forkert og må sadle om. Mange af de seneste statistikker viser, at man måske ikke i fremtiden behøves at tække iOS bruger så meget som de selv mener de er berettiget til. Mange sidder fejlagtigt og tror, at de har en ret til at kunne se alt, hvad der vises på nettet - men sådan er det desværre ikke.

Hvis du prøvede mit lille eksperiment med at søge på "canvas demo" fra en smartphone (nu du ikke havde en iPhone), vil du måske fornemme, at det grundlæggende problem for mange sites, er at de ikke forholder sig til at devices, med begrænsede muligheder kommer ind og besøger dem. I fremtiden skal udbydere være meget opmærksomme på at lave versioner der er tilpasset mobile enheder. Jeg ser ikke nogen grund til at stationære og bærbares oplevelse, skal lide under at der skulle komme en mobil forbi.

Folk har "gladeligt" hentet ting som QuickTime ned på deres PC, fordi det gav dem nogle øgede muligheder, din bank starter også en Java applikation, så du kan tilgå dine finanser. På telefoner kan du kun gå i banken, hvis du bruger en App, og derved har de igen et godt tag i dig, og browseren har tabt. HTML er bygget til at kunne udvides, og det skal man egentlig ikke være ked at - det er noget af det der trækker os fremad.

  • 0
  • 0
#24 Karsten Vestergaard

Måske, men de har jo så en Mac i stedet ;-)

PS til Danske Spil: Det var på tide

Jeg ser ikke umiddelbart at folk med en Mac har problemet i det konkrete tilfælde - det er mere brugerne af iOS :-)

Og du har ret i at det var på tide, at de indså at den slags sites skal laves med HTML ... skrabespillene er dog stadig Flash, og virker derfor kun på Android og desktop/laptop, så de er ikke nået helt i mål i forhold til problematikken.

  • 0
  • 0
#25 Jonas Høgh

Code Reuse -- A Myth? Part II

A comparative study of Language Support for Generic Programming

Jeg synes ikke rigtigt disse underbygger din pointe. Førstnævnte er grundlæggende blot en konstatering af, at der blev lavet meget misbrug af nedarvning da OOP var nyt. Det er temmeligt åbenlyst, og har ikke meget med sagen at gøre, da OOP er meget andet end nedarvning.

Sidstnævnte artikel er en meget interessant gennemgang af forskellige sprogs evner inden for generisk programmering, men jeg synes ikke der er meget argumentation for, hvorfor generisk programmering er "bedre end OOP", det bliver nærmest taget som en given sandhed. Alene det at stille de to op som modsætninger synes jeg er tvivlsomt, selvom det er korrekt, at understøttelsen for generisk programmering i praksis er væsentligt dårligere i mainstream OOP sprog end i fx funktionelle sprog. I øvrigt er artiklen noget forældet i forhold til C#, da der er sket en del siden version 2.0 i forhold til typeinferens, (ko-)varians og andet, der gør generiske typer mere anvendelige.

  • 0
  • 0
#26 Torben Mogensen Blogger

OOP er meget andet end nedarvning.

Ikke meget mere. De andre ting du nævner er ikke i sig selv objektorienterede features -- de eksisterer fint uafhængigt af objekter. De er nærmere tegn på, at de mest udbredte objektorienterede sprog er blevet til multiparadigmesprog.

Førstnævnte er grundlæggende blot en konstatering af, at der blev lavet meget misbrug af nedarvning da OOP var nyt.

Hvis du læser videre, siger han også, at løsningen ikke viste sig at være at bruge OO bedre, men at bruge templates (altså parametrisk popymorfi) i stedet, og han argumenterer også hvorfor.

  • 0
  • 0
#27 Jonas Høgh

Ikke meget mere.

Det er jeg helt uenig i. Mange førende OOAD eksperter har advaret mod nedarvning i mange år, men de er stadig tilhængere af OOP.

De andre ting du nævner er ikke i sig selv objektorienterede features -- de eksisterer fint uafhængigt af objekter. De er nærmere tegn på, at de mest udbredte objektorienterede sprog er blevet til multiparadigmesprog.

Det ved jeg godt. Jeg siger bestemt ikke at OOP er løsningen på alt, at Java 1.0 var et perfekt sprog, eller noget i den retning. Multiparadigme er en god ting. Jeg mener bestemt at højereordensfunktioner med en brugbar syntaks i form af lambda udtryk er en stor gave i C# (siden version 3.0), men jeg synes bare der er meget langt derfra til at se OOP som en klods om benet, som vi (C# / Java udvikler) må trækkes med pga. sprogenes rødder. Der er stadig mange gode ting i OOP.

  • 0
  • 0
#28 Torben Mogensen Blogger

se OOP som en klods om benet,

Hvis du læser efter, så var det heller ikke det, jeg sagde. Jeg sagde blot, at der var en urealistisk forventning om kodegenbrug ved at bruge objekter, og at hvis formålet er kodegenbrug, så findes der bedre sprogelementer. OO kan være en hjælp til at strukturere kode, men man skal ikke regne med, at det giver øget genbrug.

  • 0
  • 0
#29 Jonas Høgh

Hvis du læser efter, så var det heller ikke det, jeg sagde.

Fair nok, det var ikke for at lægge dig ord i munden.

Måske har jeg bare svært ved at se argumentet i, at separationen af algoritme og datastruktur som fx C++ STL gør det (kva eksemplerne i dit første link), ikke er objektorienteret.

I .Net 1.0, hvor der endnu ingen generiske typer var, kunne man fx også sortere et array af en given klasse, ved at lade klassen implementere interfacet IComparable. IComparable beskriver, givet 2 objekter, ordningen mellem disse. Sorteringsalgoritmen kan så separeres fra dette, og frameworket kommer fx med hjælpemetoden Array.Sort, der kan sortere en vilkårlig array af IComparables.

At dette så i praksis pga. det primitive typesystem kræver nogle casts fra Object, og er noget mere elegant fra 2.0 og frem, da man kan bruge IComparable, er vel en biting. At dette er en procedural måde at gøre tingene på kan jeg ikke se, naturligvis skal elementet definere hvordan det sammenlignes med andre elementer, mens selve sorteringsalgoritmen ikke har noget at gøre i elementets klasse.

  • 0
  • 0
Log ind eller Opret konto for at kommentere