"Ulrik Magnusson" <ulrikm@yahoo.com> wrote in message
news:3AFDBEC9.51990273@yahoo.com...
> Bertel Lund Hansen wrote:
>
> > Ulrik Magnusson skrev:
> > >class B;//forward erklæring - tror jeg nok, det hedder
> > Skal man ikke overveje om ikke det er en designfejl?
>
> Så ville det fantastiske C++ sprog jo ikke have en konstruktion til
> det
(undskyld, jeg kunne ikke lade være..). Er cirkularitet i
Forward erklæringer tjener også andre formål: nedsættelse af
compilerings-afhængighederne og dermed compilerings-tiden.
Givet en klasse "bar", som bruges i interfacet til "foo" (og bemærk "bar"
kender ikke "foo"):
class foo
{
// ...
void foo_func(const bar& bar_arg);
};
har man to muligheder:
// --------------- foo.h --------------------
#include "bar.h"
class foo
{
// ...
};
eller
// --------------- foo.h --------------------
class bar;
class foo
{
// ...
};
og
// --------------- foo.cpp --------------------
#include "bar.h"
// ...
void foo::foo_func(const bar& bar_arg)
{
// ...
}
I det første tilfælde vil alle, der includerer "foo.h" _også_ includere
"bar.h" osv.
I det andet tilfælde vil ingen der includerer "foo.h" automatisk includere
"bar.h" - hvilket giver en hurtigere compilering.
Kun "foo.cpp" vil includere "bar.h"
Der er nogle vigtige relationer:
* Uses-In-The-Interface
* Uses-In-The-Implementation
> klasseafhængighed i øvrigt generelt betragtet som "designfejl" -
> eller i hvert fald noget, som bør undgås?
Som så ofte er svaret ikke blot "ja" eller "nej".
Det kommer an på hvilket niveau vi snakker på. Cirkulære afhængigheder er
roden til _meget_ ondt. Jo længere der konceptuelt er mellem 2 klasser, des
værre bliver det at have cirkulære afhængigheder.
Men man skal aldrig sige aldrig.
Hvis to tæt knyttede klasser hjælpes om at løse en opgave er det vel i
orden.
Hvis to klasser naturligt er relateret - som f.eks. "Kunde" og "Faktura" -
er det vel i orden. Specielt hvis man har en abstrakt bekrivelse (base
klasse) af "Kunde" og "Faktura".
Hvis det giver afhængigheder mellem subsystemer f.eks. "grafisk
brugergrænseflade" og "modem" er det _dårligt_.
Se f.eks. "Large Scale C++ Software Design", John Lakos, ISBN 0-201-63362-0
for en meget god beskrivelse af dette og en række relaterede problemer.
Se også artiklen/kapitlet "Design Principles and Design Patterns", Robert C.
Martin. Det burde kunne downloades fra
www.objectmentor.com. Det giver også
en række gode overvejelser omkring relationer og afhængigheder mellem
klasser.
Venlig hilsen
Mogens Hansen