One of the great leaps in OO is to be able to answer the question “How does this work?” with “I don’t care”.

Det er min opfattelse, at dette er tilfældet for 99% af alle Java-programmører (for en bred definition af Java): Det forstår ikke, helt hvordan virtuelle metoder og generiske typer fungerer i forbindelse med nedarvning, så de holder sig til patterns, de har set virke -- indtil de lige pludselig ikke gør det.

Dette er ikke en kritik af Javaprogrammører, men en kritik af hele grundideen om, at nedarvning og dynamiske metodekald er den foretrukne måde at strukturere programmer på. Det bliver endnu værre, når man begynder at bruge reflection, fordi objekthierarkier viser sig ikke at være tilstrækkelige til generisk programmering. Reflection er ekstremt "leaky" og modvirker alle former for abstraktion. Noget lignende kan siges om aspects.

File descriptors abstraherer væk fra om noget er en fil, pipe, socket, en rå disk, osv. Og abstraktionen fungerer rimeligt, men den lækker aligevel nogle steder:
- man kan ikke lave select() på en fil Hvorfor må jeg ikke lave select(...read) på en fil for at vågne når nogen har appendet til den?
- sendfile() skal have en fil som source-descriptor. Og der findes ingen recvfile() API.Hvorfor det? Det ville da ellers være fikst hvis det var et API til at kopiere x bytes mellemto descriptors
- TCP OOB data kan forekomme på TCP socket descriptors.

Det er ikke noget stort problem, men dog aligevel et irritationsmoment.

Det er nok fordi der ikke er et oplagt svar på hvad der skal ske hvis filen trunkeres, eller der skrives i midten af den (eller den udvides, for den sags skyld). Man kunne selvfølgelig bare vælge hvad der skal ske, men valget vil nok føles lidt vilkårligt.

Blander du ikke to ting sammen her? Måder at konstruere abstraktioner og disses utætheder har vel ikke nødvendigvis altid noget med hinanden at gøre. Vi kan godt blive enige om at det er sejere at laver super abstrakt og generisk Haskell-kode, der fx mapper en funktion over en instans af Functor-typeklassen, end at skrive et klassehierarki i Java. Det ændrer bare ikke på, at man kan skabe en instans af abstraktionen, der brænder sammen på kørselstidspunktet, fx hvis din functor er IO-monaden, og din fil ikke er tilgængelig.

Tjo, det er heller ikke noget stort problem. Det eneste sockets og filer i praksis har til fælles er close(), read() og write(). Man kunne så overveje om de i det hele taget begge skulle bruge samme namespace (descriptors), men jeg har arbejdet med OS/2 hvor file handles og socket descriptors ikke var fælles, og det var heller ikke ideelt. Eller i den anden ende af skalaen: win32, hvor filer, mutexes, sockets, ...altsammen er handles, som dog ikke opfører sig helt ens.

Der er altid et sted en abstraktion ender med at knække:

• Den rene Haskell-funktion tager ikke højde for hukommelsesforbrug
• Du kan skrive klassehierarkier der bryder med Liskov's substitutionsprincip
• Du kan definere en instans af Functor eller Monad som ikke er det i Haskell

Og så videre.

Men gode abstraktioner er dem der lader dig beskrive et problem mere præcist end ellers, så du kan arbejde på et højere niveau end normalt. Og gode abstraktioner lader dig modularisere programmet, så dele kan udskiftes løbende, eller udvides uden at skulle lave tværgående omskrivninger.

Det har altid været min overbevisning at transparente systemer er dem der virker.

Hvis du ikke kan ad-hoc forespørge i det (kørende) system og pakke en abstraktion ud, så har du meget lille chance for at håndtere de fejl der gemmer sig. Rigtigt gode systemer er designet sådan at de har selvafslørende dele, hvor de på den ene eller den anden måde oplyser om at de er ved at køre skævt.

Du laver abstraktionen for at undgå denne udpakning til dagligt. Og den gode abstraktion er den hvor det er sjældent du skal gøre det. Men jeg vover at påstå at hvis du bruger et bibliotek uden at nogen i projektet kender dets interne opbygning, så arbejder du med en unødig risiko i dit projekt. Der er simpelthen for mange uskrevne regler om hvad der er forventet anvendelse, og bryder man med en af de regler, så går det som regel galt i det lange løb.

