Bolączki C++ #1 – Pimp(l) my code
2007-08-25 12:13Kiedy programuje się w języku, który jest – jak to ładnie mówią Amerykanie – ‘standardem przemysłowym’ w danej dziedzinie, chcąc nie chcąc trzeba się do niego przyzwyczaić. A to oznacza, że musimy nauczyć się żyć z jego wadami, które niekiedy mogą być tylko irytujące, a niekiedy bardzo nieprzyjemne. Ważne, by mieć świadomość ich istnienia i w miarę możliwości sobie z nimi radzić.
C++ jako ustandaryzowany język ma już prawie dziesięć lat, więc lista jego niedoskonałości w porównaniu z nowszymi językami siłą rzeczy staje się coraz dłuższa. Takie listy są jednak w dużym stopniu subiektywne, zatem i ten, który rozpoczynam poniżej, absolutnie nie pretenduje do miana ostatecznej wyroczni :) Na pewno inni usunęliby z niego część pozycji, niektóre uznali za mniej lub bardziej dotkliwe, a także dodali własne propozycje.
Dla mnie sprawą, która w C++ jest powodem największego bólu zębów, jest sposób organizacji kodu zaproponowany w tym języku. Jest on bodaj jedynym mi znanym (poza swoim poprzednikiem C), w którym występuje podział plików z kodem na dwa rodzaje: pliki nagłówkowe (*.h, *.hpp) i moduły kodu (*.cpp). W tych pierwszych teoretycznie umieszczany jest interfejs klas i funkcji, czyli informacje potrzebne do ich użycia w innym miejscu programu. W tych drugich jest zaś zawarta implementacja rzeczonych klas oraz funkcji.
Tyle teorii. W praktyce osiągnięcie idealnej separacji obu tych elementów wymaga sztuczki nazywanej szumnie wzorcem projektowym, o nazwie Pimpl (skrót od private implementation). Wygląda on na przykład następująco:
- // -- foo.hpp --
- class CFoo_Impl; // deklaracja zapowiadająca
- // właściwa klasa
- class CFoo
- {
- private:
- CFoo_Impl* m_pImpl;
- public:
- CFoo();
- ~CFoo();
- void SomeOperation1();
- };
- // -- foo.cpp --
- #include "foo.hpp"
- class CFoo_Impl
- {
- // implementacja
- };
- CFoo::CFoo() : m_pImpl(new CFoo_Impl) { /* ... */}
- CFoo::~CFoo() { delete m_pImpl; }
- void CFoo::SomeOperation1() { m_pImpl->SomeOperation1(); }
- // itd.
Wtedy faktycznie nie widać, co siedzi w środku naszej klasy, ale cena takiej hermetyzacji to konieczność stworzenia dodatkowej klasy i przekierowania do niej metod. Może nie jest to dwa razy więcej roboty, ale przynajmniej 10-20%.
Z drugiej strony większość języków nowszych niż C++, jak Java, C# czy Python, w ogóle zna takich pojęć jak ‘prototyp funkcji’ czy ‘deklaracja zapowiadająca’. Tam kod piszemy od początku do końca: funkcję zawsze z jej treścią, a klasę zawsze w całości łącznie ze wszystkimi polami i kodem wszystkich metod. Nie ma podziału na pliki z ‘interfejsem’ i z implementacją.
A w C++ ten podział istnieje i tak naprawdę służy on tylko i wyłącznie… wygodzie kompilatora. Dzięki temu, że treść plików nagłówkowych jest taka, a nie inna (i np. zawierają one deklaracje prywatnych pól klas, które są przecież częścią implementacji), mogą być one zwyczajnie dołączane do modułów przy pomocy arcyprymitywnej dyrektywy #include. Dla kompilatora jest to najprostsze rozwiązanie, bo może on pracować nad każdym modułem osobno i nie musi się martwić żadnymi niejawnymi zależnościami między plikami. A dla programisty oznacza to wybór między wygodą kodowania, a jakością i “odpornością” stworzonego kodu.
C++ stoi więc w pewnym sensie pośrodku i wcale nie jest to złoty środek. Z jednej strony mógłby pójść w kierunku wyznaczonym przez wspomniane nowsze języki, czyli wprowadzenia jednego typu plików źródłowych, zawierających kod bez podziału na deklaracje i implementacje. To by było jednak mało oryginalne :) Bardziej interesujące byłoby, jak sądzę, polepszenie istniejącego rozwiązania w odwrotnym kierunku; być może automatyczne stosowanie wzorca Pimpl dla każdej klasy jest jednym ze sposobów.
Niestety, patrząc na obecny roboczy szkic standardu C++0x, w którym nic na ten temat nie znajdziemy, nie możemy raczej oczekiwać, że coś tu się zmieni w przewidywalnej przyszłości.
-
spaxio:
August 25th, 2007 o 16:27http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf – dalekiej przyszlosci ;]
-
Reg:
August 26th, 2007 o 10:15Nie trzeba duplikować wszystkich metod klasy w jej PIMPL. Ja traktuję PIMPL jako strukturę i trzymam tam tylko pola oraz te metody, które byłyby w klasie prywatne. Pozostałe są zaimplementowane bezpośrednio w klasie głównej i używają pimpl->Pole.
Tym nie mniej eleganckiego rozwiązania nie ma. C++ sux :P
-
siso:
September 29th, 2009 o 2:30PIMPL może znaleźć jeszcze jedno ciekawe zastosowanie. Otóż, możemy je sobie w locie podmieniać na inne.
Dodatkowo, w opublikowanym API, przeznaczonym bezpośrednio klientom naszego kodu, nie podaje się szczegółów PIMPL. Nie jest im to zupełnie potrzebne, a ponadto w znaczący sposób utrudnia im to (jeśli nie uniemożliwia zupełnie) używanie klasy w sposób niezgodny z jej założeniami projektowymi.
Recent posts
