Kell használni a beágyazott osztályok ebben az esetben?

szavazat
42

Dolgozom egy gyűjtemény osztályok használható video lejátszás és felvétel. Van egy fő osztály, amely úgy működik, mint a nyilvános interfész, a módszerek, mint play(), stop(), pause(), record()stb ... Aztán van igásló osztályok, amelyek nem a videó dekódolás és video kódolás.

Most tanultam a létezéséről beágyazott osztályok C ++, és kíváncsi vagyok, hogy mit gondol a programozók használja őket. Én egy kicsit óvatos, és nem igazán tudja, mi az előnyök / hátrányok, de úgy tűnik, (a könyv szerint Olvasom) kell használni azokban az esetekben, mint az enyém.

A könyv azt sugallja, hogy a forgatókönyv, mint az enyém, egy jó megoldás az lenne, hogy fészket igásló osztályok belsejében interfész osztály, így nincsenek külön fájlokat osztályok az ügyfél nem azt jelentette, hogy használja, és hogy elkerüljék az esetleges elnevezési konfliktusokat? Nem tudom, hogy ezekről a bizonyítékokat. Beágyazott osztály egy új fogalom számomra. Csak azt, hogy mit gondol a programozók a problémát.

A kérdést 02/08/2008 03:51
a forrás felhasználó
Más nyelveken...                            


10 válasz

szavazat
25

Azt lenne egy kicsit vonakodik használni beágyazott osztályok itt. Mi van, ha létrehozott egy absztrakt osztályok számára egy „multimédiás driver” kezelni a back-end cucc (igásló), és egy külön osztályt a front-end munkát? A front-end az osztály egy pointert / hivatkozás egy megvalósított illesztőprogram osztály (a megfelelő média típusa és helyzete), és végezze el az absztrakt műveleteket az igásló szerkezetét.

Az én filozófiám az lenne, hogy megy előre, és két struktúra elérhetővé teszi az ügyfelek egy polírozott módon, csak azzal a feltételezéssel lennének használhatók tandem.

Azt hivatkozás olyasmi, mint egy QTextDocument Qt. Azt, hogy közvetlen interfész a csupasz fém adatkezelés, de át a hatóság mentén egy objektum, mint egy QTextEdit tenni a manipuláció.

Válaszolt 02/08/2008 04:00
a forrás felhasználó

szavazat
5

Az egyik módja annak eldöntése, hogy ne használja a beágyazott osztályok gondolni-e vagy sem ez az osztály játszik támogató szerepet, vagy hogy a saját részét.

Ha csak és kizárólag abból a célból, hogy segítse egy másik osztály, akkor én általában, hogy ez egy beágyazott osztály. Van egy rakás kikötéseket e, amelyek közül néhány ellentmondásosnak tűnik, de minden jön le, hogy a tapasztalatok és a bél-érzés.

Válaszolt 05/08/2008 09:29
a forrás felhasználó

szavazat
4

úgy hangzik, mint egy eset, amikor jól jönne a stratégia minta

Válaszolt 05/08/2008 09:37
a forrás felhasználó

szavazat
4

Néha szükséges, hogy elrejtse a megvalósítási osztályokat a felhasználó - ezekben az esetekben, hogy jobb őket egy foo_internal.h mint belül a nyilvánosság osztály definíciója. Így, az olvasók a foo.h nem fogja látni, amit inkább ők nem zavarta az, de akkor is levelet tesztek egymás ellen a beton implementáció a felületet.

Válaszolt 16/09/2008 10:31
a forrás felhasználó

szavazat
9

Akkor használja a beágyazott osztály létrehozásához (kis) helper osztály, ami szükséges, hogy hajtsák végre a fő osztály. Vagy például, hogy meghatározza egy interfész (egy osztály absztrakt módszerekkel).

Ebben az esetben a fő hátránya beágyazott osztályok, hogy ez megnehezíti, hogy újra használni őket. Talán szeretné használni a VideoDecoder osztály egy másik projektben. Ha teszi a beágyazott osztály VideoPlayer, akkor ezt nem elegáns módon.

Ehelyett tegye más osztályok külön .h / cpp fájl, amit lehet majd használni a VideoPlayer osztályban. Az ügyfél a VideoPlayer már csak tartalmaznia kell a fájlt, hogy kijelenti VideoPlayer, és még mindig nem tudni kell, hogyan valósították.

Válaszolt 17/09/2008 12:50
a forrás felhasználó

szavazat
2

Akkor érdemes használni egy belső osztály csak akkor, ha nem tudja végrehajtani, mint egy külön osztályt a leendő külső osztály nyilvános felületen. Belső osztályok méretének növelése, a bonyolultság és a felelősség egy osztály, így takarékosan kell használni.

A kódoló / dekódoló osztály hangzik jobban illeszkedik a stratégia Pattern

Válaszolt 18/09/2008 16:19
a forrás felhasználó

szavazat
1

Ennek egyik oka, hogy elkerüljék a beágyazott osztályok, ha valaha is szándékában, hogy lezárja a kódot korty ( http://www.swig.org ) használható más nyelven. Korty jelenleg problémák beágyazott osztályok, így kapcsolódást könyvtárak, hogy ki minden beágyazott osztályok válik igazi fájdalom.

Válaszolt 20/09/2008 08:37
a forrás felhasználó

szavazat
4

Elérünk egy probléma félig régi Sun C ++ fordító és láthatóságának beágyazott osztályok viselkedése megváltozott a szabvány. Ez nem ok arra, hogy nem a beágyazott osztály, persze, csak valami legyen tudatában, ha terv összeállítása a szoftvert sok platformon, beleértve a régi fordító.

Válaszolt 21/09/2008 01:39
a forrás felhasználó

szavazat
1

A másik dolog, hogy tartsa szem előtt, hogy valaha is képzelni különböző implementációja a munka funkciók (például dekódolás és kódolás). Ebben az esetben, akkor biztosan szeretne egy absztrakt alap osztály különféle konkrét osztályok, amelyek megvalósítják a függvényeket. Ez nem lenne igazán megfelelő fészek külön alosztály minden fajta megvalósítás.

Válaszolt 23/09/2008 20:07
a forrás felhasználó

szavazat
4

Nos, ha használja mutatókat az igásló osztályok az interfész osztály és ne tegye ki őket paraméterek vagy vissza típusok a felület módszereket, akkor nem kell, hogy tartalmazza a definíciókat azoknak munka lovak a header fájlban (csak előre kijelentem nekik helyette). Így a felhasználók a felület nem kell tudni az osztályok a háttérben.

Te biztosan nem kell fészket osztályok erre. Tény, hogy külön osztályt fájlok valójában a kódot sokkal olvashatóbb és könnyebben kezelhetővé, mint a projekt növekszik. ez is segít a későbbiekben, ha szüksége alosztályba (mondjuk a különböző tartalmak / codec típus).

Itt további információt a PIMPL minta (3.1.1).

Válaszolt 26/09/2008 00:34
a forrás felhasználó

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more