items i mitt rpg spel

Men eftersom alla items ska ha ett namn och info borde inte det gå att lägga i Item? känns onödigt att repetra soma kod 5-10 ggr ...

Man tappar liksom vitsen med arvet då. Normalt sett så brukar man skriva en wrapper-klass vid denna typ av problematik.

"Keep it simple" är ett bra måtto.

Vad är en wrapper klass?

Det här funkar ju inte allt för bra.

	for (i=0;i<10;i++)
	{
		cout << "  Slot #" << i+1 << ": " << player.slot[i]->getName() << "\n";
	}

En wapperklass är ett skal utanpånått för att förenkla för "omvärlden". Vanligtvis är detta en templateklass. Det beror lite på hur många Items du har tänkt att ha. Om det är bara de 6 som finns ovan så tycker jag det känns väldigt mycket som att gå över ån efter vatten att försöka göra en mer avancerad, generell lösning. Hur som helst så har du ju ändå problematiken att avgöra vad det är för nått som ligger i arrayen och då måste du ha ett fält för att tala om vad det är för nått. För mig känns det väldigt onödingt i alla fall att försöka göra en snygg objektorienterad lösning på ett relativt litet problem. Det enda saken som alla Items har gemensammt är ett namn.

Men eftersom alla items ska ha ett namn och info borde inte det gå att lägga i Item? känns onödigt att repetra soma kod 5-10 ggr ...

Vitsen med hela mitt förslag är ju att Item blir en wrappning över alla små objekt så att man lätt kan svepa över dem utan att behöva hålla reda på vilka dem är i koden (dvs dynamiskt). Visst blir det något "mer" kod i själva klassdefinitionerna, men vid implementeringen blir det mindre (totalt blir det inte sämre) och väldigt lätt att korrigera in nya grunkor/egenskaper i efterhand. Kan hålla med Beatbox om att det kan vara overkill... men samtidigt vinner du 2 saker. Dels lärdomen om tillämpning av ren OOP och dels utbyggbarheten.

Vad man tycker är "lätt" kan väl variera från ens erfarenheter, men så här vinner man som sagt en del i kodstilen. Jag har själv satt ihop flera spel med samma teknik och för mig är det nice att i efterhand enkelt kunna uppdatera, förändra m.m... + att man många ggr vinner i tidskomplexitet mot strukruterad programmering, något som ofta är knepigt vid grafik.

Gjorde som beatbox föreslog och som jag hade innan.
Har bara en item klass med alla variabler i och en för vilken sorts item det är.

Blev så många problem jag inte lyckades lösa med PeWs förslag. Kanske får ändra när jag har lärt mig mer c++ :)

Jag tror att det va lite brister i designen. Klassen Item va lite FÖR abstrakt. Den skulle ju kunna passa in på precis vad som helst. En Creature skulle till och med kunna ärvt från Item. Om man tänker sig att karaktären har en ryggsäck där det finns 8 fack för saker. Bristen i designen va att man kan inte förutsätta att alla typer av Items "får plats" i facket. Det är då wrapper-lösningen kommer in. Adaptor brukar man kalla sånt. För att ta ett litet exempel. För att geväret ska rymmas i ett av facken i ryggsäcken så måste man skruva isär den och sätta ihop den då den ska användas. Programmatiskt så kallas denna lösning för en adaptor-lösning där adaptorn sköter "skruvandet". Att säga att varje fack i ryggsäcken tar ett Item är typiskt väldigt dålig design eftersom Item kan va i princip vad som helt, typ en Jumbojet. Vitsen med OO-programmering är ju att man ska bryta ned problemet och det ska också gå att ta färdig kod och härleda tillbaka till ursprungsproblemet och förstå vad man gjort. :)

Beatbox ->
Det du beskriver är precis det jag eftersträvade med mitt förslag och genom en abstrakt basklass wrappar du alltihop . Men om man väljer att använda mitt förslag och sen ändå falla tillbaka på "hybrid" & strukturerat stilsätt (såsom C++ tyvärr inbjuder till) förlorar man klart vitsen med det hela. Orkar inte med en fjantig debatt om vad som är ditten och datten, men samma stuk på design går igen i Java och andra rena OOP-språk. Det handlade alltså om att närma sig OOP mer än att progga med C++'s alla möjligheter som tyvärr ofta genererar fulprogrammering ur mina ögon sett.

