Estendi la struttura ad oggetti ereditata dalla libreria

0

Ho creato una libreria / pacchetto di base contenente la classe Type e i suoi child ObjectType e PrimitiveType .

In aggiunta a ciò, ho 3 diversi casi d'uso per questa classe di tipi che logicamente appartiene ad altri pacchetti.

  1. Rendering di un tipo di dati in una classe generata (parametro o tipo di ritorno), ad es. toCode() = > %codice%
  2. Rendi un tipo di dati nella documentazione, ad es. ?int = 3 = > %codice%
  3. Converti un tipo di dati del linguaggio di programmazione in un tipo di database, ad es. toDoc() = > %codice%

Ovviamente voglio usare il pacchetto base senza dipendenze dal pacchetto "generator" o "ORM".

Vorrei anche usare qualsiasi combinazione di tutti e 3 i pacchetti.

Sono abbastanza sicuro di non essere il primo con un problema del genere. Esiste uno schema di progettazione per questo scenario oltre al GoF?

La duplicazione della gerarchia degli oggetti in ogni pacchetto impedirà un utilizzo misto, a condizione che non risolvi l'ordine. (ad esempio, Base > ORM > Generator)

Né un Decoratore , un Adapter né alcuno degli altri wrapper sembrano risolvere il mio problema in modo generico.

Mixins ecc. e AOP non sono supportati. E int|null perderà qualsiasi tipo di sicurezza.

Mi sto avvicinando al punto pensando che un toDatabaseType() per pacchetto come TINYINT(1) sia l'approccio più pulito supponendo che in futuro non ci sarà "nuovo" extending the class at runtime s.

Forse ho bisogno di riformulare la mia domanda. A partire dal modello di seguito

Vorrei spostare il switch -methods per possedere pacchetti indipendenti. Esiste uno schema comune o meno comune per risolvere questo problema?

    
posta mheinzerling 28.12.2016 - 19:19
fonte

0 risposte

Leggi altre domande sui tag