Ponowne użycie obiektów

Ważnym celem każdego modelu obiektów jest umożliwienie autorom obiektów ponownego używania i rozszerzania obiektów udostępnianych przez inne osoby jako elementów własnych implementacji. Jednym ze sposobów wykonania tej czynności w programie Microsoft Visual C++ i innych językach jest użycie dziedziczenia implementacji , dzięki czemu obiekt może dziedziczyć niektóre funkcje ("podklasy") z innego obiektu podczas zastępowania innych funkcji.

Problem z interakcją z obiektem w całym systemie przy użyciu tradycyjnego dziedziczenia implementacji jest to, że kontrakt (interfejs) między obiektami w hierarchii implementacji nie jest jasno zdefiniowany. W rzeczywistości jest niejawny i niejednoznaczny. Gdy obiekt nadrzędny lub podrzędny zmieni swoją implementację, zachowanie powiązanych składników może stać się niezdefiniowane lub niestabilne. W każdej pojedynczej aplikacji, w której implementacja może być zarządzana przez jeden zespół inżynieryjny, który aktualizuje wszystkie składniki w tym samym czasie, nie zawsze jest to głównym problemem. W środowisku, w którym składniki jednego zespołu są tworzone za pomocą czarnego pudełka ponownego użycia innych składników utworzonych przez inne zespoły, ten typ niestabilności zagraża ponownemu użyciu. Ponadto dziedziczenie implementacji zwykle działa tylko w granicach procesów. Dzięki temu tradycyjne dziedziczenie implementacji jest niepraktyczne dla dużych, zmieniających się systemów składających się z składników oprogramowania utworzonych przez wiele zespołów inżynieryjnych.

Kluczem do kompilowania składników wielokrotnego użytku jest możliwość traktowania obiektu jako nieprzezroczystego pola. Oznacza to, że fragment kodu próbujący ponownie użyć innego obiektu nic nie wie i nie musi nic wiedzieć o wewnętrznej strukturze lub implementacji używanego składnika. Innymi słowy, kod próbujący ponownie użyć składnika zależy od zachowania obiektu, a nie jego dokładnej implementacji.

Aby osiągnąć możliwość ponownego użycia czarnej skrzynki, COM przyjmuje inne ustanowione mechanizmy ponownego użycia, takie jak zawieranie/delegowanie i agregacji.

Notatka

Dla wygody obiekt używany ponownie jest nazywany obiektem wewnętrznym , a obiekt korzystający z tego obiektu wewnętrznego jest obiektem zewnętrznym .

 

Należy pamiętać w przypadku obu tych mechanizmów, jak obiekt zewnętrzny prezentuje się klientom. Z punktu widzenia klientów, oba obiekty implementują jakiekolwiek interfejsy, do których klient może uzyskać wskaźnik. Klient traktuje obiekt zewnętrzny jako nieprzezroczyste pole i dlatego nie dba, ani nie musi dbać o wewnętrzną strukturę obiektu zewnętrznegoâ € "klient dba tylko o zachowanie.

Aby uzyskać więcej informacji, zobacz następujące tematy:

• ograniczanie/delegowanie
• Agregacja