Skrivet av heretic16:
Jag använder typ aldrig arv, interface eller någon annan mystisk OOP-teknik.
<rant>
Att inte använda OOP med än nödvändigt är väl rätt nyktert 2019, om någon har bra motexempel får de gärna motbevisa mig men vad av det som är unik för OOP är det någon som idag försvara som "bra"?
Att inte programmera mot interface känns dock lite bonkers, varför gör du inte det?
Många sätter likhetstecken mellan OOP och saker som "polymorfism". Polymorfism är inte på något sätt unik för OOP utan är väldigt användbart, t.ex. genom att programmera mot ett väldefinierat interface som implementeras på olika sätt beroende på underliggande typ ("klass" är bara en specialisering av "typ").
De saker jag kan komma på som unika för OOP är implementationsarv (som nog de flesta är med på att man bör undvika idag), hopkoppling av data och beteende (som faktiskt motverkar "reuse", något som OOP var tänkt att förbättra...) samt inkapsling (som är en dålig idé om man effektivt vill använda många CPU-kärnor).
En annan riktigt dålig idé, fast den är inte unik för OOP, är exceptions. Java gjorde ett rätt misslyckat försök att laga det mest slående problemet med exceptions (bättre namn är nog goto-on-steroids): om jag bara känner till signaturen på en funktion/metod kan jag ändå inte säga vilket typ har data som jag får tillbaka? Detta försökte Java fixa genom att tvinga funktioner lista både returtyp och alla exceptions som kan hända.
</rant>
Det skrivet, finns trots allt nischer där OOP är rätt val! Ramverk för UI är ett bra exempel, de passar perfekt för abstraktionen och är i praktiken rätt hopplöst att skala med CPU-kärnor.
Självklart finns det saker som man inser att kunde ha gjorts bättre i efterhand och detta citat är lika sant idag som när det skrevs för 44 år sedan (The Mythical Man-Month)
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.
Men finns ett ännu mer träffande citat
Perfect is the enemy of good
Även om man skriver en pilot, tar all tänkbar lärdom, slänger bort den och sätter sig och knackar kod så kommer det med väldigt nära 100 % säkerhet inte bli perfekt. Man har inte alla fakta, saker ändras under resans gång, tid är en resurs som man inte kan skaffa mer av oavsett hur mycket pengar man har...
Ser i tråden de vanliga klyschorna om att "bra kod inte kräver kommentarer". Det är definitivt fel. Finns kod som är så välskriven att man enkelt förstår vad den gör. Men i många fall är det helt hopplöst att få svar på frågan varför en viss algoritm är vald, vad syftet med funktionen/modulen är samt i stora komplexa system finns tyvärr ofta implicita antaganden som var uppenbara för den som skrev koden men som mycket väl inte går att se om man bara studerar funktionen/modulen i isolation.
Det betyder inte att man ska skriva massor med kommentarer. Tvärtom, allt som går att uttrycka i kod ska uttryckas i kod för kompilatorer/datorer läser inte kommentarer! Men finns saker som endera uttrycks i en kommentar och därmed underlättar rejält för de människor som försöker förstå koden eller så finns inte den informationen på något lättillgängligt sätt.
Saker har ändå blivit långt bättre genom åren. Väldigt få som ifrågasätter värdet av unit-tester som en självklar del i utveckling. Överhuvudtaget är insikten kring värdet av automatiskt testning relativt hög. Tester underlättar också för de som försöker förstå en kodbas, tester kan därmed i viss mån ersätta kommentarer (för de som absolut vill minimera mängden kommentarer).
Sen finns det vissa som fortfarande verkar se ett värde i "komplicerad kod" (kod kan med fog vara komplicerad om den löser ett komplex problem, men detta refererar till onödig komplexitet)... Har vid ett tillfälle fått kommentaren: "vi är missnöjd med priset vi betalade för er kod (hundratusentals rader), den var väldigt dyr men vi har inga problem alls att förstå vad den gör så det verkar ju inte så svårt". Vad svarar man på det
