Spagetti - hur skall man koda för att undvika det

Det krävs ofta större system (tex gammal legacykod hos företag, som är äldre än OO) för att spaghettikoden skall bli ett verkligt, konkret problem. Jag kan försäkra dig om att den finns och att den är ett rent helvete att sätta sig in i och underhålla. Men självklart kan jag inte lägga ut den här.

Det är relativt få som bara råkar ha en stor blaffa källkod hemma att visa upp, som inte är hemlig och som är spaghettikod. För små applikationer är inte spaghettikoden något större problem, och de som gör halvstora applikationer hemma för skojs skull har troligen slutat koda spaghetti med köttbullar för länge sedan.

GCC och Apache har ett par år på nacken - på den tiden var det inte särskilt vanligt med OOP och .NET fanns definitivt inte i krokarna då. .NET-kompilatorn och IIS 7 är för övrigt skrivna i C++, bara för att ta två exempel på stora motpoler till dina exempel. Sedan är det väl ganska välkänt att open source-projekt och open source-programmerare inte tillhör OO-communityn eller är de mest entusiastiska OO-utvecklarna; de utvecklarna och de projekten har ju oftast sina ursprung i källarlokaler och av "källarprogrammerare".


OO-utvecklare som jag har ofta som princip att inte göra för mycket och skapa "supergenerella" system som passar alla storlekar, utan man gör det som uppfyller kraven som finns nu, men man lämnar ändå utrymme för utökning och modifikation i framtiden. Just detta blir betydligt enklare när man har väldefinierade lager i systemet där de olika komponenterna lever, och varje lager har ju sitt ansvar förstås. Och om man klokt använder abstraktion så kan man få riktigt snyggt designade system som inte brakar ihop vid första förändring.


Då kan du skapa upp din Window-klass och ha metoder och properties för allt det du beskriver, men endast implementera de du behöver nu och som uppfyller kraven; alltså kastar du ett NotImplementedException i de övriga. I V2 kan du implementera dessa metoder utan att behöva ändra "kroppen" på klassen vilket kanske underlättar för befintliga klienter som slipper omkompilera och testa igen. Men om du vet att du aldrig någonsin kommer att behöva sätta fönstertext, storlek, o.s.v., så kanske en Window-klass är lite "overkill" och du kanske borde implementera det på något annat sätt - det gäller att vara pragmatisk. Klasser är löser inte alla problem i världen, men de är mycket trevliga att jobba med.


En god OO-utvecklare ska inte "binda sig" till framtiden genom att göra för mycket som kanske inte behövs - men däremot ska han lämna utrymme för förändringar och utökning i framtiden exempelvis genom abstraktion. En OO-princip som tillåter detta är exempelvis Open-Closed-principen, om du nu känner till den.


Med OO får du betydligt mycket mer på köpet: du får typsäkerhet, effektiv återanvändning av kod och utökningsbara system, du kan använda dig av abstraktioner för att enkelt utöka befintlig kod och ersätta en implementation med en annan och koda "defensivt" så att en liten förändring i systemet inte behöver betyda förändring i femtioelva moduler som påverkas av detta (side-effects). Ren C är ganska mycket a thing of the past, det har ingen riktig plats i framtiden och framtidens tekniker, i synnerhet när .NET ramverket utvecklas och växer i snabb takt. Det är och kommer förbli en grej för hårdvaruutvecklare, vissa Unixprogrammerare och förmodligen lite spelutvecklare.


Jaså? Vi får väl se om Uncle Bob kan övertyga dig - detta bör i synnerhet du se som står fast vid C och ifrågasätter OO:

http://weblogs.asp.net/rosherove/arc...ss-design.aspx

Det var aldrig meningen att antyda om att det skulle vara brist på stora projekt som följer OO-modellen, utan bara att det finns många andra stora projekt som inte följer OO.

Även om Apache är mycket gammalt och härstammar från den klassiska C-eran så är version 2.0 en nästan total omskrivning av programmet (alpha-versionen först år 2000). Utvecklarna kunde då ha valt att övergå till C++ men gjorde det inte. Open source programmare är inte entusiastiska medlemmar av OO-communityn eftersom OO inte är på något sätt en silverkula.


Samma argumentation fungerar för gammal hederlig "modulär" C-kod. Är det objekt-orientering i sig som underlättare, eller är det snarare faktumet att man separerar komponenterna ifrån varandra?

Funktioner som är deklarerade i C behöver inte heller vara definerade (om de inte används).

Överdesignade/generaliserade komponenter är knappast något som alltid sker vid OO-utveckling, men av personlig erfarenhet och av åsikter inhämtade från andra så brukar det åtminstonde accepteras som en av farorna med OO. Kan du med gott samvete säga att du själv aldrig har skrivit mer än vad som egentligen hade varit nödvändigt? Jag har själv i alla fall gjort det.


En paradigm som sätter fokus på objekten kräver av naturliga skäl också stark typsäkerhet. Även om det finns fel som man kan göra i C p.g.a. att det inte är typsäkert (C är trots allt det klassiska exemplet på ett typosäkert språk) så skulle jag vilja påstå att de definitivt inte tillhör majoriteten.

Välskriven OO-kod kan och bör jämföras med välskriven C-kod. Kod som man delar upp i moduler och som själva försöker vara så autonoma som möjligt, eller annars har tydliga knytpunkter, är något som man eftersträvar med båda stilarna.

OO-kod kan lika lätt få ett spindelnät av beroenden som icke-OO-kod. Även om design-mönster berör andra stilar så är det först och främst inriktat på OO.


Heh, tja... med tanke på att *nix numera håller på att växa och det mesta i *nix fortfarande är skrivet i C så skulle jag personligen inte satsa många slantar på det.

En av C-s främsta styrkor är att språket är enkelt. I någon mening så är C raka motsatsen till vad C++ är.

Det är relativt entydligt vad en rad C-kod gör för något medan detsamma kan man knappast säga för C++. C++'s OO, med otaliga regler om vad, när och hur något kastas till något annat, vilka temporära objekt som skapas och exakt vad för påverkan ett undantag har på ett givet ställe, gör språket i vissa fall mycket svårare att förstå och buggsöka än vad som annars är absolut nödvändigt.

C#/.NET, Java och m.fl. är många gånger bättre än C++ på det området, men saknar å andra sidan C's elegens som ett enkelt imperativt språk.

Behöver du verkligen OO om du inte skriver GUI-relaterade delar? Är det nödvändigt att slänga in en full OO-hierarki när du, säg, skriver en IRC-server? Måste man använda sig av arv för att symbolisera olika typer av användare eller räcker inte bara en "int"-flagga?


Du behöver inte övertyga mig om OO; jag är först och främst en C++ programmare och inte någon C programmeare.

Principen och tankarna bakom OO är definitivt värda att ta till sig. Men om man verkligen använder sig av OO eller ej; det får variera från fall till fall. GUI-kod är de enda som jag spontant tycker nästan alltid bör använda sig av OO-modellen.

Ett par länkar för att balansera din pro-OO länk...

http://www.codinghorror.com/blog/archives/000617.html
http://www.codinghorror.com/blog/archives/000801.html

Edit: Ugh... massor av stavfel.