Devo utilizzare la struttura da un kit di strumenti grafici della libreria principale nel mio dominio?

Question

Devo utilizzare la struttura da un kit di strumenti grafici della libreria principale nel mio dominio?

#1 da (1 voti)
#2 da (1 voti)

2

In java (e in molti altri linguaggi di programmazione), ci sono spesso strutture per gestire elementi grafici: Colore, Forma, ecc. Questi sono molto spesso in un toolkit dell'interfaccia utente e quindi hanno un accoppiamento relativamente strong con l'elemento dell'interfaccia utente.

Ora, nel dominio della mia applicazione, ci occupiamo spesso di colori, forme, ecc. per visualizzare informazioni statistiche su un elemento. In questo momento tutto ciò che facciamo è visualizzare / salvare quegli elementi con poco o nessun comportamento. Avrebbe senso evitare "reinventare la ruota" e utilizzare direttamente le strutture in java.awt.* o dovrei creare il mio elemento ed evitare un accoppiamento con questo toolkit? Non è come se quegli elementi stessero andando via in qualunque momento (sono parte della java library di base dopo tutto), ma allo stesso tempo sembra strano importare java.awt.* lato server. Non ho problemi a usare java.util.List ovunque. Dovrei sentirmi diverso da quella classe?

Quale sarebbe la pratica "raccomandata" in quel caso?

java coupling domain-model

posta Laurent Bourgault-Roy 24.10.2012 - 16:35

fonte

2 risposte

1

Finché non lo fai persistere. Una volta creato lo schema RDBMS per mantenere la struttura, dovresti riconsiderare il tuo approccio.

risposta data 24.10.2012 - 17:02

fonte

Leggi altre domande sui tag java coupling domain-model

Objective C style nil in java? wrapper API REST - progettazione della classe per le risposte agli oggetti 'lite'

score 1 · Accepted Answer

Vorrei applicare YAGNI qui e utilizzare le strutture della libreria standard, tuttavia farei attenzione a garantire che tutte le parti del dominio che utilizzano questa roba siano il più vicino possibile nel sistema. Questo renderà la ricerca dell'uso per la sostituzione più tardi banale nel caso in cui finisci per aver bisogno di un decoratore in cima a queste strutture.

Non vuoi che queste strutture finiscano per diffondersi su tutto il tuo codice base, a meno che tu non sia assolutamente certo che i requisiti non cambieranno mai (suggerimento: i requisiti di ogni pezzo di codice che tu scriveresti cambierà sempre). Suppongo che dovrei anche dire, se il loro unico scopo è che il codice sia usato da parti del client che si basano sulle implementazioni standard di java, quindi probabilmente sei sicuro trattandoli come primitivi.