Kanske en nybörjarfråga, men ändå...
Eftersom jag för det mesta suttit med VB6 och VB.NET så har jag vant mig vid att kunna placera generella funktioner i en modul som jag sedan kan anropa från vilket formulär som helst så att jag slipper skriva samma kod flera gånger mm. Men hur gör jag det i C#? Är jag helt ute och cyklar när jag letar efter "modul" i C#, eller skall man lösa det på något annat sätt?

Måste nog ta mig tid och åka till bokaffären och köpa mig en bok om C# med det SNARASTE! :)

Det är vad jag tror...

Att man skapar den i en vanlig klass och instansierar denna klassen från de klasser som behöver den.
Kanske som Shared om alla värden skall vara lika?

Hoppas på att någon kan ge oss ett BRA! svar.


/Alexander

Om du gör metoderna/funktionerna statiska i klassen behöver du inte instansera något objekt.

<code>
public static string MinFunktion()
{
return "x";
}
</code>

/Johan

Johan svar är lösningen, static gör metoden medlem av klassen istället för objektet.

Vilket gör att om du kommer åt klassen kan skriva MinClass.MinFunktion() utan att behöva skapa objekt..

Men anledningen till det här inlägget är för att spy lite på VB.NET.

Moduler är ett aber som de har med för att VB programmerare skall känna igen sig.. Problemet är att modulerna blir klasser när du kompilerar (allt i .net är klasser eller structer). Vilket förvirrar vb programmerarna....


Nä, all borde skriva i C# så de lär sig .NET på riktigt.

Hmm... Det låter ju rätt logiskt. Fast det är ju bekvämt att (via moduler) ha alla gemensamma funktioner samlade på ett ställe så att man i IDE:n inte behöver fundera på vart någonstans funktionen finns skriven samt att man kan använda samma modulfil i andra projekt (allt för återvinningens skull). Ja, jag går nog till bokaffären imorgon och köper mig en bok och börjar plugga C# på allvar nu...

Moduler är satans verktyg och borde aldrig ha flyttas med VB när de gick över till VB.NET. De är i särklass en av de största anledningarna till att utvecklare som går över till .net med hjälp av VB.NET inte känner till vanliga design mönster så som Singleton.

Och för att ytterligare spä på kritiken (från en som inte ens använder .NET), fast åt ett lite annat håll:
Själva idén med moduler är rent funktionsorienterad och har inget i modern utveckling att göra.
Kan ett begrepp inte härledas till en vettig oo-idé så har den inget att göra i ett språk och bör syntaxmässigt förfulas in i förbannelse för att få folk att sluta använda den.

Intressant att läsa synpunkterna här, för mig som är mest van vid smalltalk.
För några år sedan läste jag en artikel i CS om att när man börjar med objektorinterad programmering bör man först använda Smalltalk, inte C++. Detta för att vänja sig av med hybridprogrammering och lära sig att arbeta helt med objekt.
Med .net och C# har MS kommit ganska nära Smalltalk, så det rådet är överflödigt idag.

