Может ли дизайн шаблонов разрушать абстракцию?

Question

Это вопрос теории не практический.

Я пытаюсь разработать программу, которая следует за лучшими практиками программного обеспечения. Но у меня возникли проблемы с поиском наилучшего способа сделать определенные вещи, которые позволяют разработать Test Driven Development и хорошую инкапсуляцию и абстракцию, а также минимизировать сцепление.

Я планировал иметь два уровня абстракции, уровень управления базой данных и уровень управления таблицей.

class TableManager() 
{ 
    init() { 
    manager = DatabaseManger() 
    } 

    do_operation(String operation) { 
     connection = manager.get_db_connection() 
     connection.execute(operation) 
    } 
} 

Это казалось хорошей идеей, потому что фактические данные соединения скрыты от менеджера таблиц. Но это также кажется плохим, потому что TableManager тесно связан с DatabaseManager и для тестирования, мне нужно будет иметь отдельное соединение с базой данных для настройки состояния базы данных, например, для удаления базы данных и таблицы, чтобы мы тестировали операции, когда база данных не существуют и тому подобное

Может кто-то весить здесь и оспаривать мои предположения? Я мог бы переоценить важность некоторых факторов или недооценивать другие. Это обычная проблема с дизайном?

Answer 1

Рассмотрим прохождение manager в TableManager в качестве параметра конструктора, так что вы можете иметь две различные реализации менеджера в базы данных: бетонную один и макетом один.

// These two classes have the same interface. 
class ConcreteDBManager 
{ 
    auto numberOfTables() 
    { 
     auto connection = connectToRealDB(); 
     return connection.queryAs<int>("COUNT TABLES"); 
    } 
}; 

class MockDBManager 
{ 
    auto numberOfTables() 
    { 
     return 5; 
    } 
}; 

template <typename TDatabaseManager> 
class TableManager 
{ 
    TDatabaseManager _manager; 
    TableManager(const TDatabaseManager& manager) 
     : _manager{manager} 
    { 
    } 

    auto numberOfTables() 
    { 
     return _manager.numberOfTables(); 
    } 
}; 

При таком подходе, вы можете протестировать функциональность TableManager, предоставляя MockDBManager экземпляр, так что вы не должны подключаться к фактическому БД в модульных тестов ...

TEST(TableManager, RetrieveNumberOfTables) 
{ 
    MockDBManager mockDBManager; 
    TableManager<MockDBManager> tableManager(mockDBManager); 
    EXPECT_EQ(5, tableManager.numberOfTables()); 
} 

... но вы можете подключиться к реальной БД в рабочем коде с тем же TableManager интерфейсом:

void realProductionCode() 
{ 
    ConcreteDBManager concreteDBManager; 
    TableManager<ConcreteDBManager> tableManager(concreteDBManager); 
    std::cout << tableManager.numberOfTables(); 
}