Pro e contro di un'interfaccia "Connection" e criticità implementative

[mazzal1]

È di tendenza il dibattito sull'utilità o meno di rappresentare la connessione logica con un macchinario industriale con un'apposita interfaccia "Connection", la quale sarebbe agnostica rispetto all'entità a al protocollo di comunicazione. In tali condizioni, la Connection dichiarerebbe solo metodi pubblici non riguardanti la comunicazione ma riguardanti invece lo stato della connessione, ad esempio "getStateConnection".
Una tale interfaccia risulterebbe quindi inutilizzabile in sé e per sé per comunicare con la macchina. Richiederebbe infatti di essere declinata in interfacce più specifiche, a seconda del protocollo di comunicazione sottostante, come ad esempio "SqlConnection" o "OpcUaConnection". Queste interfacce avrebbero quindi l'onere di dichiarare e "wrappare" i metodi di comunicazione definiti da standard terzi. Le implementazioni di tali interfacce risulterebbero quindi degli "Adapter", secondo la nomenclatura dei design pattern.
Dividendo concettualmente il concetto di connessione e il concetto di adapter, si arriverebbe ad avere una struttura di classi ed interfacce simile a quella dell'esempio che segue:
```
interface OpcUaConnection extends Connection, OpcUaAdapter

class MiloOpcUaConnection implements OpcUaConnection
```

È certamente buona pratica l'uso degli Adapter per evitare grossi refactor nel caso in cui si dovesse cambiare una libreria che implementa un client di comunicazione. È tuttavia così utile "nascondere" l'implementazione del paradigma "Adapter" all'interno di una declinazione dell'interfaccia Connection? Non è l'interfaccia Connection, nella sua forma base, troppo generica per essere utile?

[iotinga]

Ciao Luca,
grazie per il tuo contributo.
Il markdown non e' supportato e non puó essere supportato.
Puoi usare il bbcode il tag [ code ] codice [ /code ] (senza spazi tra le quadre)

Codice: Seleziona tutto

int main()
{
  char a = 'a';
  return 1;
}