Jag brukar skilja på vad som skall vara instansmetoder och klassmetoder, så att om man tänker sig en klass Murare, så är t ex metoden muraVägg en instansmetod, det är något som varje murare gör. Men t ex att svara på brinntid (tiden det tar för murbruket att hårdna) det hör till murarskråets yrkeskunskaper, så det är en klassmetod (i C# "static").
Men man skall vara sparsam med klassmetoder. Har man metoder som återkommer i flera klasser skall man ordna detta med abstrakta klasser och arv. Det som är gemesamt för Hund och Katt kan ligga i Däggdjur. Det som gäller även Groda och Fisk ligger i Ryggradsdjur o s v.
T ex viftaSvans är ointressant för t ex Bil och Skatteskuld, så det skall inte vara åtkomligt för sådana objekt. Alla Ryggradsdjur har inte någon svans att vifta med, men det bör ändå vara en metod för den klassen (svansen är ju en förlängning av ryggraden). De subklasser som inte har svans impementerar den metoden med att göra ingenting, helt enkelt.

- Hans

Hans,

Helt korrekt oop-tänkande - tyvärr är det sånt här som moduler sätter en enorm käpp i hjulet för. Man skriver inte bra kod om man väver in funktionelprogrammering med oop så fort man måste dela någon gemensam funktion.

Hela "kompatibel med vb6 för att locka över vb kodare till .net" saken har gått hemskt fel. Visst kommer folk över, men de stannar i samma gamla banor och tänker sällan utanför lådan. Jag generaliserar inte utan jag har själv kontakt med den typen av utvecklare både privat och på pellesoft, samt att det är ett ganska känt "fenomen/faktum"..

<b>Själva idén med moduler är rent funktionsorienterad och har inget i modern utveckling att göra.</b>

Det beror på vad man menar med moduler. Inte anser du väl att all kod skall ligga i en enda gigantisk fil?

Organisationen av källkoden är egentligen en fråga som programmeraren inte skall behöva fundera över. Det är bara gamla traditioner från C m fl att dela upp i olika filer.
I Smalltalk använder man en enda fil plus en changelog-fil som byggs på hela tiden. Allt man behöver göra är att rensa changelog då och då (en knapptryckning endast), varvid bara den senaste versionen läggs i huvudfilen.
Man ser bara en metod/klassdefinition åt gången (men kan ha flera sådana fönster med varsin metod förstås) och man har olika verktyg för att hitta den metod man vill arbeta med eller titta på.
Filhanteringen är i huvudsak genomskinlig, men för att hantera olika projekt/delprojekt kan man välja ut vad som skall ingå och spara det i separata filer. Sådana projekt kan referera till andra projekt och även helt eller delvis överlappa andra. Men egentligen är själva filhanteringen ointressant.
Det borde inte vara något som hindrar att man använder en databas för att lagra källkod, väl? Det är ju ändå ingen nytta med att sitta och läsa filerna rakt upp och ner, man läser dom ju i klassbläddrare eller liknande, som grupperar och formatterar på lämpligt sätt.
Jag ser att i .net skiner uppdelningen på filer igenom, och jag kan inte få ett fönster som visar bara en metod i taget och inget annat. Det enda jag kan göra är att "fälla ihop" de metoder jag inte arbetar med (kanske har jag missat någon finess där?)

- Hans

Per,

Jag vet inte vad du utvecklar i eller har för bakgrund, men alla som arbetat med VB eller VB.NET känner till vad en "Module" är för något. Resonemanget som först i denna tråden om att moduler inte är en bra idé kräver just att man har en viss bakgrund.

Att VB:s generella moduler (Module) inte hör hemma i en objektorienterad utveckling kan jag hålla med om. Men Niklas Jansson skrev väldigt allmänt:
<b>Själva idén med moduler är rent funktionsorienterad och har inget i modern utveckling att göra.</b>
Det jag ser som "idén med moduler" är att man delar upp sitt program i separata delar som är någorlunda oberoende av övriga delar för att få mer hanterbara delar. Det är alltså samma idé som återkommer i uppdelningen i klasser i OOP. Därför protesterar jag mot att "Själva idén med moduler /.../ har inget i modern utveckling att göra."

Niklas skrev även:
<b>Kan ett begrepp inte härledas till en vettig oo-idé så har den inget att göra i ett språk och bör syntaxmässigt förfulas in i förbannelse för att få folk att sluta använda den.</b>
Är det bara OOP som har ett existensberättigande? Har ni inte sett hur smidigt det kan vara med funktionella språk eller deklarativa språk?

> Att VB:s generella moduler (Module) inte hör hemma i en objektorienterad utveckling kan jag hålla med > om. Men Niklas Jansson skrev väldigt allmänt:
<b>Själva idén med moduler är rent funktionsorienterad och har inget i modern utveckling att göra.</b>

Ja Moduler i VB(.NET) är rent funktionsorienterade tillskillnad från resten av VB.NET som har tagit steget över till en OOP-miljö, därav hör Moduler inte hemma i VB.NET. Så det är nog en tolkningsfråga hur man läser det Niklas skrev =)

<b>Har ni inte sett hur smidigt det kan vara med funktionella språk eller deklarativa språk?</b> Per, du har missat poängen. Hela diskussionen har kretsas kring VB.NET och inge språk-x som måhända är funktionellt eller inte. I VB.NET som är OOP hör Moduler inte hemma. =)