Är inte så haj på detta med classer och objektorienterat språk. Men är det inte så att objekt är saker och dessa saker representeras av classer?? Men när man laddar ner ex ett class bibliotek så inehåller det massa klasser som snarare fungerar som funktioner. Hur lägger man upp ett classbibliotek, hur struktureras det, vad ska man tänka på? >Men är det inte så att objekt är saker och dessa saker representeras av classer?? Bara ett litet tips hur di ev identifierar de klasser du vill ha i ett OO baserat system. Annars brukar man ju sammanfatta det så här (även om jag personligen känner visst obehag på tanken):Lite info om objektorienterat.
Vilken typ av kod ska man köra inne i självaset projektet och vilken bör man lägga som externa .dll filer? Har hållit på med ett projekt ett tag nu men det börjar bli lite för stort nu måste ta och strukturera upp det på något sätt. Någon som har några förslag?
MVH Göran PSv: Lite info om objektorienterat.
Ett objekt är en instans av en klass. Klassen beskriver objektets egenskaper och uppförande, tex med property och metoder etc.
>Hur lägger man upp ett classbibliotek, hur struktureras det, vad ska man tänka på?
Du skapar enkelt ett Klass bibliotek genom att du skapar ett Class Library projekt i Vs.Net. Du döper ditt bilbiotek till det namespace du vill ha, detta för att du slipper manuellt gå in och förändra namespacet på alla klasser som du sedan lägger till (Ok, det går att göra detta enkelt genom att gå in på properties för projektet och skriva in vilket namespace den ska använda sig av som standard.) Namespace ska vara ett unikt namn som du kan använda dig av för att tex kategorisera/gruppera dina klasser etc. Det du behöver tänka på är att inte har ett namespace som slutar med samma namn som någon av dina klasser som ligger inom namespacet tex: Namespace MyCompany.MYProdukt.User så skapa inte en klass som heter User här under.
I SDK:n finns det en developers guidelines som beskriver detta och förslag på hur du kan namnge klasser, variabler etc.
Öppna .Net Framwork SDK och gå till:
.Net Framwork SDK/References/Design Guidelines for Class Library
Tycker jag att du ska läsa. Ett klassbibliotek resulterar sedan att bli en egen dll (Assemlby).
Om du skapar ett projekt och du vill gruppera klasser i egan klass bibliotek så skulle jag rekommendera att du skapar en solution där du lägger upp flera de klassbiblioteks projekt som du vill ha och refererar till dom genom en projekt refenrece. Om ändå din applikation ska använda sig av de klasser som ligger i klassbibliotekten så är det onödigt att skapa solutions för varje klass (Alltså skapa upp assemblys separat, du kallar dom kanske för externa dll:er), kan även vara onödigt att skapa klassbibliotek för vissa mindre applikationer. Men med hjälp av klassbiliotek så kan du strukturera upp dina applikationer bättre. Ett exempel är att du skapar ett klassbibliotek per lager du använder dig av, tex ett klass bibliotek för datalagret där du har dina Data Access klasser och en för ditt affärslager där du har dina affärslogiks klasser etc. Tänk på att om du skapar för många klassbilbiotek så har du många dll:er som du måste hålla reda på.
Hoppas detta kan hjälpa dig något när det gäller att strukturera dina applikationer.
Andra tips när det kan vara bra att skapa Class library.
* När du ska lägga en assembly i GAC:en då måste den ha ett strong name.
* När du ska anvädna dig av Enterprise Services (COM+)
Det beror helt och hållet på va du ska bygga för lösning och hur den ser ut.
Samt lite tycke och smak.
/Fredrik NSv: Lite info om objektorienterat.
Skriv ner ett Usecase som förklarar en händelse.
Ex.
En spelare kastar två träningar, om resultatet blir 7 har man vinnut annars inte.
Nu gäller det att plocka ut verklighetsbaserade objekt. (Substantiven i texten ger hjälp)
"Spelare,träning"
Sedan kan du plocka ut verben för att ev identifiera verkliga händelser.
"Kasta"
Du har då två objekt "Spelare och Tärning" sedan händelsen "kasta"
Spelare --> Kastar ---> Tärning
Nu behöver man gå lite djupare ner och identifiera vad det är som ev kastar tärningarna, i vår värld blir det vi själva men i datans värld är det ju ett spel.
Spel --> Starta Spel --> Kastar --> 2*Tärning
Nu har vi hittat Spel klass samt Tärnings klass.
Spel hade metoden StartaSpel och tärning Kasta. En tärning har ju oxå sidor med nummer, och eftersom vi måste ha ut ett reultat så passa attributet SidNummer in ganska bra i klassen tärning, Eftersom dessa klasser hör ihop så blir ett bra namespece ex: Mitt.TärningSpel och båda klasserna kan läggas i en och samma DLL då de tillhör samma kategori eller namnrymd eller vad man vill kalla det.
Kod exempel:
<code>
public class Spel
{
public void StartaSpel()
{
Träning tärning1 = new Tärning();
Träning tärning2 = new Tärning();
tärning1.Kasta();
tärning2.Kasta();
if(tärning1.SidNummer + tärning2.SidNummer == 7)
Colsole.WriteLine("Du vann!");
else
Colsole.WriteLine("Du förlorade!");
}
}
public class Tärning
{
public int SidNummer;
public void Kasta()
{
... Någon random metod av något slag...
SidNummer = Resultat;
}
}
</code>
Detta var bara ett snabbt utkast på hur du kan identifiera dina klasser. Sedan hur du delar upp assemblys m.m. är en annan historia, tror Fredrik Hade en bra förklaring som kan hjälpa dig. Att lära ut OO samt design är inte lätt i ett forum. Jag föreslår att du läser en del böcker om ämnet. Särkilt då det kräver en annan tanke gång som man oftast inte är van vid.
Hoppas detta gav dig lite info. Du kanske redan hade koll på detta?
//Johan NSv: Lite info om objektorienterat.
Skriv ner allt som programmet skall göra, ganska detaljerat.
Stryk under alla substantiv ("substantiv är namn på ting, såsom klocka, boll och ring" =) )
Det är dina klasser.
Kolla sen på alla verb. Det är dina metoder.
--
Sen brukar man väl iofs försöka komma på vad substantiven består av, om man kan dela in de i grupper, osv. och på det sättet göra relationer. T.ex. "Bla, bla, bla...bilar...lastbilar...personbilar..."
Hmm... alla lastbilar är ju bilar, och det är personbilar också. En Är-En-relation, alltså, som representeras genom ett publikt arv. (nu är jag ute på djupt vatten, kan inte c# tillräckligt bra).