Accettare diversi tipi di argomenti in Java

Question

Questa è una domanda su qualcosa che non sono sicuro su come risolvere in Java. Voglio fare affermazioni triple basate su tre tipi di dati, URI, String o Letterali, ogni tipo è codificato in modo diverso. Ho scritto metodi di codifica che accettano questi tipi.

public static String makeStatement(URI subject, URI predicate, String object) { 
    return " " + encode(subject) + " " + encode(predicate) + " " + encode(object) + ".\n"; 
} 

public static String makeStatement(String subject, URI predicate, String object) { 
    return " " + encode(subject) + " " + encode(predicate) + " " + encode(object) + ".\n"; 
} 

public static String makeStatement(URI subject, URI predicate, Literal object) { 
    return " " + encode(subject) + " " + encode(predicate) + " " + encode(object) + ".\n"; 
} 

private static String encode(String binding) { 
    return "?" + binding; 
} 

private static String encode(URI uri) { 
    return "<" + uri.stringValue() + ">"; 
} 

private static String encode(Literal literal) { 
    return "\"" + literal.stringValue() + "\"" + literal.getDatatype(); 
} 

Ma, come posso accettare qualsiasi combinazione di questi tipi di ciò richiederebbe 9 funzioni makeStatement, che sono fondamentalmente facendo la stessa cosa e che sembra una cattiva idea, soprattutto perché potrebbe essere possibile voglio aggiungere un altro digita più tardi.

Normalmente risponderei a una domanda del genere con il suggerimento di creare una super classe, ma non posso modificare String, URI e Literal. Un'altra opzione sarebbe quella di definire

public static String makeStatement(Object subject, Object predicate, Object object) { 
    String encodedSubject = "", encodedPredicate = "", encodedObject = ""; 
    if (subject.getClass().equals(URI.class)) { 
     encodedSubject = encode((URI) subject); 
} 
    return " " + encode(encodedSubject) + " " + encode(encodedPredicate) + " " + encode(encodedObject) + ".\n"; 
} 

e quindi controllare le classi per ogni argomento, ma questo non considerare molto elegante. Un altro suggerimento sarebbe quello di definire qualcosa come makeStatement (URI subjectURI, String subjectString, Literal subjectLiteral, URI predicateURI .. etc) e quindi controllare quali argomenti sono nulli e passare da lì, ma ciò significherebbe digitare un sacco di null quando chiamo la funzione. Una terza opzione è https://stackoverflow.com/a/12436592/1014666, ma anche in questo caso è necessaria una digitazione aggiuntiva quando si chiama la funzione makeStatement.

Qualche suggerimento?

Answer 1

È possibile utilizzare un builder:

public class StatementMaker { 
    private static String encode(String binding) { 
     return "?" + binding; 
    } 

    private static String encode(URI uri) { 
     return "<" + uri.stringValue() + ">"; 
    } 

    private static String encode(Literal literal) { 
     return "\"" + literal.stringValue() + "\"" + literal.getDatatype(); 
    } 

    public static Statement from(String b) { 
     return new Statement(encode(b)); 
    } 

    public static Statement from(URI b) { 
     return new Statement(encode(b)); 
    } 

    public static Statement from(Literal b) { 
     return new Statement(encode(b)); 
    } 

    public static class Statement { 

     private StringBuilder buf; 
     private Statement(String s) { 
      buf = new StringBuilder(" "); 
      buf.append(s); 
     } 

     public Statement with(String s) { 
      buf.append(" ").append(encode(b)); 
      return this; 
     } 

     public Statement with(URI s) { 
      buf.append(" ").append(encode(b)); 
      return this; 
     } 

     public Statement with(Literal s) { 
      buf.append(" ").append(encode(b)); 
      return this; 
     } 

     public String toString() { 
      return buf.toString() + ".\n"; 
     } 

    } 
} 

È ora possibile costruire affermazione come ad esempio:

StatementMaker.from(subject).with(predicate).with(object).toString()

Nel codice che deve il bilancio è possibile abbreviare il codice ulteriormente con l'importazione statica:

import static my.package.StatementMaker.from;

Poi la dichiarazione è ridotto a:

from(subject).with(predicate).with(object).toString()

È possibile aggiungere altri 3 metodi alla classe interna:

public static class Statement { 

    private StringBuilder buf; 
    private Statement(String s) { 
     buf = new StringBuilder(" "); 
     buf.append(s); 
    } 

    public Statement with(String s) { 
     buf.append(" ").append(encode(b)); 
     return this; 
    } 

    public Statement with(URI s) { 
     buf.append(" ").append(encode(b)); 
     return this; 
    } 

    public Statement with(Literal s) { 
     buf.append(" ").append(encode(b)); 
     return this; 
    } 

    public String and(String s) { 
     buf.append(" ").append(encode(b)); 
     return buf.toString() + ".\n"; 
    } 

    public String and(URI s) { 
     buf.append(" ").append(encode(b)); 
     return buf.toString() + ".\n"; 
    } 

    public String and(Literal s) { 
     buf.append(" ").append(encode(b)); 
     return buf.toString() + ".\n"; 
    } 


    public String toString() { 
     return buf.toString() + ".\n"; 
    } 

} 

Quindi è possibile utilizzare evitare una toString() chiamata in questo modo:

String statement = from(subject).with(predicate).and(object);

Answer 2

L'overloading dei metodi funziona alla grande se ci sono solo poche opzioni. Quello che hai qui è un po 'ossessivo. Non è necessario avere tutte le opzioni se c'è un modo semplice per convertire da uno all'altro.

