Hai davvero due domande molto diverse qui, sebbene siano correlate.
La domanda più generale è quella nel titolo, perché dovresti separare l'interfaccia dall'implementazione in generale. La seconda domanda è perché il modello a ponte è utile. Sono correlati perché il modello bridge è un modo specifico di separare l'interfaccia dall'implementazione, che ha anche alcune altre conseguenze specifiche.
La domanda generale è qualcosa di vitale da comprendere per ogni programmatore. È ciò che impedisce ai cambiamenti di un programma di propagarsi ovunque. Non riesco a immaginare che gli umani possano programmare senza usare questo.
Quando scrivi una semplice dichiarazione di addizione in un linguaggio di programmazione, questa è già un'astrazione (anche se non utilizza il sovraccarico dell'operatore per aggiungere matrici o qualcosa del genere) che passa attraverso un sacco di altro codice prima che venga finalmente eseguito su un circuito nel tuo computer. Se non vi fosse alcuna separazione dell'interfaccia (diciamo "3 + 5"), dall'implementazione (un gruppo di codice macchina), allora dovresti cambiare il tuo codice ogni volta che l'implementazione è cambiata (come se volessi eseguire su un nuovo processore).
Anche all'interno di una semplice applicazione CRUD, ogni firma del metodo è, in senso lato, l'interfaccia della sua implementazione.
Tutti questi tipi di astrazione hanno lo stesso obiettivo di base: far sì che il codice chiamante esprima le sue intenzioni nel modo più astratto possibile che fornisca all'implementatore tutte le informazioni necessarie. Ciò fornisce il minimo accoppiamento possibile tra loro e limita l'effetto di ondulazione quando il codice deve essere modificato il più possibile.
Sembra semplice, ma in pratica diventa complicato.
Il modello a ponte è un modo specifico di separare alcuni bit di implementazione in interfacce. Il diagramma di classe del modello è più informativo della descrizione. È più un modo per avere moduli collegabili che un bridge, ma lo hanno chiamato bridge perché è spesso usato dove i moduli sono stati creati prima dell'interfaccia. Quindi la creazione di un'interfaccia comune per implementazioni simili simili in qualche modo "colma" la differenza e consente al codice di lavorare con una qualsiasi delle implementazioni.
Quindi, supponiamo che tu voglia scrivere un componente aggiuntivo su un elaboratore di testi, ma vuoi che funzioni su più elaboratori di testi. È possibile creare un'interfaccia in grado di estrarre le funzionalità basate sull'elaboratore di testi necessarie (e che devono essere implementabili da ciascun elaboratore di testi poiché non è possibile modificarle) e un implementatore di tale interfaccia per ciascun elaboratore di testi che si desidera supportare. Quindi l'applicazione può chiamare quell'interfaccia e non preoccuparsi dei dettagli di ciascun word processor.
In realtà è leggermente più dettagliato di quello, perché ogni classe potrebbe davvero essere una gerarchia di classi (quindi, potrebbe non esserci solo un elaboratore di testi astratto, ma un Documento astratto, una TextSelection astratta, ecc., Con implementazioni concrete per ciascuno), ma è la stessa idea.
È un po 'come una facciata, tranne in questo caso lo strato di astrazione è focalizzato sulla fornitura della stessa interfaccia a più sistemi sottostanti.
È correlato a Inversion Of Control, poiché l'implementatore concreto verrà passato a metodi o costruttori e determinerà l'implementazione effettiva chiamata.