"Interface Component" di Leo Brodie

3

A pagina 85 del libro di Leo Brodie, Pensare in avanti, descrive un componente che chiama "Componente di interfaccia". Descrive le sue differenze e vantaggi su un'interfaccia standard come segue:

When it comes to data interfaces between modules, traditional wisdom says only that “interfaces should be carefully designed, with a minimum of complexity.” The reason for the care, of course, is that each module must implement its own end of the interface (Figure 3.8).

This means the presence of redundant code. As we’ve seen, redundant code brings at least two problems: bulky code and poor maintainability. A change to the interface of one module will affect the interface of the opposite module.

Prosegueconl'introduzionedelconcettodicomponentedell'interfaccia:

There’smoretogoodinterfacedesignthanthat.AllowmetointroduceadesignelementwhichIcallthe“interfacecomponent.”Thepurposeaninterfacecomponentistoimplement,andhideinformationabout,thedatainterfacebetweentwoormoreothercomponents(Figure3.9).

Questo modello è applicabile quando si programma in Java? Le interfacce in Java sono simili a quelle illustrate nella Figura 3.8 sopra. Se fosse necessario introdurre un oggetto componente dell'interfaccia, non sarebbe questo, insieme agli altri due oggetti, che tutti devono rispettare l'interfaccia definita? Non vedo quali vantaggi possa fornire il componente dell'interfaccia.

Qualche idea?

    
posta dmux 04.08.2016 - 17:06
fonte

1 risposta

4

Regola n. 1 durante la lettura di qualsiasi testo di programmazione o di informatica: "interfaccia" non fa mai riferimento al costrutto Java interface . (Regola n. 1b: tranne quando il testo è specificamente sul linguaggio Java e anche in questo caso non è garantito.)

In questo caso particolare, sembra che "l'interfaccia" sia usata nel senso generico di occultamento dell'informazione, astrazione dei dati e modularità, ovvero la distinzione tra dettagli di implementazione interna privata nascosta e un modo pubblico di usare il modulo, noto anche come la sua interfaccia.

Ciò che sta dicendo il testo è che anche se hai due moduli completamente incapsulati, il modo in cui quei due moduli accettano di interagire tra loro (cioè l'interfaccia che si presentano l'un l'altro), li accoppia ancora, e persino peggio, cambiando il modo in cui interagiscono tra loro richiede modifiche a entrambi i moduli. IOW, la conoscenza di come interagire tra loro è distribuita tra i due moduli.

Il modo per contrastare questo è estrarre un terzo modulo che gestisce l'interazione tra i due moduli.

Gli "elementi di design" di cui parla Brodie, verrebbero probabilmente chiamati Design Patterns in un linguaggio più moderno / mainstream, e ci sono in effetti due design pattern nel libro GoF che incontrano grosso modo la descrizione di Brodie:

  • Il Modello di ponte : disaccoppia un'astrazione dalla sua implementazione, se hai dimestichezza con C ++, questa è una generalizzazione dell'idioma PIMPL.
  • Il Modello di mediatore : incapsula il modo in cui un insieme di oggetti interagisce in un oggetto separato , puoi chiamarlo "ri-ificazione dell'interazione", se vuoi.
risposta data 04.08.2016 - 20:12
fonte

Leggi altre domande sui tag