Quindi dimenticarsi di avere ogni possibilità di scelta e rendere disponibili quelle più utilizzate.

Answer 3

Normalmente risponderei a una simile domanda con il suggerimento di creare una super classe, ma non riesco a modificare Stringa, URI e Letterale. Un'altra opzione sarebbe quella di definire

Avrei optato per un approccio simile, ma invece di estrarre una superclasse, che come hai affermato, non puoi fare, potresti creare un wrapper.

public class LiteralWrapper { 
    private String string = null; 
    private URI uri = null; 
    private Literal literal = null; 

    public LiteralWrapper(String sting) { 
     this.string = string; 
    } 

    public LiteralWrapper(URI uri) { 
     this.uri = uri; 
    } 

    public LiteralWrapper(Literal literal) { 
     this.literal = literal; 
    } 

    // Note that this class is immutable, 
    // so you know you cannot have more than one non-null member. 
    // Probably not a bad idea to add some getters, though. 


    /* The encode functions from your original question */ 

    private static String encode(String binding) { 
     return "?" + binding; 
    } 

    private static String encode(URI uri) { 
     return "<" + uri.stringValue() + ">"; 
    } 

    private static String encode(Literal literal) { 
     return "\"" + literal.stringValue() + "\"" + literal.getDatatype(); 
    } 

    @Override 
    public String toString() { 
     if (literal != literal) { 
      return encode(literal); 
     } 
     if (uri != null) { 
      return encode(uri); 
     } 
     return encode(string); 
    } 
} 

Ora il codice makeStatement diventa banale:

public static String makeStatement(LiteralWrapper subject, LiteralWrapper predicate, LiteralWrapper object) { 
    return " " + subject + " " + predicate + " " + object + ".\n"; 
} 

EDIT:
Come per il commento qui sotto, questo rende chiamando makeStatement un po 'fastidioso. Invece di essere in grado di fare makeStatement(myString, myUri, myLiteral), sei costretto a chiamare makeStatement(new LiteralWrapper(myString), new LiteralWrapper(myUri), new LiteralWrapper(myLiteral)). Questo problema non può essere completamente evitato con la soluzione di data, ma può essere mitigato con l'introduzione di po 'di zucchero sintattico nella forma di metodi di fabbrica:

public static LiteralWrapper wrap(String string) { 
    return new LiteralWrapper(string); 
} 

public static LiteralWrapper wrap(URI uri) { 
    return new LiteralWrapper(uri); 
} 

public static LiteralWrapper wrap(Literal literal) { 
    return new LiteralWrapper(literal); 
} 

Ora, è possibile staticly importare questi involucri, ovunque è necessario utilizzare makeStatement:

import static org.some.package.LiteralWrapper.wrap; 
/* other imports*/ 

public class MyClass { 
    public void someFunction() { 
     /* some business logic */ 

     makeStatemet(wrap(myString), wrap(myURI), wrap(myLiteral)); 
    } 
} 

Answer 4

public static String makeStatement(Object subject, Object predicate, Object object) { 
    return " " + encode(subject) + " " + encode(predicate) + " " + encode(object) + ".\n"; 
} 

private static String encode(Object obj) { 
    String encodedOj =""; 
    if (obj.getClass().equals(URI.class)) { 
     encodedOj = encode((URI) obj); 
    }else if(obj.getClass().equals(Literal.class)){ 
     encodedOj = encode((Literal) obj); 
    }else if(obj.getClass().equals(String.class)){ 
     encodedOj = encode((String) obj); 
    } 
    return encodedOj; 
} 

private static String encode(String binding) { 
    return "?" + binding; 
} 

private static String encode(URI uri) { 
    return "<" + uri.stringValue() + ">"; 
} 

private static String encode(Literal literal) { 
    return "\"" + literal.stringValue() + "\"" + literal.getDatatype(); 
} 

Answer 5

È possibile creare divertente e facile da usare involucro utilizzando metodi factory statici (vedi Effective Java, punto 1) e classi anonime (che si comportano come chiusure).

Ecco come:

public class Item { 

    private static interface Methods { 
     public String encode(); 
    } 

    private final Methods methods; 

    private Item(Methods methods) { 
     this.methods = methods; 
    } 

    public static Item of(final String binding) { 
     return new Item(new Methods() { 
      @Override 
      public String encode() { 
       return "?" + binding; 
      } 
     }); 
    } 

    public static Item of(final URI uri) { 
     return new Item(new Methods() { 
      @Override 
      public String encode() { 
       return "<" + uri.stringValue() + ">"; 
      } 
     }); 
    } 

    public static Item of(final Literal literal) { 
     return new Item(new Methods() { 
      @Override 
      public String encode() { 
       return "\"" + literal.stringValue() + "\"" + literal.getDatatype(); 
      } 
     }); 
    } 

    public String encode() { 
     return methods.encode(); 
    } 
} 

E 'davvero facile aggiungere nuovi tipi supportati (che era uno dei vostri requisiti) con questo approccio: basta creare un nuovo metodo factory statica accettare questo tipo: Item.of(NewType val).

Quindi si avrebbe un metodo:

public static String makeStatement(Item subject, Item predicate, Item object) { 
    return subject.encode() + " " + predicate.encode() + " " + object.encode(); 
} 

e chiamarlo così:

makeStatement(Item.of(subject), Item.of(predicate), Item.of(object)); 

L'aggiunta di nuovi metodi è anche abbastanza facile (ma sarebbe un po 'come la modifica, invece di estensione): basta aggiungerli all'interfaccia Methods e implementare le chiusure per tutti i tipi supportati. Il compilatore ti farà, comunque.