Udostępnij przez

Korzystanie z plików źródłowych MFC

Biblioteka klasy Microsoft Foundation (MFC) dostarcza pełny kod źródłowy. Pliki nagłówków (.h) znajdują się w katalogu \atlmfc\include . Pliki implementacji (.cpp) znajdują się w katalogu \atlmfc\src\mfc .

W tym artykule wyjaśniono konwencje używane przez MFC do komentowania różnych części każdej klasy, co oznaczają te komentarze i czego należy oczekiwać w każdej sekcji. Kreatory programu Visual Studio używają podobnych konwencji dla klas tworzonych dla Ciebie i prawdopodobnie znajdziesz te konwencje przydatne dla własnego kodu.

Być może znasz publicsłowa kluczowe , protectedi private C++. W plikach nagłówków MFC znajdziesz każdą klasę z kilkoma z nich. Na przykład publiczne zmienne składowe i funkcje mogą znajdować się w więcej niż jednym public słowie kluczowym. Jest to spowodowane tym, że MFC oddziela zmienne składowe i funkcje na podstawie ich użycia, a nie według typu dozwolonego dostępu. MFC używa private oszczędnie. Nawet elementy uważane za szczegóły implementacji są często protected, a wiele razy to public. Chociaż nie zaleca się dostępu do szczegółów implementacji, MFC pozostawia ci decyzję.

W plikach źródłowych MFC i plikach nagłówkowych tworzonych przez Kreatora aplikacji MFC znajdziesz komentarze podobne do tych w deklaracjach klas (zwykle w tej kolejności):

// Constructors

// Attributes

// Operations

// Overridables

// Implementation

Przykład komentarzy

Poniższa częściowa lista klasy CStdioFile używa większości standardowych komentarzy MFC do podziału elementów klasy według sposobu ich użycia:

/*============================================================================*/
// STDIO file implementation

class CStdioFile : public CFile
{
    DECLARE_DYNAMIC(CStdioFile)

public:
// Constructors
    CStdioFile();

    // . . .

// Attributes
    FILE* m_pStream;    // stdio FILE
                        // m_hFile from base class is _fileno(m_pStream)

// Operations
    // reading and writing strings
    virtual void WriteString(LPCTSTR lpsz);
    virtual LPTSTR ReadString(_Out_writes_z_(nMax) LPTSTR lpsz, _In_ UINT nMax);
    virtual BOOL ReadString(CString& rString);

// Implementation
public:
    virtual ~CStdioFile();
#ifdef _DEBUG
    void Dump(CDumpContext& dc) const;
#endif
    virtual ULONGLONG GetPosition() const;
    virtual ULONGLONG GetLength() const;
    virtual BOOL Open(LPCTSTR lpszFileName, UINT nOpenFlags, CFileException* pError = NULL);

    // . . .

protected:
    void CommonBaseInit(FILE* pOpenStream, CAtlTransactionManager* pTM);
    void CommonInit(LPCTSTR lpszFileName, UINT nOpenFlags, CAtlTransactionManager* pTM);
};

Te komentarze konsekwentnie oznaczają sekcje deklaracji klasy, które zawierają podobne rodzaje członków klasy. Należy pamiętać, że są to konwencje MFC, a nie ustawione reguły.

Komentarz konstruktorów

Sekcja // Constructors deklaracji klasy MFC deklaruje konstruktory (w sensie języka C++) i wszystkie funkcje inicjowania wymagane do rzeczywistego używania obiektu. Na przykład CWnd::Create znajduje się w sekcji konstruktorów, ponieważ przed użyciem obiektu CWnd musi być "w pełni skonstruowany", najpierw wywołując konstruktor języka C++, a następnie wywołując funkcję Create. Zazwyczaj ci członkowie są publiczni.

Na przykład klasa CStdioFile ma pięć konstruktorów, z których jedna jest wyświetlana na liście w obszarze Przykład komentarzy.

Komentarz atrybutów

Sekcja // Attributes deklaracji klasy MFC zawiera atrybuty publiczne (lub właściwości) obiektu. Zazwyczaj atrybuty są zmiennymi składowymi lub funkcjami Get/Set. Funkcje "Get" i "Set" mogą być wirtualne lub nie. Funkcje "Get" są często const, ponieważ w większości przypadków nie mają efektów ubocznych. Ci członkowie są zwykle publiczni. Chronione i prywatne atrybuty są zwykle znajdowane w sekcji implementacji.

Na przykładowej liście z klasy CStdioFilew obszarze Przykładowe komentarze lista zawiera jedną zmienną składową, m_pStream. Klasa CDC wymienia prawie 20 członków pod tym komentarzem.

Uwaga / Notatka