Torben har iøvrigt ret i at aspects er ualmindeligt dårligt som en programmeringsredskab. Men til ad-hoc sporing i systemer er det nok det værktøj jeg anvender mest i mit daglige arbejde når der skal findes fejl (se Erlang's tracing, dtrace(1) i Illumos/FreeBSD/OSX).

Problemet med denne abstraktion er dog primært ydelsesbaseret, og hvis det er målestokken, så er der næsten ingen abstraktioner der holder vand. Hvis du ikke ved nøjagtigt hvad der sker, så ved du ikke hvordan det yder, men som ofte er man også ligeglad.

Jeg vil egentlig mene at disse steder, hvor der er ambiguitet, netop afspejler steder hvor OO metodikken IKKE er den bedste løsning, til at sikre kode der er nemt af fejlfinde og udvikle i (uden overraskelser). Jeg vil næsten påstå at OO bedst er brugt til datastrukturer (ordrer, varer, indkøbskurv mv.) og funktioner er bedre til interaktion med "omverdenen" - sådan når det gælder at sikre at koden bliver nem for alle at gå til, og så burde man netop kunne undgå disse "leaky abstractions". Og når der så kommer multipel arv ind i billedet og mudrer billedet, ligesom Mikkels Date eksempel.. så synes jeg bare det viser områder hvor OO IKKE forbedrer kodekvaliteten, og det bliver et eksempel på at alle problemer er søm, fordi man kun står med en hammer.

Mange virker til at have glemt en af de største kvaliteter ved god kode (efter min mening naturligvis ;) - nemlig at den er let forståelig og ikke "leder i uføre".. de højere niveau sprog blev vel primært opfundet i et forsøg på at gøre os mere effektive, ikke for at anstrenge os endnu mere :)

Ikke at man ikke kan lave gode abstraktioner for filhåndtering mv.. men man skal dælme passe på hvor meget funktionalitet man så forsøger at udstille og abstrahere væk..

Man fristes til at sige man glemmer at gøre det KISS :)

Jeg er PhD-studerende i kode-optimering og high-performance-computing, så noget nær mit eneste fokus er køretidsydelse. Fra mit synspunkt bruger alle (inklusive mig selv) abstraktioner der giver et enormt mudret billede af køretidsydelsen. Insisterer du ikke selv på kun at bruge sprog der kører oven på en virtuel maskine? Det er da i dén grad en (nyttig og værdig) abstraktion der besværliggør forståelsen af hvad den fysiske maskine egentlig ender med at bruge sin tid på.

Og jeg tror ikke, at jeg er den eneste, som har det sådan. Tag fx igen Polsag-historien - applikationen giver sikkert de rigtige resultater, men er bare ubrugelig i praksis, fordi alt kører som en gigtramt skovsnegl indefrosset i en gletcher.

Det gør den (angiveligt) fordi den laver alt for mange databaseroundtrips, ikke fordi koden ikke er optimeret i forhold til registerallokering, cachelokalitet o.a. der er mange størrelsesordener billigere end et enkelt netværkskald. Min erfaring er i hvert fald, at man i en forretningsapplikation meget meget sjældent behøver at tænke over performance, når man bare har styr på hvordan databasen performer.

Kun hvis abstraktionen er en del af din beregningskerne. Uhyggeligt meget kode har det med at falde udenfor det behov i praksis. Produktivitet er også at kunne gennemskue hvornår man bare skal hive en abstraktion ind fra højre, velvidende at den koster noget i systemet. Det gør at man kan bruge tiden et andet sted i sit system, hvor det har større effekt.

Case in point: Erlang kører via en bytekodefortolker uden JIT. Det gør den ca. 10 gange langsommere end tilsvarende C kode og en 7-8 gange langsommere end tilsvarende Java eller OCaml kode. Men et typisk Erlang-program, når du profiler det, bruger kun ca. 20% af tiden i emulator-loopet i fortolkeren, så selv hvis vi eliminerer dette er vores program kun blevet maksimalt 20% hurtigere i praksis. Til gengæld kan jeg vel skrive kode 10-20 gange hurtigere i Erlang-abstraktionen, så jeg kan bruge tiden andetsteds, mere fornuftigt.

I sproget D er brugen af UFCS meget udbredt for at undgå at biblioteks-udviklere kontinuerligt finder på nye sub-klasser som til sidst giver et ret rodet billede af hvilke objekter man arbejder med. Om det ville løse det aktuelle problem kan jeg ikke svare på, men generelt skulle effekten være at klassehierarkiet kan forsimples.

