Progettazione della classe Messaggio in Java

Prima di tutto, questo non è un "problema" che ha bisogno di "modellizzazione". Questo è solo un problema di sintassi.

In secondo luogo, perché mai penseresti di utilizzare un modello di builder per questo? Forse perché leggi "Clean Code", dove a pagina 35 l'autore classifica i metodi in quattro categorie, a seconda che accettino zero, uno, due o il numero incredibilmente alto di tre argomenti , con quattro argomenti essendo, presumibilmente, impensabili? Oh, non preoccuparti di lui, stava solo facendo la sciocca.

Things should be as simple as possible, but not simpler
-Albert Einstein

Methods should accept as few arguments as possible, but not fewer than what they need to do their job.
--Mike Nakis

Generalmente il pattern builder è eccessivo per i messaggi, perché ciò che solitamente si vuole fare con un messaggio è istanziarlo, riempirlo e inviarlo a modo suo usando il minor numero possibile di linee di codice. Idealmente, solo una riga di codice.

Di fatto, l'invio di un messaggio dovrebbe apparire sintatticamente identico all'inserimento di una chiamata di funzione e il fatto che non sia identico nella maggior parte delle lingue tradizionali è una mancanza di quelle lingue. Quello che fondamentalmente vogliamo fare è mettere una chiamata asincrona. Il fatto che un messaggio debba essere usato per ottenere questo è solo un dettaglio di implementazione che dovrebbe essere nascosto da noi, e il fatto che dobbiamo ancora sprecare il nostro tempo occupandoci di dettagli di implementazione come la costruzione, il riempimento e l'invio di messaggi, solo definendo e mantenendo intere gerarchie di classi di messaggi,) mostra solo che le lingue hanno ancora molta strada da fare.

Quindi, in mancanza di meccanismi migliori, il compito di istanziare, riempire e inviare un messaggio non dovrebbe essere più complicato di questo:

sendMessage( new MyMessage( 123, XYZ, configuration, metafile ) );

Ovviamente, la classe MyMessage estende presumibilmente qualche Message class, (che per qualche ragione stai pensando come Header ,) quindi la prima affermazione del costruttore di MyMessage sarà la seguente :

super( version, type );

No, un costruttore non è inaudito per creare messaggi. Spring Integration fa qualcosa di simile con un Builder. I messaggi di Spring Integration hanno una struttura generale come la tua: a payload e a header .

• C'è l'interfaccia Message

  public interface Message<T> {
      T getPayLoad();
      MessageHeaders getHeaders();
  }
  

• La classe MessageHeaders (il tuo Header ) è solo un Serializable POJO che implementa Map<String, Object>

  public final class MessageHeaders implements Map<String, Object>, Serializable { ... }
  

• Il payload è solo un POJO. Hai già ottenuto XYZ

Mettendo tutto insieme, puoi avere

public abstract class XYZMessage implements Message<XYZ>{

   private XYZ payload;
   private Headers headers;

   public abstract XYZ getPayload();
   public abstract getHeaders();

} 

Il tuo builder non apparirà diverso da quello che abbiamo per Spring Integration . Certo, l'implementazione del Framework di primavera è più faticosa di quanto tu abbia mai bisogno, ma potresti ancora prendere in prestito una foglia da essa. Se lo fai, il tuo utilizzo sarebbe pulito come il seguente

Message<Account> m = MessageBuilder.withPayload(a)
                                   .setHeader("VERSION", "123")
                                   .build();