Naprawdę masz tutaj dwa bardzo różne pytania, choć są one powiązane.
Bardziej ogólne pytanie brzmi: w tytule, dlaczego ogólnie oddzielasz interfejs od implementacji. Drugie pytanie dotyczy tego, dlaczego wzór mostu jest użyteczny. Są ze sobą powiązane, ponieważ wzorzec mostka jest specyficznym sposobem oddzielenia interfejsu od implementacji, co ma również pewne inne konsekwencje.
Ogólne pytanie jest czymś niezbędnym do zrozumienia przez każdego programistę. To właśnie zapobiega rozprzestrzenianiu się zmian w programie wszędzie. Nie wyobrażam sobie ludzi, którzy mogliby programować bez tego.
Kiedy piszesz prostą instrukcję dodawania w języku programowania, która jest już abstrakcją (nawet jeśli nie używa przeciążania operatora do dodawania macierzy lub czegoś podobnego), która przechodzi całkiem sporo innego kodu, zanim w końcu zostanie wykonany w obwodzie w komputerze. Jeśli nie było oddzielenia interfejsu (powiedzmy „3 + 5”) od implementacji (wiązka kodu maszynowego), musiałbyś zmieniać kod za każdym razem, gdy implementacja się zmieniała (tak jakbyś chciał uruchomić na nowy procesor).
Nawet w prostej aplikacji CRUD każda sygnatura metody jest, w szerokim znaczeniu, interfejsem do jej implementacji.
Wszystkie te rodzaje abstrakcji mają ten sam podstawowy cel - niech kod wywołujący wyraża swoją intencję w możliwie najbardziej abstrakcyjny sposób, który zapewnia implementatorowi tyle informacji, ile potrzeba. Zapewnia to minimalne możliwe sprzężenie między nimi i ogranicza efekt tętnienia, gdy kod musi zostać zmieniony w jak największym stopniu.
Brzmi prosto, ale w praktyce komplikuje się.
Wzorzec mostu jest szczególnym sposobem rozdzielenia niektórych bitów implementacji na interfejsy. Schemat klasowy wzorca jest bardziej pouczający niż opis. To raczej sposób na posiadanie modułów wtykowych niż mostek, ale nazwali go mostem, ponieważ jest często używany tam, gdzie moduły zostały utworzone przed interfejsem. Tak więc utworzenie wspólnego interfejsu dla podobnych istniejących implementacji stanowi „pomost” różnicy i umożliwia kodowanie pracy z dowolnymi implementacjami.
Powiedzmy, że chcesz napisać dodatek do edytora tekstu, ale chcesz, aby działał na wielu edytorach tekstu. Możesz utworzyć interfejs, który wyodrębnia funkcje oparte na edytorze tekstów, których potrzebujesz (i które muszą być możliwe do wdrożenia przez każdy edytor tekstu, ponieważ nie możesz ich zmienić) oraz jeden implementator tego interfejsu dla każdego edytora tekstu, który chcesz obsługiwać. Następnie aplikacja może wywołać ten interfejs i nie martwić się o szczegóły każdego edytora tekstu.
W rzeczywistości jest nieco bardziej szczegółowy, ponieważ każda klasa może naprawdę być hierarchią klas (więc może istnieć nie tylko abstrakcyjny edytor tekstu, ale abstrakcyjny dokument, abstrakcyjny wybór tekstu itp., Z konkretnymi implementacjami dla każdej), ale jest ten sam pomysł.
To trochę jak fasada, z tym wyjątkiem, że w tym przypadku warstwa abstrakcji koncentruje się na zapewnieniu tego samego interfejsu wielu bazowym systemom.
Jest to związane z Inversion Of Control, ponieważ konkretny implementator zostanie przekazany do metod lub konstruktorów i określi rzeczywistą wywoływaną implementację.