C# Knas eller begränsning?

Det är jätteskönt att inte komma åt variabler utanför scope. Hade blivit drygt med stora program om saker som i, n, j redan var upptagna i andra metoder. Nej tack!

Kan du inte lägga ut lite av din kod. Ganska svårt att förstå vad du menar? Räcker inte return?

Säg det till Rich Hickey, har var ursprungligen en C# utvecklare och jobbade på en lång rad gigantiska projekt, bl.a. åt US-gov. För att på något rimligt sätt kunna hantera de mängder kod och den komplexitet de hade skrev de det mesta just som statiska metoder för att undvika alla problem som funktioner med associerat implicit tillstånd (i.e. "this") för med sig. Andra verkar hålla med denna ståndpunkt.

Det fungerade men han insåg att det var väldigt mycket fight-the-system, något som resulterade i språket Clojure (som initialt designades för CLR för att fungera ihop med existerade C#-kod men senare flyttades till JVM då dagens JVM har betydligt bättre prestanda än MS CLR). När väl folk lärt sig bättre kommer OOP gå till historien som datorvärldens största aprilskämt, det är så fel på så många sätt i dagens multicore värld

Det är OT så tar det någorlunda kort/översiktligt...

En av de fundamentala grundpelarna för OOP är inkapsling, både av exakt beteende och av representation av data. Det senare är totalt inkompatibelt med god design för något som ska köras på multicore-system då det är absolut kritiskt att totalt förstå hur data representeras och under vilka omständigheter data kan läsas eller skrivas (utan den kunskapen är det svårt att göra saker korrekt och omöjligt att göra det effektivt). Här måste data definieras separat från algoritmer som jobbar på data. Detta är INTE samma sak som att all data är "immutable" och allt är rent funktionellt, det är en trevlig teori men det presterar öken i praktiken.

Finns fall som kanske är närmare mångas vardag, "objektorienterade språk" (typiskt C# och Java) är väldigt vanliga till att implementera affärslogik ovanpå någon form av RDBMS och körs ofta i något ramverk som presenterar ett gränssnitt mot Internet. OOP är ett sätt att modellera världen i form av "objekt" och förändra dessa objekts tillstånd via väldefinierade interface (uppsättning metoder). Men vilket tillstånd finns i typisk affärslogik? Typiskt väldigt lite, utan i stället handlar det om att skriva koden som på något sätt utför en transform på ett dataset för att det ska presenteras.

En av designvalen i OOP är att fokusera på tillstånd och sätt att förändra tillstånd, OOP är väldigt dålig på att hantera design av algoritmer, d.v.s. transformation av data. En algoritm har inget associerat tillstånd och kan därför inte modelleras som en klass på något rimligt sätt. Då affärslogik typiskt är algoritmer, varför då använda OOP?

Det FINNS ställen där OOP är väldigt användbart, många former av simulering passar OOP väldigt väl (så typiskt bra för spel). OOP fungerar också riktigt bra för GUI-ramverk, knappar, textboxar etc är ju typexempel på "objekt" med associerat tillstånd som rimligen har väldefinierade sätt att ändra det tillståndet.

Rich är långt ifrån den enda som ser problem med OOP.

Det sista du skrev är ju mer ett problem i specifika språk/ramverk än ett verklig problem. Det går alldeles utmärkt att testa saker i språk som C, Go, Clojure m.fl. som överhuvudtaget inte har koncept av klasser...

För Java finns ju flera gratisramverk på code.google.com, t.ex. PowerMock, som bl.a. stödjer mocks av statiska metoder ihop med JUnit, är ju rätt uppenbart att sådant måste finnas.

Jag har undervisat OOP och gjort massor med OOP i C++ och Java, fast det var på 90- och 00-talet. Är väldigt bekant med den ursprungliga Design Patterns boken från 1994. Men dels har OOP alltid varit överanvänt och innan mitten av 00-talet var multi-core CPUer något som i princip bara fanns i extremt dyra system, inte något som finns i den billigaste lilla enhet, numera är ju till och med en 400kr RPi multicore. Av alla tänkbara sätt att programmera dessa multicore enheter måste OOP vara det absolut sämsta.

Modulär kod är helt ortogonal mot om man använder OO-, funktionell- eller procedurell-programmering. Kod som är enkel att integrera är typiskt funktioner som helt saknar implicit tillstånd och därmed bara beror av sina argument (d.v.s. inte metoder), men viktigast är att designa interface som är minimalistiska, koherenta i sin abstraktionsnivå och löser ett eller i alla fall väldigt få specifika problem, åter igen helt oberoende av typ av språk/programmeringsparadigm. I OOP är polymorfism baserat på typ (via arv) något som gång på gång visat sig motverka modularitet och göra designer stelare, polymorfism och därmed arv är ju en annan av grundstenarna i OOP. Polymorfism är definitivt något bra, felet i OOP är att det är så hårt knutet till arv när det finns så väldigt många andra selektorer än typ som borde kunna användas.

OOP är inte värdelöst på något sätt, men det borde vara ett specialverktyg för de relativt få fall det faktiskt passar i stället för att vara förvalet i alla lägen där det inte är totalt omöjligt, vilket har varit fallet under ganska lång tid nu.

För tillfället skriver jag kod som ska passera DO-178C level A, det är skrivet i C där allt kan anses vara "statiska" metoder. Kravet för testning här är att man testar varje möjlig permutation av villkorad körning som kan ändra sekvensen av satser, inte helt trivialt att skriva sådana tester men det är fullt möjligt utan några specialverktyg utöver GCC (stora bokstäver så det är alla verktyg som ingår, inte bara kompilatorn gcc), autotools och make.

IceDread, du låter rätt förvirrad. SOLID är hur trevligt som helst, men det har inte speciellt mycket med statiska metoder och klasser att göra, att man följer SOLID principer betyder inte att man inte får skriva statisk kod. Ta t ex Math klassen i Java, vore hur dumt som helst att gnälla över att den inte är SOLID, det är inte poängen.

Håller man på med OOP är det viktigt att man håller koll på principsaker som SOLID för annars blir det rörigt som satan, men det är inte ett argument mot andra lösningar så som funktionell programmering som har sina egna stora fördelar. Sen tror jag å andra sidan inte som Yoshman att OOP kommer försvinna och glömmas bort, det är alldeles för passande för stora områden... men jag tror andra paradigm kommer ta och få större plats i framtiden när fler inser att OOP inte är den optimala lösningen för all form av mjukvara.