Duże klasy, takie jak CDC i CWnd, mogą mieć tak wiele elementów członkowskich, że samo wypisanie wszystkich atrybutów w jednej grupie nie wnosiłoby wiele do jasności. W takich przypadkach biblioteka klas używa innych komentarzy jako nagłówków, aby dalej wyróżniać członków. Na przykład CDC używa // Device-Context Functions, // Drawing Tool Functions, // Drawing Attribute Functions i innych. Grupy reprezentujące atrybuty będą zgodne ze zwykłą składnią opisaną powyżej. Wiele klas OLE ma sekcję implementacji o nazwie // Interface Maps.

Komentarz operacji

Sekcja // Operations deklaracji klasy MFC zawiera funkcje składowe, które można wywołać na obiekcie w celu wykonania czynności lub wykonania akcji (wykonywanie operacji). Funkcje te zwykle nie są const - ponieważ zazwyczaj mają skutki uboczne. Mogą być wirtualne lub niewirtualne w zależności od potrzeb klasy. Zazwyczaj ci członkowie są publiczni.

W przykładowej liście z klasy CStdioFile, w przykładzie komentarzy lista zawiera trzy funkcje składowe w tym komentarzu: WriteString i dwa przeciążenia ReadString.

Podobnie jak w przypadku atrybutów, operacje można dalej podzielić.

Komentarz dotyczący możliwych zastąpień

Sekcja // Overridables deklaracji klasy MFC zawiera funkcje wirtualne, które można zastąpić w klasie pochodnej, gdy trzeba zmodyfikować zachowanie klasy bazowej. Zazwyczaj nazywa się je zaczynając od "On", chociaż nie jest to ściśle konieczne. Funkcje są tutaj zaprojektowane tak, aby mogły być zastąpione i często implementują lub udostępniają pewnego rodzaju "wywołanie zwrotne" lub "hak". Zazwyczaj te składniki są chronione.

W samej usłudze MFC czyste funkcje wirtualne są zawsze umieszczane w tej sekcji. Czysta funkcja wirtualna w języku C++ przyjmuje postać:

virtual void OnDraw( ) = 0;

Na przykładowej liście z klasy CStdioFile, w przykładzie komentarzy, lista nie zawiera sekcji zastępowalności. Klasa CDocument, z drugiej strony zawiera listę około 10 zastępowalnych funkcji składowych.

W niektórych klasach może również zostać wyświetlony komentarz // Advanced Overridables. Te funkcje to te, które tylko zaawansowani programiści powinni próbować zastąpić. Prawdopodobnie nigdy nie trzeba ich zastąpić.

Uwaga / Notatka

Konwencje opisane w tym artykule również działają dobrze, ogólnie, dla metod i właściwości automatyzacji (dawniej znanej jako automatyzacja OLE). Metody automatyzacji są podobne do operacji MFC. Właściwości automatyzacji są podobne do atrybutów MFC. Zdarzenia automatyzacji (obsługiwane w kontrolkach ActiveX, wcześniej znane jako kontrolki OLE) są podobne do funkcji składowych MFC, które można przesłonić.

Komentarz implementacji

Sekcja // Implementation jest najważniejszą częścią każdej deklaracji klasy MFC.

Ta sekcja zawiera wszystkie szczegóły implementacji. W tej sekcji mogą pojawić się zarówno zmienne składowe, jak i funkcje składowe. Wszystko poniżej tego wiersza może ulec zmianie w przyszłej wersji MFC. Jeśli nie możesz tego uniknąć, nie należy polegać na szczegółach poniżej // Implementation wiersza. Ponadto członkowie zadeklarowani poniżej wiersza implementacji są nieudokumentowani, chociaż niektóre implementacje zostały omówione w uwagach technicznych. Przesłonięcia funkcji wirtualnych w klasie bazowej znajdują się w tej sekcji, niezależnie od tego, w której sekcji zdefiniowano funkcję klasy bazowej. Gdy funkcja zastępuje implementację klasy bazowej, jest to traktowane jako szczegół implementacji. Zazwyczaj ci członkowie są chronieni, ale nie zawsze.

Na liście pod CStdioFile w obszarze Przykład komentarzy, członkowie zadeklarowani pod komentarzem // Implementation mogą być zadeklarowani jako public, protected, lub private. Należy z ostrożnością używać tych elementów, ponieważ w przyszłości mogą ulec zmianie. Deklarowanie grupy elementów członkowskich jako public może być niezbędne do poprawnej implementacji biblioteki klas. Nie oznacza to jednak, że można bezpiecznie korzystać z członków zadeklarowanych w ten sposób.

Uwaga / Notatka

Komentarze pozostałych typów można znaleźć powyżej lub poniżej komentarza // Implementation . W obu przypadkach opisują rodzaje zadeklarowanych poniżej członków. Jeśli wystąpią one poniżej komentarza // Implementation, należy założyć, że członkowie mogą ulec zmianom w przyszłych wersjach MFC.

Zobacz także

Ogólne tematy MFC

  • Last updated on