Metodi per memorizzare oggetti, ereditati da una superclasse in un database

0

Per il mio progetto personale ho bisogno di memorizzare forme 2D in un database Postgres. Ad esempio Cerchio, Pentagono, Rettangolo e così via. All'inizio l'ho fatto in questo modo: tutte le forme sono ereditate da una classe astratta chiamata Shapes, che ha alcuni metodi con cui ho bisogno che ogni oggetto esegua su se stesso, ad esempio (sto usando java con i dati di Spring):

for(Shape shape : shapes){
    shape.getArea();
}

Questo è buono nel codice, ma non conosco un buon modo per archiviarlo in un database. Ogni forma ha alcuni parametri che sono diversi dagli altri (raggio per cerchio, altezza e lunghezza per rettangolo ecc.) Quindi sembra che mi servano molte tabelle per ogni tipo di geometria. Ma come fare riferimento a ciascuna forma da un'altra tabella?

In questo momento cerco di risolvere questo problema con una singola classe chiamata Geometry. Ha un campo tipo e una serie di parametri ad esso collegati. Cerchio, ad esempio, avrà un record nella tabella Geometria e un record nella tabella Parametri. Questa classe ha anche tutti i metodi necessari per ogni forma disponibile, come questa:

getArea(){
    switch(type){
        case circle: ....
        case pentagon: ...
    }
}

Ma mi chiedo se ci sono modi più eleganti per risolvere questo problema?

    
posta Zmur 19.01.2018 - 02:55
fonte

2 risposte

1

Dipende se vuoi solo memorizzare le forme o eseguire query sulle loro proprietà.

Se vuoi solo memorizzarli, il modo più semplice è serializzarli e archiviare i dati serializzati, insieme a un campo shapeid per farti sapere che tipo di forma hai. Ogni sottoclasse può gestire la propria serializzazione. Molto simile alla memorizzazione di immagini in un database.

Se si desidera eseguire query sulle proprietà di una determinata forma, è necessario esporre tali proprietà come colonne su una tabella o utilizzare i tipi geometrici di PostgreSQL (come menzionato da Patrick Mevzek). Tuttavia, l'utilizzo di tipi da un determinato motore di database non è molto portabile.

    
risposta data 19.01.2018 - 07:05
fonte
0

Per mantenere un programma geometrico complesso con tutti i tipi di forme, è meglio utilizzare il polimorfismo e le classi ereditano da Shape . Ciò renderà il codice più comprensibile e più manutenibile (cioè è più facile aggiungere una nuova forma con polimorfismo piuttosto che con interruttori lunghi).

Ora per la persistenza in un database relazionale, hai molte alternative che sono molto ben descritte nel libro di Martin Fowler " Pattern of Enterprise Application Architecture ":

  • Dato che non ci sono molti parametri per una forma, potresti optare per ereditarietà di tabelle singole : avresti una singola tabella contenente tutti i dati, un po 'come con la classe geometrica.
  • Se le tue forme sarebbero molto complesse, con molti dati diversi, potresti optare per ereditarietà delle tabelle di classe : ogni la classe avrebbe una propria tabella (incluso Shape se avrebbe qualche tipo di dati comuni).
  • Tra entrambi dovresti avere una eredità della tabella concreta , in cui ogni classe derivata avrebbe una propria tabella con tutti i suoi dati (quindi Squares e Circles , ma non Shape stesso.

Quindi il trucco è disaccoppiare un po 'gli oggetti che vivono nella memoria e il modo in cui sono memorizzati nel database.

    
risposta data 19.01.2018 - 09:04
fonte

Leggi altre domande sui tag