Klaus Kolle wrote:
> Hov, hov - roderi kan du lige så godt lave med funktionsorienteret
> programmering. Jeg ser ikke noget i at det er objektorienteret der
> skulle fremtvinge rod i lagring af data.
Nu kan man definere rod på mange måder - i dette tilfælde har Microsoft
ladet objekterne selv streame deres data, hvilket giver et rodet filformat
per definition.
> Jeg har selv i mange år udviklet databaseprogrammer objekt orienteret
> uden dermed at få roderi i datastrukturer.
Datastrukturer = data uden kode eller med kode? Det er nemt nok at have
orden sålænge man har koden, kunsten er at tolke data uden at have koden...
> Faktisk vil jeg sige at den
> objektorienterede tilgang ofte gør det hele mere overskuelig.
Enig.
> Men det
> kræver lidt håndarbejd, når man skal lagre i filerne.
Ja. Og Microsoft valgte en tåbelig, men meget objektorienteret metode.
Objektorienteret, fordi filformatet ikke giver mening uden kode, og fordi
objektorienteret går ud på at sætte kode og data sammen.
> Intet OOP-specifikt her. Jeg bruger også en gang i mellem kode fra to
> forskellige versioner når jeg skal opgradere.
> Den gamle kode kan læse
> de gamle formater - den nye kan skrive de nye. OOP eller ej.
Korrekt - men hvis dataformatet var nemt læseligt uden
klasseimplementationerne, ville det ikke være nødvendigt. På grund af OOP
er de nødt til at konvertere filformatet og nødt til at bruge kode fra
begge versioner.
> Det har nu været diskuteret i mange år og mange har vist at f.eks. C++
> kan kompilere til mere effektiv kode en C. Såe...
Det har jo intet med sagen at gøre. OOP er at knytte programkode til data,
og alternativet er at have data uden tilhørende programkode. Eksempel: Før
OOP hed det *char, og efter OOP hed det CString. CString er klart lettere,
giver større produktivitet, sandsynligvis også mindre programmer, da koden
for en del string håndtering genbruges. *char giver muligheden at lave
stringhåndtering uden at CString klassen skal involveres, og enkelte
operationer vil mest sandsynligt blive programmeret mere effektivt. Du kan
smide en *char ud til stort set alle programmeringssprog, og det virker.
Hvis du derimod kaster en pointer til en CString ud til et modul, kræver
det, at dette modul på en eller anden måde har adgang til CString
implementationen, dvs. kode. Uden adgang til CString koden, er en CString
ikke meget værd. Hvad er mest effektivt? Tja, det kommer faktisk an på,
hvad du måler, og hvad dit success kriterie er.
> Det er rigtigt at deling af kode i f.eks. COM objekter medfører lidt
> overhead til administrationen af de "enkeltstående" objekter, men så
> slemt er det vel heller ikke, hvis man i stedet får mulighed for
> genbrug på en struktureret måde.
Af en eller anden grund, ville jeg ikke gemme en million strings i memory
som objekter, hvor implementationen nås via COM... jeg ville foretrække
*char, selv om den ikke er objekt orienteret. Simpelthen fordi jeg så kan
skrive koden til håndtering af data inde i mine løkker, i stedet for at
skulle foretage en million COM kald.
> Jeg kan da sagtens lave en klasse, som kan håndtere en jpeg fil og
> lade en instans af klassen (inklusive data fra filen) være et objekt.
Ja - man kan sagtens pakke traditionel, struktureret programmering ind i
OOP. Og modsat. Men grundlæggende er en jpeg fil uafhængig af
implementation, og dermed en ikke-objektorienteret teknologi.
> XML kan typisk også håndteres både proceduralt eller objektorienteret,
> men jeg ved godt hvad jeg vil foretrække.
Erm... jeg snakker ikke om procedurer vs. objekter, jeg snakker om objekter
vs. adskillelse af datastrukturer og programdele. Men i øvrigt programmerer
jeg normalt altid XML streambaseret - nok mest fordi jeg bruger XML en del
i forb. med webservere, hvor selv et lille memory forbrug kan være
performance hindrende. Men så har streambaseret programmering også den
fordel, at jeg kan sende de første records som xml inden min database
server (normalt firebird) endog har fundet ud af, hvor mange records der er
tale om... og klienten kan anvende disse XML data og vise resultatet inden
webserveren har sendt den sidste record, og dermed inden databaseserveren
har alle data. Det er ret fedt, når tiden fra et museklik til at man ser
første record på skærmen, hentet over internettet, på 30 millisekunder,
også selv om det tager 1-2 sekunder for database serveren at hente
records... Hvis XML data blev opbygget på sædvanlig in-memory OOP vis som
objekter, leafs osv., ville den jo skulle vente 1-2 sekunder før den
overhovedet begynder at sende noget. Og hvis klienten skulle opbygge XML
træ som objekter i memory, ville det også betyde at alle data skulle
downloades før den første record vises... medmindre man selvflg. bruger
ekstremt meget krudt på at lave en multithreaded træ-opbygning.
Jeg plejer at holde mig til KISS og at lave god kode, der er nem at forstå
og som virker rigtigt godt.
> Eller måske forstå dem
Nemlig
I øvrigt så jeg, at en af skribenterne i Delphi Magazine i januar 2003 skrev
en artikel om noget af det samme, som jeg skriver her. Han havde en
påstand: OOP er godt når data risikerer at ændre sig, hvorimod OOP er
skidt, når funktionaliteten skal ændre sig. Jeg er ikke sikker på, at jeg
giver ham fuldstændig ret, men jeg vil give ham ret så langt, at hvis man
kan fastlægge datastrukturer præcist (og her snakker jeg IKKE objekt
datastrukturer!!!), så vil man være i stand til at få væsentligt mere
modulære systemer end hvis man går OOP vejen. Datastrukturer inkluderer her
filformater, memory filformater, pipe protokoller og internet protokoller.
XML revolutionen handler tildels faktisk om at undgå OOP og i stedet bruge
implementationsuafhængige datastrukturer.
Lars Dybdahl.
--
Dybdahl Engineering
http://dybdahl.dk/