Struktura interfejsu i implementacji?

Question

Jestem całkiem nowy w projektowaniu dużych programów w C++. Piszę serię operacji, z których każda ma własną klasę, która zostanie wywołana przez klasę ProcessMgr.

Używam ProcessMgr jako klasy interfejsu, z których każda operacja może być wywołany:

class ProcessMgr 
{ 
private: 
    class OperationOne; 
    class OperationTwo; 
    class OperationThree; 
} 

class ProcessMgr::OperationOne 
{ 
public: 
    ... 
}; 
class ProcessMgr::OperationTwo 
{ 
public: 
    ... 
}; 
class ProcessMgr::OperationThree 
{ 
public: 
    ... 
}; 

To pozwala mi kontrolować rodzaje dostępu do Operation klas, więc nie narażając dużo leżące u ich podstaw kod.

Ważne jest, aby użytkownik tego kodu mógł wchodzić w interakcje z klasami Operation w określony sposób i nie mieć pełnego dostępu do wszystkich treści klas Operations.

Moje pytania:

1) Czy jest to dobre podejście do projektowania dużych programów? Czy większość bibliotek, takich jak CURL, ma taką strukturę?

2) Czy istnieją lepsze/bardziej wydajne metody oddzielania interfejsu i implementacji?

Answer 1

Normalny interfejs w C++ (lub innych językach OOP) zapewnia definicje. "Klasy operacyjne" muszą pochodzić z interfejsu, aby oddzielić implementację od klienta. Zasada ta nazywa się Dependency inversion principle(DIP).

Częstym UML diagram z DIP wygląda następująco:

Ponieważ klient jest po prostu zapoznać się z interfejsem, można kontrolować dostęp do poszczególnych podklas. Implementacja może wyglądać następująco:

class ProcessMgr { 
    virtual void foo() = 0; 
    virutal void bar() = 0; 
} 

class Operation1 : public ProcessMgr { 
    virtual void foo() { ... } 
    virtual void bar() { ... } 
} 

class Operation2 : public ProcessMgr { 
    virtual void foo() { ... } 
    virtual void bar() { ... } 
} 

DIP jest zasada z serii bardzo dobrych zasad, zwany SOLID. Aby projektować duże projekty, jest wiele do zrobienia i uczenia się. Jednak zasady SOLID to dobry początek, aby zrozumieć, jak projektować aplikacje.