---

Sidder og læser en bog om objekt orienteret analyse og design, og kommer
helt i tvivl om hvad OO nu egentlig er.

Normalt skriver jeg c++ programmer sådan at der er en masse objekter, som
jeg anvender som værktøjer, og disse anvendes af alm struktureret kode. Det
er altså ikke som i java hvor alt er et objekt.. elelr som i delphi og c++
builder.

Betyder det at det ikke er helt objekt orienteret ?

Ex lidt pseudo
main()
{
crate object A(some param);
A.doSomething();
create B;
give B to A;
hvis B.etellerandet så A.gør noget andet;
..
..
..
}

---

Hans skrev:

>Betyder det at det ikke er helt objekt orienteret ?

Selv Java er ikke helt objektorienteret. Der findes numeriske
typer som er simple.

Når vi løste opgaver på min datamatiker uddannelse, skrev vi
mains af samme type som din. Det hørte vi aldrig noget for.

Jeg skal dog ikke kunne sige om vores løsninger var "helt OOP",
for måske er mine lærere lige så ligeglade med det som jeg er? De
lagde mere mærke til om koden var velstruktureret og logisk
bygget op.

Sidebemærkning:
I sin tid da jeg opgraderede fra Turbo Pascal 4 til 6, læste jeg
flittigt i dokumentationen (den var suverænt god). TP6 har en
slags OOP-mulighed som jeg dog aldrig er blevet fortrolig med.
Men bogen var uhyre stolt af (mit indtryk) at det var lykkedes at
reducere main til (efter hukommelsen):

Begin
   myprogram.init;
   myprogram.run;
   myprogram.close;
End.

Den dybere mening med det gik aldrig op for mig.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

> Når vi løste opgaver på min datamatiker uddannelse, skrev vi
> mains af samme type som din. Det hørte vi aldrig noget for.

Næ, og det er da også sådan man gør i praksis, de steder jeg har arbejdet.
Problemet er bare at praksis ikke behøver være korrekt.
Det er vel strengt taget heller ikke helt stuerent at bruge printf, fopen
ect. istedet for c++ streams når man nu koder c++.
Det er desværre en vane jeg har svært ved at aflæge mig, eftersom jeg lærte
c før c++ og pascal før det.

> I sin tid da jeg opgraderede fra Turbo Pascal 4 til 6, læste jeg
> flittigt i dokumentationen (den var suverænt god). TP6 har en
> slags OOP-mulighed som jeg dog aldrig er blevet fortrolig med.
> Men bogen var uhyre stolt af (mit indtryk) at det var lykkedes at
> reducere main til (efter hukommelsen):
>
> Begin
> myprogram.init;
> myprogram.run;
> myprogram.close;
> End.
>
> Den dybere mening med det gik aldrig op for mig.

Det er samme system som delphi og c++ builder bruger nu.
Jeg kan heller ikke helt se det fantastiske ved at skrive sin kode i en
run-metode istedet for i main. Måske fordi det indkapsler en del flere
globale funktioner og variabler. Det ser pænt ud, men i praksis gør det
næppe nogen forskel.

Er da glad for at høre at du oplever OOP på samme måde som jeg gør. Bare min
bog der objekt-snobber tror jeg.

---

Hans skrev:

>Det er vel strengt taget heller ikke helt stuerent at bruge printf, fopen
>ect. istedet for c++ streams når man nu koder c++.

Der prøver jeg nu at bruge C++-kommandoer, bl.a. fordi
strenghåndteringen er meget bedre. Men jeg skriver også kode i
ren C.

>Det er desværre en vane jeg har svært ved at aflæge mig, eftersom jeg lærte
>c før c++ og pascal før det.

Tænk, jeg kender lige præcis problemet for det var også den
rækkefølge jeg lærte det i.

>Er da glad for at høre at du oplever OOP på samme måde som jeg gør.

Måske misforstod du det. Jeg er skam uhyre glad for at jeg nu har
lært OOP rigtigt. Det er mere TP's pseudomodel jeg ikke brød mig
om. Jeg fuskede lidt med at rette i eksempelkode, og det var
noget med

new(detene(detandet(dettredje(detfjerde(detfemte(detsjette))))))
- og det så bare sygt ud.

Nu har jeg prøvet OOP med Java og C++, og det er en ren
fornøjelse.

>Bare min bog der objekt-snobber tror jeg.

Det er jeg ikke blevet. Jeg syntes at det virkede befriende
engang Henning Makholm svarede på mit spørgsmål med (ca.):

   Hvis man er den type der sovser det hele ind i OOP, så
   siger man ..., men ellers siger man bare ...

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> writes:

> Hans skrev:
>
> >Det er vel strengt taget heller ikke helt stuerent at bruge printf, fopen
> >ect. istedet for c++ streams når man nu koder c++.
>
> Der prøver jeg nu at bruge C++-kommandoer, bl.a. fordi
> strenghåndteringen er meget bedre. Men jeg skriver også kode i
> ren C.

'imho', er det vel ligegyldigt om man bruger funktioner/metoder, dvs.
om man bruger main() eller objekt.doit(). OOP er en maade at strukturere
sig paa, om man saa end vaelger at implementere det i et funktions-baseret
sprog, eller - lidt nemmere - i et sprog der rent faktisk er bygget til det.

f.eks. er der ingen der forhindrer nogen i skrive noget polymorft i c,
men man vil nok spare mange linjers kode (og lidt riven i haaret) hvis man
vaelger c++ istedet .


Hygge,

--
___
Soren Davidsen / o\
Math student, ICSMA (_____)
__ http://www.tanesha.net/ _________________________________(___)_______

---

Soren Davidsen skrev:

>'imho', er det vel ligegyldigt om man bruger funktioner/metoder, dvs.
>om man bruger main() eller objekt.doit(). OOP er en maade at strukturere
>sig paa, om man saa end vaelger at implementere det i et funktions-baseret
>sprog, eller - lidt nemmere - i et sprog der rent faktisk er bygget til det.

Det har du ganske ret i.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

In news:bvjb7vcu2i2qesct18r9tl4251jcrot4rf@news.stofanet.dk,
Bertel Lund Hansen <nospamfor@lundhansen.dk> wrote:

> Hans skrev:
>
> Selv Java er ikke helt objektorienteret. Der findes numeriske
> typer som er simple.

Dog har java objektorienterede versioner af int, floats osv...

primitiv. objekt.
int Integer
double Double

osv...

--
Michal
[ echo "\$0&\$0" > _; chmod +x _; ./_ ]

---

Michal skrev:

>> Selv Java er ikke helt objektorienteret.

>Dog har java objektorienterede versioner af int, floats osv...

Øh ... ja. Det har også hundredevis af andre objektorienterede
fiduser.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

In news:u1sn7vo63f17ae2475trhasg0kosubar8l@news.stofanet.dk,
Bertel Lund Hansen <nospamfor@lundhansen.dk> wrote:

>>> Selv Java er ikke helt objektorienteret.
>
>> Dog har java objektorienterede versioner af int, floats osv...
>
> Øh ... ja. Det har også hundredevis af andre objektorienterede
> fiduser.

Ja ok, det har du ret i...

--
Michal
[ echo "\$0&\$0" > _; chmod +x _; ./_ ]

---

Hans wrote:
> Sidder og læser en bog om objekt orienteret analyse og design, og kommer
> helt i tvivl om hvad OO nu egentlig er.
>
> Normalt skriver jeg c++ programmer sådan at der er en masse objekter, som
> jeg anvender som værktøjer, og disse anvendes af alm struktureret kode. Det
> er altså ikke som i java hvor alt er et objekt.. elelr som i delphi og c++
> builder.
>
> Betyder det at det ikke er helt objekt orienteret ?
>
> Ex lidt pseudo
> main()
> {
> crate object A(some param);
> A.doSomething();
> create B;
> give B to A;
> hvis B.etellerandet så A.gør noget andet;
> .
> .
> .
> }
>
>
Der er ikke rigtig nogen vej uden om at 'main()' SKAL være en global
funktion (eller 'WinMain()' hvis man programmerer Windows), så der er
intet galt i hvad du gør. Efter main lader jeg personligt objekter gøre
alt arbejdet, men man er jo nødt til at kalde funktioner fra C API'er en
gang imellem, men dem pakker jeg oftest ind i C++ objekter.
Personligt ser jeg dog intet galt i at man laver almindelig C kode her
og der med structs og globale funktioner. Det har vi også gjort alle de
steder jeg har arbejdet, men derhjemme holder jeg min kode så C-fri som
muligt.

Men igen...det er et spørgsmål om holdning og religion.

Robert

---

Hans wrote:

> Sidder og læser en bog om objekt orienteret analyse og design, og kommer
> helt i tvivl om hvad OO nu egentlig er.

[klip]

Ahh, den "Røde fanden" af Jan Stage mfl. ? :)

Du skal nok skelne mellem "Objektorienteret programmering" (OOP) og
"Objektorienteret analyse og design" (OOA&D), i hvert fald havde jeg
selv problemer med at skille disse to af i starten. For at den sidste først:

OOA&D er en metode til at modelere et problem/opgave. Gennem analyse af
problemområde og anvendelseområde kan man, hvis processen er vellykket,
konstruere klassediagrammer, tilstandsdiagrammer, hændelsestabeller m.m.

Udfra disse kan ret præcist identificere klasser, metoder, flow osv. som
gør selve kodearbejdet (OOP) relativt nemt og veldefineret.

Håber det hjalp lidt.


--
Mvh
Tonni Aagesen
<agent29 AT stofanet DOT dk>

---

> Ahh, den "Røde fanden" af Jan Stage mfl. ? :)

Ja..!!?! Hvordan pokker kunne du gætte det?
Ja, det er den bog. En skodbog, synes jeg. Ville hellere finde mig en der
tog en mere programmørvenlig indgang til emnet, end denne bogs højtravende
teoretisering.

> Du skal nok skelne mellem "Objektorienteret programmering" (OOP) og
> "Objektorienteret analyse og design" (OOA&D), i hvert fald havde jeg
> selv problemer med at skille disse to af i starten. For at den sidste
først:

Tja.. det er vel rigtigt nok. Så bare gerne en tydelig linie mellem analyse
og design og implementering.

> OOA&D er en metode til at modelere et problem/opgave. Gennem analyse af
> problemområde og anvendelseområde kan man, hvis processen er vellykket,
> konstruere klassediagrammer, tilstandsdiagrammer, hændelsestabeller m.m.
>
> Udfra disse kan ret præcist identificere klasser, metoder, flow osv. som
> gør selve kodearbejdet (OOP) relativt nemt og veldefineret.

Det er nok fordi skridtet fra det rent analytiske design til kodningen
virker lidt stort og ud-i-mørket agtigt for mig.

Dog sjovt at du kunne gætte bogen

---

Hans wrote:
>>Ahh, den "Røde fanden" af Jan Stage mfl. ? :)
>
> Ja..!!?! Hvordan pokker kunne du gætte det?

Nu var det ikke mig der gættede men jeg tror jeg kender svaret.
Det er en klassiker på danske universiteter/datamatikerstudier fordi den
er skrevet af danskere. Ikke fordi den er god....eller middelmådig. Den
er på dansk og det er dens eneste force efter de fleste programmørers
mening (dem jeg kender i hvert fald). Teoretikerne derimod savler den
til i løbet af den første måned.

Hvis du vil have en bog som beskriver en tilgang til analyse og design
som er mere "programmør venlig" kan jeg anbefale "The Unified Software
Development Process" af Ivar Jacobson, Grady Booch og James Rumbaugh.
Eller måske nogle af Extreme Programming serien (jeg har aldrig læst
bøgerne men information fra Internettet siger mig at denne metode er ca.
som jeg altid har arbejdet).

VH

Robert

---

> Eller måske nogle af Extreme Programming serien (jeg har aldrig læst
> bøgerne men information fra Internettet siger mig at denne metode er ca.
> som jeg altid har arbejdet).

Osse mig, men jeg er tæt på at opgive at fortælle kollegaer om metoden, idet
den lyder så dirty. Nej hellere bruge masser af tid up-front på at
specificere, tegne i Visio (iøvrigt mener jeg at Visio bør udslettes), og
lave descision-points og design-locks og fasemodeller. Det føles så rigtigt.
Når én eller anden chef/projektleder/kunde vil have en feature mere, løber
vi alligevel efter alle disse design-creeps og diagrammer og
projekt-fase-modeller kan stikkes skr.. .. , eller de kan opdateres hvis man
synes man orker.

Det er ikke planlægning og design jeg er imod. Det er illusionen om at man
har det hele med, og resten kommer nogen til at betale ekstra for / give os
mere tid til, jeg er imod.
Nærmere fungerer det sådan at når vi er gået over tiden, får vi
syndsforladelse proportionalt med den mængde feature-creep vi har måttet
udholde.
(ahhh dejlig at slippe af med lidt galde)

mvh Troels

---

Hans wrote:

> Ja..!!?! Hvordan pokker kunne du gætte det?

Well, den står i min bogreol, og som Robert skriver, er den meget brugt
i Universitets- og datalogisammenhænge.

> Det er nok fordi skridtet fra det rent analytiske design til kodningen
> virker lidt stort og ud-i-mørket agtigt for mig.

Jeg havde et par "aha-oplevelser" da jeg først havde brugt et helt
semester på metoden og derefter kode et program udfra analyseresultatet.
OOA&D er iøvrigt, efter min mening, også et overkill til de fleste
projekter, hvis man skal følge metoden til punkt og prikke.


--
Mvh
Tonni Aagesen
<agent29 AT stofanet DOT dk>