Klasser og funkktioner fordle ulemper

Et meget stort spørgsmål, som kloge folk har skrevet stakkevis af tykke bøger om.

At putte en funktion ind i en klasse og fortsætte somom alt er som før løser jo ikke noget problem.

At bruge klasser hænger sammen med Object Orienteret programmering, og er en helt anden måde at betragte et problem, end ved funktions baseret programmering.

Ved funktions baseret programmering vil man sige at man har et problem; jeg skal skrive noget til skærmen, så jeg laver en række funktion og variable der kan bruges til det. Brugeren kalder så disse funktioner, med diverse variable.
Ved OO programmering vil man sige at jeg har et interface, en skærm, så laver man et interface, en class, som implementerer alt vedrørende skærmen. Når brugeren skal skrive til skærmen laver han instans af klassen og bruger den til at tegne med.
Det smarte kommer så når man vil skrive til en anden type skærm. Ved funktions baseret programmering vil man lave et nyt sæt funktioiner og variable til denne nye skærm. Ved OO programmering vil man blot lave en ny variation af klassen (ny nedarvning), og fortsætte som før.

Det tager tid at lære at programmere, og det tager ekstra tid at lære at lave ordentlig OO programmering. Men når først man kan det, får man et helt nyt sæt muligheder.

Et meget stort spørgsmål, som kloge folk har skrevet stakkevis af tykke bøger om.

Jeps. Lærerne på datamatiker uddannelsen (hvor jeg gik) lovpriste OOP, og brugte megen tid på at forklare alle fordelene, men det var først efter at have brugt OO i et par år at jeg rigtig begyndte at sætte pris på det, så hvis du ikke helt har set lyset endnu så fortvivl ikke.

Når du har kodet lidt og er begyndt at forstå begreberne (arv, polimorfi, instanser, osv.), kan jeg anbefale dig at kigge lidt på Design Patterns (søg google tynd eller køb en bog). Design patterns viser virkelig hvor smart OO er, men det kræver desværre lidt at man ved, hvad der snakkes om, før man rigtig forstår dem.

Det starter med at du vil lave en struct til at repræsentere en firkant:
struct Firkant
{
int left, right, top, bottom;
};

Så en dag finder du ud af at det var smart med en måde at beregne arealet på denne, skal det være en normal funktion eller en funktion i class'en? Hvis du vælger der sidste.

struct Firkant
{
public:
int left, right, top, bottom;
int area() { return (right - left)*(bottom - top); }
};

Så kan du skrive
Firkant X;
...
int area = X.area();
istedet for
int area = areal(X);
Så laver du
Firkant::offset(int x, int y);
til at forskyde Firkant i X og Y retning.

Så finder du ud af det ville være smart om du kunne skrive koordinaterne til en fil med:
Firkant T;
FIL << T << std::endl;
Og læse på samme måde.

En dag finder du ud af at du vil have en cirkel, med ca. de samme egenskaber, så laver du en Cirkel class, men det var jo smart om man lavede den "virtual base class" som både Firkant og Cirkel (og trekant og ...) arvede fra. Og inden du har set dig om har du fåat brug for en "virtual constructor" og ...