Tipo persistente in Java - dovrei usare le bandiere?

Question

Tipo persistente in Java - dovrei usare le bandiere?

#1 da (2 voti)

0

C'è qualche consiglio specifico sui valori persistenti che indicano il tipo? Nello specifico voglio sapere se dovrei mantenere un flag / stato che indica il tipo in persistenza o meno. Ho la sensazione che mi sto dimenticando / non capisco un concetto base di OO o modellazione dei dati.

Qualcosa che ho pensato per l'ultima volta è considerare quando usare i flag e quando no, e mescolare l'idea di ricreare oggetti di un certo tipo fuori dalla persistenza.

Il motivo della mia preoccupazione per le bandiere è che nel software che creo spesso (software aziendale creato in-house sviluppato con Java), queste bandiere diventano informazioni difficili da mantenere e di cui gli sviluppatori successivi devono essere a conoscenza al fine di mantenerli (forse creando codice gonfio).

Quindi, quando mantengo il mio foo , dovrei persistere con esso qualche indicatore che indica se è un foobar o un foobo ? C'è un consiglio specifico su questo, qualche lacuna nel mio OO-foo o nella modellazione dei dati che sto dimenticando?

object-oriented maintainability data persistence

posta Crowie 28.04.2014 - 20:22

fonte

1 risposta

Leggi altre domande sui tag object-oriented maintainability data persistence

Hashing + sicurezza in quanto riguarda un sito di condivisione di file teorico Come creare un sistema di punteggio con il tempo e le risposte corrette per un gioco?

score 2 · Accepted Answer

Dipende da dove ti ostini e da cosa persisti. Avrebbe senso utilizzare alcune enumerazioni quando si desidera mantenere una gerarchia di classi e si desidera mantenere tutti gli elementi della gerarchia di classi in un unico punto.

Prendi ad esempio l'ereditarietà della mappatura su una singola tabella in e ORM (ad esempio @Inheritance(strategy = InheritanceType.SINGLE_TABLE in JPA). Supponiamo che tu abbia una superclasse User e due sottoclassi CustomerUser e AdminUser e vuoi che vengano mappati su una singola colonna users . Qui hai bisogno di una colonna di discriminatori per distinguere tra i possibili tipi di utente; questa colonna è meglio una stringa o un enum piuttosto che una bandiera. Questa colonna deve avere il valore customer per le voci che rappresentano CustomerUser e admin per le voci che rappresentano AdminUser .

Ma se non si hanno elementi comuni di classi distinte che hanno una superclasse comune, non ha senso specificare il tipo quando lo si mantiene. Dovresti sapere dal contesto / metadati qual è il tipo (sia un nome di colonna in un database relazionale, un nome del file, un nome di tag in un XML ecc.) E non dovresti accoppiarlo strongmente con il tuo modello di applicazione perché potresti volere che altre applicazioni leggano i dati persistenti. Dato l'esempio precedente potresti anche avere due colonne distinte admin_users e customer_users e quindi non è necessario mantenere il tipo.