Tuossa koodailin huvikseni hieman C++:lla ja samalla lueskelin juttua nk. Design Patterneista, jotka ovat yleisiä hyväksihavaittuja tapoja ratkaista jokin ongelma. Keksin itse yhden uuden Design Patternin, jolle annoin nimeksi Pimp.
Ongelma: Sinulla on luokka A jolla on private muuttujia. Haluaisit päästä muuttamaan ko. muuttujaa tiettyjen luokkien sisältä, mutta et halua tehdä luokkaan suoraa funktiota joka sallisi muuttujan arvon muuttamisen (esim jos muutettavia arvoja on monta).
Ratkaisu: Teet luokan B, joka on luokan A friend-class. B toimii tässä tapauksessa nk. parittajan ominaisuudessa. Luokka C voi kysyä B:ltä jonkin tietyn A:n instanssin privaattidatan osoitetta muistissa, jota käyttämällä B pystyy suoraan muuttamaan A:n privaattidatan arvoa. Helppoa, eikö totta?
Allaolevien listausten pitäisi selventää asiaa.
class Pihi { friend Pimp; private: // Tähän ei normaalisti pääse käsiksi int mIntiimi; };
class Pimp { public: // Hakee privaattidatan osoitteen int *parita(Pihi *pihi) { return &pihi->mIntiimi; } };
class Asiakas { void Nysvaa() { // Luodaan luokista instanssit Pimp pimp; Pihi pihi; // Haetaan privaattidatan osoite int *osoite = pimp.parita(pihi); // Muutetaan datan arvoa *osoite = 1; } }
Ainiin, laittakaa kysymyksiä tai kommentteja jos löytyy.
Kalan mielikuvitus tässä esimerkissa on vähän _öö_.. kuitenkin ihan hyvä esimerkki..
Mutta kyllä täytyy myöntää että nuo nimet on kuvaavia :) Hyvä esimerkki...
:DD Aikas härski jätkä toi kala ;)
*nauraa*
siis iha hyvä esimerkki mutta noi nimet on vuodenparhaat ;D
no huumoria pitää olla mukana... ja hyvä että niitä on koodissakin :D
En nyt haluaisi olla mitenkään tyly, mutta tämä design patterni on ihan perseestä ja turha. Paremminkin tämä on anti-pattern.
Perustelut:
- Pimp rikkoo Pihin kapseloinnin, joten yhtä hyvin Pihin memberit voisivat olla publiceja. Koska Pimp:n jakelua ei mitenkään voi hallita (paitsi esim sulkemalla DLL:n sisään, mutta silloin voisi Pihi:n memberien piilottamisen hoitaa muutenkin abstraktilla rajapinnalla), on aivan sama ovatko Pihin memberit publiceja vai privateja. Jos halutaan kontrolloida kuka pääsee Pihi:n privateihin käsiksi laitetaan nämä luokat Pihin friendeiksi. Patternissa ei ole ns. järjen häivää. Hyöty on -42 (menetetään tyypitys ja rikotaan kapselointi täysin).
- Pimp ei ole type-safe. Jos Pihin membereitä käytettäisiin suoraan olisi koodi type-safe.
- Pimp-luokkaa pitää laajentaa, joka kerta kun Pihi luokkaan tuodaan eri tyyppisiä membereitä.
Pihin esittelyssä on muuten vielä sellainenkin vika, että luokan friendit pitäisi esitellä friend class <luokannimi> eikä friend <luokannimi>. Jälkimmäinen tapa on epästandardi eikä toimi kaikilla kääntäjillä.
Jos haluaa tehdä asiat oikein, niin kannattaa hieman ottaa selvää mitä esim. perinnällä voi hanskata. Joissakin tapauksissa friendejä on tietty pakko käyttää.
Aihe on jo aika vanha, joten et voi enää vastata siihen.