C++ udfordring

Regnemaskine
Pacman
Kryds og bolle
Addressebog

-en AI psykolog, som man kan tale til via tekst
-en text imager, en der laver tekst billeder ud af billeder,
burde vil kunne lade sig gøre
-Et Dungeons og Dragon spil(tekst).
-Random file generator(hvad man skal bruge den til ved jeg ikke men det var godt nok sjovt at lave den
-En kalender er nok temmelig svært men vel egentlig ikke umugligt, hvor man kan sætte helligdage fødselsdage, møder, etc.. alt.

Hvis du lavede dem ville du have lært-
c++ tids funktioner nogle af dem
c++ random funktioner
c++ skrive og læse fra en fil
Game logic
Billedbehandling
AI porgrammering
STL data handlers formentlig
OOP ville gru hvis du ikke lærte det undervejs lol.


PS af ovenstående har jeg kun selv lavet fil generatoren

OOP ville gru hvis du ikke lærte det undervejs lol.

Hmm...OO er ikke noget man lærer af at kode. Slet ikke hvis man bruger tutorials fra nettet....snarere tværtimod.

Helt enig. De er sommetider meget misvisende i deres synspunkter.

Han lærer måske ikke OOP til et 13 tal af det men han ville da formentlig lære at lave en klasse, evt. nedarvinger. Mens hvis du med OO mener at lave diagrammer analyse, etc.. så nej det lærer han nok ikke og tvivler stærkt på at særligt mange her bruger det til deres fritidsprojekter .


Og mens jeg er ved det kunne han lave følgende:
-Et program der udregnet de mest hensigtsmæssige afrejsetidspunkter fr interplanetare rejser i et hvert solsystem.
-Det sædvanlige kedelige Guess A Number spil, med statistik over det gennemsnitlige antal af gæt, det maximale, det minimale, det totale.
-Yatzy er det eneste terning spil jeg lige kender med multiplayer funktionalitet.


PS. af ovenstående har jeg kun lavet Guess A Number uden statistic.

Apropos OO; jeg vil her anbefale at der bliver brugt et domain-driven design, da det giver en større fleksibilitet i applikationen og i dens domæne.

For artikler om arkitektur, se også min blog

http://jessn.blogspot.com


Hth

Jeg har aldrig hørt om "domain-driven design" hvad er det og hvordan adskiller det sig fra bare at kode løs?

Jeg ved ikke hvordan man lærer at lave OO design, det er vist mest noget der kommer af sig selv når man ser mulighederne.

Han lærer måske ikke OOP til et 13 tal af det men han ville da formentlig lære at lave en klasse, evt. nedarvinger. Mens hvis du med OO mener at lave diagrammer analyse, etc.. så nej det lærer han nok ikke og tvivler stærkt på at særligt mange her bruger det til deres fritidsprojekter .

Are you kidding ???
Jeg bruger OO og ordentligt design til alle projekter. Det giver for mange dårlige vaner at lade være.
OO har intet med diagrammer at gøre. Det er orienteringen mod brug af objekter. Klasser og arv gør ikke automatisk kode objekt orienteret.

Igennem årtier har man anvendt lagdelt arkitektur, hvor man har placeret forretningslogikken på domæne objekterne. Det giver nogle utrolig store og klodsede domæne objekter idet forretningslogikken ligger sammen med disse og en ændring af domæneobjekterne bliver derfor også kompleks.

-- snip --
Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.
-- snip --

I de seneste år er man begyndt at adskille forretningslogikken fra domæne objekterne, så domæne objekterne kun indeholde domæne data. Forretningslogikken bliver i stedet placeret i forretningslaget og domæne objekterne bliver sendt op/ned igennem alle lagene.

Når man skal hente data fra databasen vil man modtage en eller flere domæne objekter. Persisteringen vil ligeledes ske ved at gemme en eller flere objekter igennem ens dataaccess lag.

Eksempel på del af interface på dataaccess laget:

std::vector<Person*> HentPersoner()
Person* HentPerson(const char * navn)
GemPerson(Person* person)

Forretningslaget manipulere herefter disse domæneobjekter i henhold til de gældende forretningsregler og de vises i præsentationslaget. Det kunne for eksempel være en række person objekter som vises i en listbox.

Hth

Jess, tak for forklaringen, jeg er dog ikke sikker på at jeg blev klogere...