Quale motivo di progettazione separa i convertitori di trasformazione

Question

Quale motivo di progettazione separa i convertitori di trasformazione

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

2

Per convertire un modello di oggetti Java in XML sto usando il seguente design:

Per diversi tipi di oggetti (ad es. tipi primitivi, insiemi, null, ecc.) Definisco ciascuno il proprio convertitore , che agisce in modo appropriato rispetto al tipo specificato . In questo modo può essere facilmente esteso senza aggiungere codice a un enorme costrutto if-else-then.

I convertitori sono scelti da un metodo che verifica se l'oggetto è convertibile e utilizzando un ordine di priorità. L'ordinamento prioritario è importante quindi diciamo che List non viene convertito dal convertitore POJO, anche se è convertibile in quanto tale sarebbe più appropriato utilizzare il convertitore di raccolta.

Che modello di progettazione è?

Posso solo pensare ad una somiglianza con lo schema di comando.

design-patterns

posta RevMoon 25.09.2012 - 17:09

fonte

3 risposte

Leggi altre domande sui tag design-patterns

Condivisione di un database mentre lavoriamo su copie locali? Dovrei rappresentare casi speciali (come errori / eccezioni) nei diagrammi UML?

score 2 · Answer 1

Ho la seconda risposta di Awemo; questo suona come il modello della strategia, in cui gli algoritmi che fanno cose simili dati diversi input o output attesi sono incapsulati, e quindi l'algoritmo corretto può essere scelto in fase di esecuzione data la conoscenza dei dati da inserire.

Un commento menzionato "Catena di responsabilità"; questo è correlato ma leggermente diverso e può incorporare un modello di strategia. Fondamentalmente, uno alla volta, in un ordine "molto probabilmente primo" predeterminato o dinamico, l'insieme di input è dato a una delle "strategie" incapsulate. Quella strategia ha la consapevolezza di "decidere" da sé se può fare qualsiasi cosa con gli input. Se è possibile, può elaborare parzialmente o completamente gli input e segnali al "supervisore" principale se pensa che sia necessaria un'ulteriore elaborazione. Se non può, semplicemente contrassegna quel fatto. Il supervisore quindi trova il successivo algoritmo più probabile per gestire l'elaborazione o l'ulteriore elaborazione, fino a quando qualcosa segnala al supervisore che gli input sono stati completamente elaborati.

score 2 · Answer 2

Sembra il modello di progettazione della strategia .

a software design pattern, whereby an algorithm's behaviour can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it...

For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed. The validation strategies, encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication...

Hai diversi algoritmi per cose simili.

score 0 · Answer 3

In un sistema orientato agli oggetti, normalmente si posiziona il comportamento che varia in base al tipo nel tipo (classe AKA) stesso. Ma poiché Java non ti consente di aggiungere nuovi metodi a classi esistenti, a meno che tu non possa usare l'output toString () di tutte o la maggior parte delle classi nel convertitore XML e per reificare le istanze, dovrai ricorrere a un altro modello.

Utilizza il pattern Sovraccarico metodo per richiamare la stessa semantica su tipi diversi. Di solito rende il significato più chiaro rispetto alle linee dei condizionali. Usalo all'interno dell'oggetto invocante o usa il pattern Visitor per creare la classe di implementazione con il pattern Overloading del metodo per evitare il doppio dispiegamento tipico delle implementazioni di Visitor.

Quindi, metodi di overload come

String toXML(Integer anInteger)
{
  String   xmlResult;

  xmlResult = ...
  return (xmlResult);
}

String toXML(String aString)
{
  String   xmlResult;

  xmlResult = ...
  return (xmlResult);
}

String toXML(List aList)
{
  String    xmlResult;

  xmlResult = ...
  return (xmlResult);
}

Potresti quindi trasformare i valori come

  for(Object eachValue : collection)
    xmlString += transformer.toXML(eachValue);

dove raccolta sarebbe il contenitore per i dati da trasformare, xmlString sarebbe il ricettacolo per l'output XML e trasformatore potrebbe essere questo o l'oggetto visitatore.