Separazione delle preoccupazioni quando si aggiungono nuovi tipi

7

Ho un sistema su cui ho lavorato questa settimana in cui ho difficoltà a bilanciare la separazione delle preoccupazioni con una facile estensibilità. Sto aggiungendo nuovi tipi al sistema, e sembra un intervento chirurgico con fucile a pompa.

L'idea di base è che i dati vengano raccolti (interrogati) da un sistema remoto e resi disponibili a diversi tipi di client. Per supportare il loro tipo di interfaccia (protocollo), sto facendo molta traduzione.

Cercherò di semplificare questo in modo da poterlo inserire in una casella di domanda.

Esiste un FruitService nel mondo con un'interfaccia SNMP. Il lavoro del mio editore è raccogliere quei dati e quindi pubblicarli.

  1. Quindi per ogni tipo di nuovo frutto decidiamo di pubblicare, creo una classe che sappia come estrarre gli attributi per quel frutto tramite SNMP.
  2. Internamente Fruit viene tradotto in DTO (gli stessi oggetti usati per parlare con il client # 1 (RMI)).
  3. Una cache viene aggiornata e controllata per le modifiche che attivano le notifiche asincrone.
  4. Una classe per tradurre la frutta nello schema xml utilizzato da un altro client (# 2).
  5. Una classe per tradurre il frutto in coppie di attributi / valori semplici utilizzati da un altro client (# 3).

Alla fine creo 5 classi e ne modifico altre 8 per inserire un nuovo tipo. Non è molto lavoro; un paio d'ore per scrivere codice, test e check-in per un tipo semplice. Nota che non c'è molta comunanza nei tipi di frutta (ad esempio pera e cocco), quindi la maggior parte delle astrazioni comuni si basa sul processo di aggiornamento dei dati e non sui dati stessi.

I miei dubbi sul design sono:

  1. L'interfaccia SNMP cambia 2-3 volte l'anno
  2. Lo schema xml (client 2) cambia 10 volte l'anno.
  3. L'aggiunta di nuovi tipi avviene meno frequentemente, in genere quando qualcuno ci arriva. Ma forse se fosse più facile ...

Quindi l'obiettivo nozionale con il design era di gestire facilmente quelle modifiche esterne. Ciò ha portato a tutta la separazione nei livelli di traduzione. Ma aggiungere i tipi sembra più difficile di quanto mi piacerebbe.

Esiste una tecnica o un esempio che potrei esaminare? Un'idea che mi manca? Sto applicando l'SRP sbagliato e ci dovrebbe essere un tipo Apple che parla SNNP, schema xml, DTO, ecc?

EDIT:

Il client # 1, il client RMI, è personalizzato quando viene aggiunto un nuovo frutto, per sfruttare tutte le funzionalità del frutto. Quindi, se decidiamo di estrarre le informazioni sulla banana da FruitService, scriveremo anche un client che ti permette di sbucciare la banana, ricevere una notifica quando è matura e dirti a quale mazzo appartiene - insieme agli attributi di base della frutta come la dimensione, peso, colore, tempo fino al marcio, ecc.

    
posta Steve Jackson 09.09.2010 - 15:40
fonte

1 risposta

1

La mia prima impressione è che il tuo design ha bisogno di un refactoring per essere più orientato agli oggetti. Hai diversi tipi per diverse strutture, tuttavia il comportamento è importante. Se è possibile piuttosto che creare un nuovo tipo di frutta, descrivere la struttura generica della frutta e creare oggetti per la frutta in calcestruzzo. In questo modo puoi includere un comportamento che descriverà la struttura in Fruit e creare classi di traduzione generiche, che utilizzeranno semplicemente le informazioni sulla struttura per creare gli 8 oggetti necessari quando aggiungi un nuovo tipo di frutta. Questo potrebbe essere fatto anche usando la metaprogrammazione, ma dipende dalla tua lingua, dalle tue capacità e dallo sforzo necessario per creare qualcosa del genere.

Quindi l'idea è di tradurre Coconut.getMilk () e Pear.getSeeds () in Fruit.getAttributes () e così via. Questo aiuta un po '?

    
risposta data 10.09.2010 - 13:03
fonte

Leggi altre domande sui tag