Däremot kan jag hålla med dig om att i just AlphaII,s lilla konsolprogram skulle templates kan funka smutt. Och det har jag redan förklarat tidigare ;)

Har bara en item klass med alla variabler i och en för vilken sorts item det är

Det trista med den lösningen som du visade innan är åtkomsten. Visst funkar det, men det blir desto jobbigare att implementera och det strider mot OOP:n ;)

Vitsen med OO-programmering är ju att man ska bryta ned problemet och det ska också gå att ta färdig kod och härleda tillbaka till ursprungsproblemet och förstå vad man gjort

Nope.
Vitsen med bra algoritmer är att bryta ned problemet, vitsen med en analys och design är detsamma. Men ren OOP handlar om att gömma data och bygga en miljö som är ointressant för programmeraren i detalj. Med mitt förslag går det alldeles utmärkt att återanvända kod och att bygga vidare. Det man vanligtvis menar med adaptor är exakt det som Item i det här fallet är - en abstrakt modell som man helt enkelt "kopplar" upp sig mot.

OO-programmering går ut på att genom en iterativ process bryta ned problemet "i verkligheten" till förståliga beståndsdelar så det blir lättare att lösa problemet i något OO-språk. Det är en hörnstenarna i OO-programmering. Algoritmer är ju bara ett sätt att lösa delpropblem, beskriva ett arbetssätt. Själva designen är hur programmet är strukturerat och hur data flödar mellan de olika delarna i programmet.

*suck*

Har inte sagt nåt annat heller, vad det gäller OOP, du fyller bara i det jag INTE skrev... :OO
Mitt förslag var (som redan klartgjorts tidigare) en visning åt ett håll och inget färdigt program. Den tekniken jag påvisar behöver mer än vad jag skrivit, men det lämnar jag till AlphaII att lösa - om han nu blev intresserad av den lösningen. Det jag finner märkligt är att du dissar nåt med argument som inte finns - (dvs det du argumenterar som saknat är precis det som redan finns) ist för att då fylla i de luckor som fanns i det ofärdiga förslaget.

Som jag skrev tidigare (keep it simple), dvs lägg allt i en klass. Det är ett väldigt konkret förslag på lösning. Om det inte framgick tidigare så tyckte jag designen verkade lite avvikande och ändra designen så fort man måste lägga till nått brukar va ett tecken på att man inte lyckats med designen. Jag brukar då skrota hela lösningen och designa om det som misslyckades för att se om det blev bättre. Nu tyckte jag problemet va så pass litet så för min del kändes det onödigt att lägga ned allt för mycket energi på designen av lösningen.

Beatbox, du har ju helt fel ;)

Det är ett väldigt konkret förslag på lösning

Nej, det enda konkreta är ditt egna förslag och din sågning av mitt (med felaktiga argument)

så tyckte jag designen verkade lite avvikande och ändra designen så fort man måste lägga till nått brukar va ett tecken på att man inte lyckats med designen

Ingenstans i det jag skrivit ska man ändra i designen, snarare tvärtom. Att lägga bygga på med fler/nya egenskaper (metoder) är inte alls detsamma som att förändra designen. Tror nog att du blandar ihop begreppen... ;) Mitt förslag var simpelt och effektivt - om man vet hur att implementera det och förstår fördelen och flexibiliteten med dynamisk bindning.

Nu tyckte jag problemet va så pass litet så för min del kändes det onödigt att lägga ned allt för mycket energi på designen av lösning

Visst, och så även jag. AlphaII får ju välja själv. Han frågade om mitt förslag och jag svarade...
Jag föredrar att koda så abstrakt som möjligt och tydligen kör du med mer "statiskt" och strukturerat... finns ingen anledning att dissa det ena eller det andra då bägge lösningarna har sina poänger. Men det ena är mer OOP än det andra ;) Jag har påvisat en teknik - om trådskaparen vill använda den eller ej är upp till denne. Det jag opponerera mig emot är dina argument på det jag lade fram - inget annat.