2014-05-02 25 views
5

RAII (Inicjalizacja akwizycji to inicjalizacja) jest jednym z sugerowanych sposobów konstruowania obiektów. W jaki sposób odnosi się do zasad testowania jednostek, które mówią: bez skomplikowanej pracy wykonanej w konstruktorze? A szczególnie brak wyraźnego tworzenia obiektów przez "nowego" operatora? Jednak tworzenie niektórych obiektów wymaga czasami bardziej skomplikowanych kroków, a przekazanie fabryki do konstruktora powoduje, że interfejs API jest "brudny" w znaczeniu zmniejszenia czytelności. Jakie są ogólne sposoby na spełnienie obu zasad w tym samym czasie?Zasady testowania RAII i testów jednostkowych

Znalazłem inny temat na SO: Stack allocated RAII objects vs DI principle, jednak wygląda na bardziej ogólny problem i nie jest dobrze wyjaśniony.

+0

@MartinJames dlaczego? To brzmi jak uzasadnione pytanie projektowe do mnie. Co więcej, nie mogę wymyślić żadnej klasy, która zadawałaby to jako zadanie domowe. –

+0

Jeśli to jest pytanie o przydział, to chcę się tam uczyć! Jednak jest to problem, który spotykam w codziennej pracy. Chciałbym poznać opinie i sposoby postępowania z nimi przez innych programistów. – thatsme

Odpowiedz

3

Tak, tworzenie konkretnej klasy w konstruktorze komplikuje klasę, która to robi, dodaje zależność do klasy i utrudnia testowanie.

Ale RAII nie jest sposobem na konstruowanie obiektów, ale na uwalnianie zasobów. Klasa, której destruktor zwalnia zasób, nie musi tworzyć obiektu, chociaż zwykle robi to: zobacz What is meant by Resource Acquisition is Initialization (RAII)?.

Stwórz więc zasób poza klasą, która go używa, jeśli chcesz, użyj do tego fabryki, jeśli chcesz itp., Ale pozwól klasie, która używa tego zasobu, wyczyścić ją za pomocą RAII.

+0

Właściwie w pewnym momencie żałowałem, że zadałem to pytanie, ponieważ doskonałym przykładem takiego zachowania jest shared_ptr. – thatsme

Powiązane problemy