Mitt program har nu börjat växa rejelt och är nu inte så överskådligt. Tänkte därför ta och dela upp koden i lite olika .cs filer. Men det dryga med det är ju att jag måste skapa en instans i varje fil där jag vill använda den .cs fil jag vill använda. Finns det något enklare sätt att dela upp koden i block. Vet inte om jag är helt ute och cyklar nu men kan jag skapa static metoder i .cs filerna och få åtkomst utan instanser? Det är inga objekt om man tänker objektorienterat som jag vill lägga i .cs filerna utan bara dela upp min kod i block så den blir mer översådlig.
Hur brukarn man lösa detta problem i programmerings världen?

//Henke

Hej...

Man brukar gruppera klasser efter dess samhörighet samt släktdrag, samt metoder.
Det du kan göra är att just skapa flera klasser. Dock rycker jag inte du skall göra metoderna statisca (kanske några där det kan behövas, eller fungerar bra.) Annars måste du tyvärr göra instansieringar. Fördelen med att skapa instanser är att du då för en ännu bättre spårbarhet i din ev. spagettikod du fått fram. Vilket ger dig ännu mer kontrol över det som kan vara svår kontrollerat just nu.
Statiska metoder gör att du måste sätta allt i klassen till statiskt som du vill använda dig av, det betyder att interna icke static algoritmer, attribut inte kan nås utan en instans. Allt handlar ju om hur du designar din kod, vilka designmönster du vill nyttja, syfte och krav på återanvändning, underhållning etc...

Om du har sidor med exakt samma metoder fast redundatna sådana så kan du lätt slänga in dessa i en klass och återanv'nda metoden på dessa ställen,detta minskar kod samt ökar spårbarhet samt framtida ¨versioneringar av metoden. Du måste inte skriva om den på flera ställen om du skulle finna något fel i den eller vill utöka dess funktion.

Några tips som kanske kan hjälpa dig?

//Johan N

Oftast brukar det (enligt mig) vara lättast att sätta sig ner och skissa lite på hur man kan tänkas bygga upp sin kod om nånting har blivit oöverskådligt. Börja med att skriva en klass innehållande själva basen i programmet. Bygg sedan ut programmet genom att lägga till bit för bit i det upplägg du har valt att göra (uppdelning i olika cs-dokument, accessmöjligheter osv). På så sätt upptäcker du direkt vad det är som skapar problem, kommer tillbaka hit och frågar nån vänlig själ om hur du ska gå tillväga med problemet, ändrar om din kod, osv osv, tills då har fått bättre struktur.

Lycka till!

"Oftast brukar det (enligt mig) vara lättast att sätta sig ner och skissa lite på hur man kan tänkas bygga upp sin kod om nånting har blivit oöverskådligt."

Självklart, något man borde gjort från första början :-)
Ibland har man kanske inte tid att sätta sig ner och skissa, Dagens it-projektledare och chefer i sverige vill alltid se resultat med en gång, de tål inte resultat på papper,
det är så tragiskt att det inte är sant. Skissar man i 3 mån och det sedan tar 1 mån att bygga saker så duger inte det för många de inser inte att dessa 3 mån gör att det bara tar 1 mån implementation och sedan kanske några få timmar att göra ändringar jämfört med om man la 4 mån på att bara bygga, då tar oftast en ändring flera timmar kanske tom vecka eller månader. "Rush to code" bör ju inte egentligen inte få existera. :-)

//Johan N

Ibland (ganska ofta) om man skriver nåt för sig själv kan det vara riktigt schysst att sätta sig och koda direkt. För att se att nånting händer! Men om man verkligen har kört fast så behöver det inte ta speciellt lång tid att "skissa" om det så är på papper eller att man bygger om applikationen i mindre format för att testa ändringar i upplägget.

Sedan får vi inte glömma den mycket pratiska funktionen i Visual Studio som är att gömma kod, Outlining.

Om du till exempel har en klass med en massa egenskaper så brukar de ta mycket plats. Men genom att skapa en region runt dessa egenskaper kan du dölja alla på en gång och får då en mer överskodlig kod.

En region skapar du genom att skriva
#region beskrivande text
kod
.
.
.
#endregion

Larre