Gjemme implem. detaljer i en peker?

[South_Bridge]

Sitter å leser litt i min nye favorittbok: Code Complete. God bok med mange nyttige tips til newbs.

 

Men, jeg har kommet over noe jeg ikke skjønner:

 

"... here the implementation details are hidden behind the pointer..."

 

og litt kode:

 

class Employee
{
public:
...
string GetName() const;
...
private:
string m_Name;
string m_Address;
int m_jobClass;
}

 

blir trylla om til

 

class Employee
{
public:
...
string GetName() const;
...
private:
EmploymentImplementation *m_implementation;
}

 

Og der er jeg lost. Hva skjedde med de private variablene? Boka diskuterer at det er bra å gjemme så mye som mulig bort i rare klasser og slikt og tiltaket jeg har beskrevet ovenfor er en av de.

 

Men hvordan er dette mulig, klassen Emplyee må jo kjenne til de private variablene i første kodesegment for å kunne bruke de? Blir det ikke slitsom referering?

[South_Bridge]

etter litt research har jeg kommet frem til at jeg liker å gjemme implementasjonsdetaljer.

 

Hva jeg har funnet ut:

 

Flere bøker (Code Complete og Effective C++) forteller at dette(å gjemme implementasjon) er en god ide. Kanskje ikke for et hjemmeprosjekt, men i større prosjekter har det flere fordeler.

 

1) Man separerer implementasjonsdetaljer og interface (bra for struktur)

 

2) Man får mer dynamisk kode. Feks om man har hele interfacet på plass men skal inn og editere detaljer (mutexer osv) så trenger man ikke å rekopilere hele prosjektet slik jeg forstår det.

 

Dette er et "pattern", hva det kan kalles er jeg litt usikker på (kanskje det ikke har et navn engang).

 

Svar på spm om slitsom referering kan det jo bli litt mye her og der, men det er fullstendig verdt det når man i ettertid bare kan glemme detaljene og jobbe med klassens interface, både enselv og andre i prosjektet.

 

Noen andre som har kommentarer?

[GeirGrusom]

Det fjerner også data vekk ifra stackområdet, som kan være nyttig for å hindre missbruk av programmet.

[Dead_Rabbit]

etter litt research har jeg kommet frem til at jeg liker å gjemme implementasjonsdetaljer.

 

Hva jeg har funnet ut:

 

Flere bøker (Code Complete og Effective C++) forteller at dette(å gjemme implementasjon) er en god ide. Kanskje ikke for et hjemmeprosjekt, men i større prosjekter har det flere fordeler.

 

1) Man separerer implementasjonsdetaljer og interface (bra for struktur)

 

2) Man får mer dynamisk kode. Feks om man har hele interfacet på plass men skal inn og editere detaljer (mutexer osv) så trenger man ikke å rekopilere hele prosjektet slik jeg forstår det.

 

Dette er et "pattern", hva det kan kalles er jeg litt usikker på (kanskje det ikke har et navn engang).

 

Svar på spm om slitsom referering kan det jo bli litt mye her og der, men det er fullstendig verdt det når man i ettertid bare kan glemme detaljene og jobbe med klassens interface, både enselv og andre i prosjektet.

 

Noen andre som har kommentarer?

Jeg tror du oppsummerer hovedgrunnene her. Du refererer til Effective C++, og der forklares det jo veldig godt. Du kan gjøre dette generellt ved å skrive en "handle klasse" (evt. cheshire cat klasse, osv; kjært barn mange navn, osv). I store prosjekter er kompilering et jævla ork, og da lønner det seg fort å gjøre det på denne måten.

 

Når det gjelder å separere interface og implementasjon må jeg si at jeg foretrekker abstrakte baser for å definere interface. Men i de tilfellene der dette blir klønete, så er dette en god måte å gjøre det på.

[[kami]]

dette er en fin måte å unngå for kompliserte arvehierakier. (det er ofte her diskusjonen oppstår)

 

Eks: du lager et spill som skjer på et brett (playfield). objektene på playfieldet kan ha posisjon, navn, være beveglige, etc.

class Positionable 
{
 public: 
   const Vector3& GetPos() const;
   void SetPos(const Vector3& pos) {m_Pos = pos;}
 private:
   Vector3 m_Pos;
};

class Nameable
{
 public:
  const std::string GetName() const {return m_Name; }
  void SetName(const std::string& name) {m_Name = name; }
 private:
  std::string m_Name;
};

// ok, gidder ikke lage de andre klassene men prinsippet bør være oppfatta 
// da kan man enten gjøre det slik..:

class Monster : public Moveable, public Nameable
{

}

// eller slik
class Monster 
{
  public:
   Positionable &GetPositionHandler() {return *m_PosHandler;}
   Nameable &GetNameHandler() { return *m_NameHandler;}
  private:
   Positionable* m_PosHandler;
   Nameable* m_NameHandler;
}

 

Man oppnår akuratt det samme, men i tilfeller kan det være hensiktsmessig med PIMP (pointer to implementation) pattern, for noen ganger med arv ender man opp med tullete greier der man enten har arva baseklassen før (man kan arve virtual her, men da begynner det å lukte b** av leggen), eller funksjonsnavn kræsjer.