Løsningen i D er inspireret fra Scott Meyers [1] og består i grunden af at kompileren omskriver "foo(a)" til "a.foo()" hvis "foo(a)" ikke findes. Jeg kan egentlig godt lide konceptet.

Den aktuelle tilfælde lyder da i øvrigt som om Liskovs substitutionsprincip er brudt - eller hvad?

1: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/1844...

Men er det en leaky abstraction? Det er jo dokumenteret at det er sådan det virker, og du kan jo lave det om - du kan jo deklarativt ændrer dette. Både generelt og i enkelte tilfælde (det er jo en funktionalitet man gerne vil have i nogle sammenhænge - en del faktisk).
Det er korrekt at der er et mismatch mellem Object model og Relational model, og at en ORM derfor vil være leaky, men det er vel et forstået problem for dem som arbejde med omådet?

Pointen er vel, at det er nødvendigt at sætte sig ind i hvad man arbejde med, for at kunne gøre arbejdet ordenligt. http://martinfowler.com/bliki/OrmHate.html

Helt enig. Og en ting er at mange bruger ORM naivt og undlader at tænke over at mange lazy loads ofte performer dårligt. En anden ting er, at det ORM Mikkel her har fat i, må være meget patologisk, hvis det er nødvendigt at generere proxy-typer af primitive værdityper som datoer...men måske lever jeg bare i lykkelig uvidenhed om rædslerne i java.util.Date?

er en rædsel, men der er heller ikke nogen grund til at bruge den. Joda eller Java 8 date/time er langt at foretrække og kan sagtens benyttes med Hibernate (der kan være gamle legacy systemer hvor det muligvis ikke kan lade sig gøre, men så må man gribe til refactoring).
Datoer er iøvrigt ikke primitive typer. java.util.Date er ikke en dato, men et tidspunkt, og både datoer og tidspunkter er temmeligt komplicerede datatyper, hvilket java.util.Date og dens rædsler også er vidner om.

Hibernate (og andre ORMs) benytter i udstrakt grad proxies. Det er ikke nødvendigvis forkert, og det ville være svært for dem at leve op til kontrakten, hvis ikke de gør. Men som alt andet software kan der jo altså være fejl i implementationen. Det gør ikke nødvendigvis en abstraktion leaky, det afslører blot en bug.

Man skal også huske på at i visse tilfælde vil en join (for eager fetching) ikke producere de korrekte resultater, og i nogle tilfælde heller ikke være hurtigere end lazy fetching. Det kommer helt an på hvordan man har skruet sit skema sammen. Dvs. hvilke use cases skema er optimeret for.

Men er det ikke som at give en vej skylden for at have et sving, selvom det er din bil som ikke kan dreje?

Et andet godt eksempel fra det ORM-framework jeg slås med til daglig er det at føje et objekt til en persistent collection. Når man gør det, så populerer frameworket først collectionen, så man altså ender med at lave et potentielt meget stort antal objektinstanser, uanset om man faktisk nogensinde tilgår dem eller ej. Netop den abstraktion er så lækkende, at den er tæt på at gøre mere skade end gavn.

Ja det er irriterende, men det har IMO meget lidt at gøre med en lækkende abstraktion. Abstraktionen er at du arbejder med en almindelig collection af objekter. Sådan nogle ligger normalt og fylder i hukommelsen :). Det er kun fordi du ved hvad der ligger bag abstraktionen, at du sukker efter en ORM, der "bare kan generere en simpel INSERT-statement".

Enig, abstraktionen opfylder jo kontrakten.

Datoer er iøvrigt ikke primitive typer.

Undskyld, jeg mente ikke Javas snævre definition heraf, blot at det er en (forholdsvis) simpel Value Type som defineret i Eric Evans :)

Mener du virkelig at Hibernate bruger proxyer på "feltniveau", jeg troede kun det var på relationer fra en entitet til en anden, eller fra en entitet til en collection?

Nej det mener jeg selvfølgelig ikke. My bad :-) Det er som du siger. Entiteter er repræsenteret vha. proxies. Men hvis man er helt ude i hampen kan man jo erklære en java.util.Date som en entitet :-)

Men hvis man er helt ude i hampen kan man jo erklære en java.util.Date som en entitet :-)

Aaargh