Modèles de code Java Eclipse Utiles [fermé]

Quelques modèles supplémentaires ici: Link I - Lien II

J'aime celui-ci:

Readfile

 ${:import(java.io.BufferedReader,  
           java.io.FileNotFoundException,  
           java.io.FileReader,  
           java.io.IOException)}  
 BufferedReader in = null;  
 try {  
    in = new BufferedReader(new FileReader(${fileName}));  
    String line;  
    while ((line = in.readLine()) != null) {  
       ${process}  
    }  
 }  
 catch (FileNotFoundException e) {  
    logger.error(e) ;  
 }  
 catch (IOException e) {  
    logger.error(e) ;  
 } finally {  
    if(in != null) in.close();  
 }  
 ${cursor} 

MISE À JOUR : La version Java 7 de ce modèle est:

${:import(java.nio.file.Files,
          java.nio.file.Paths,
          java.nio.charset.Charset,
          java.io.IOException,
          java.io.BufferedReader)}
try (BufferedReader in = Files.newBufferedReader(Paths.get(${fileName:var(String)}),
                                                 Charset.forName("UTF-8"))) {
    String line = null;
    while ((line = in.readLine()) != null) {
        ${cursor}
    }
} catch (IOException e) {
    // ${todo}: handle exception
}

Formater une chaîne

MessageFormat - entourez la sélection d'un MessageFormat.

 ${:import(java.text.MessageFormat)} 
 MessageFormat.format(${word_selection}, ${cursor})

Cela me permet de déplacer un curseur sur une chaîne, d'étendre la sélection à la chaîne entière (Maj-Alt-Up), puis Ctrl-Espace deux fois.

Verrouiller la sélection

Lock - entourez les lignes sélectionnées d'un try finally lock. Supposons la présence d'une variable de verrouillage.

${lock}.acquire();
try {
    ${line_selection}
    ${cursor}
} finally {
    ${lock}.release();
}

NB ${line_selection} apparaissent dans le menuSurround Avec (Alt-Shift-Z).

Je sais que je donne un coup de pied à un poste mort, mais je voulais partager cela pour des raisons d'achèvement:

Une version correcte du modèle de génération singleton, qui surmonte la conception de verrouillage à double vérification défectueuse (discutée ci-dessus et mentionnée ailleurs où)

Modèle de création Singleton: Nommez ceci createsingleton

static enum Singleton {
    INSTANCE;

    private static final ${enclosing_type} singleton = new ${enclosing_type}();

    public ${enclosing_type} getSingleton() {
        return singleton;
    }
}
${cursor}

Pour accéder aux singletons générés en utilisant ci-dessus:

Modèle de référence Singleton: Nommez ceci getsingleton:

${type} ${newName} = ${type}.Singleton.INSTANCE.getSingleton();

Pour log, une petite chanson utile à ajouter dans la variable membre.

private static Log log = LogFactory.getLog(${enclosing_type}.class);

Ajouter un extrait de code pour itérer sur Map.entrySet():

Modèle:

${:import(java.util.Map.Entry)}
for (Entry<${keyType:argType(map, 0)}, ${valueType:argType(map, 1)}> ${entry} : ${map:var(java.util.Map)}.entrySet())
{
    ${keyType} ${key} = ${entry}.getKey();
    ${valueType} ${value} = ${entry}.getValue();
    ${cursor}
}

Code généré:

for (Entry<String, String> entry : properties.entrySet())
{
    String key = entry.getKey();
    String value = entry.getValue();
    |
}

Créer une maquette avec Mockito (dans le contexte" Java statements"):

${:importStatic('org.mockito.Mockito.mock')}${Type} ${mockName} = mock(${Type}.class);

Et dans "Membres de type Java":

${:import(org.mockito.Mock)}@Mock
${Type} ${mockName};

Moquer une méthode void pour lancer une exception:

${:import(org.mockito.invocation.InvocationOnMock,org.mockito.stubbing.Answer)}
doThrow(${RuntimeException}.class).when(${mock:localVar}).${mockedMethod}(${args});

Moquer une méthode void pour faire quelque chose:

${:import(org.mockito.invocation.InvocationOnMock,org.mockito.stubbing.Answer)}doAnswer(new Answer<Object>() {
public Object answer(InvocationOnMock invocation) throws Throwable {
    Object arg1 = invocation.getArguments()[0];
    return null;
}
}).when(${mock:localVar}).${mockedMethod}(${args});

Vérifier la méthode moquée appelée exactement une fois:

${:importStatic(org.mockito.Mockito.verify,org.mockito.Mockito.times)}
verify(${mock:localVar}, times(1)).${mockMethod}(${args});

Vérifier moqué de méthode n'est jamais invoquée:

${:importStatic(org.mockito.Mockito.verify,org.mockito.Mockito.never)}verify(${mock:localVar}, never()).${mockMethod}(${args});

Nouvelle liste chaînée utilisant Google Guava (et similaire pour hashset et hashmap):

${import:import(java.util.List,com.google.common.collect.Lists)}List<${T}> ${newName} = Lists.newLinkedList();

J'utilise également un énorme modèle qui génère un La classe de Test. En voici un fragment raccourci que toutes les personnes intéressées devraient personnaliser:

package ${enclosing_package};

import org.junit.*;
import static org.junit.Assert.*;
import static org.hamcrest.Matchers.*;
import static org.mockito.Matchers.*;
import static org.mockito.Mockito.*;
import org.mockito.Mockito;
import org.slf4j.Logger;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;
import org.junit.runner.RunWith;

// TODO autogenerated test stub
@RunWith(MockitoJUnitRunner.class)
public class ${primary_type_name} {

    @InjectMocks
    protected ${testedType} ${testedInstance};
    ${cursor}

    @Mock
    protected Logger logger;

    @Before
    public void setup() throws Exception {
    }

    @Test
    public void shouldXXX() throws Exception {
        // given

        // when
        // TODO autogenerated method stub

        // then
        fail("Not implemented.");
    }
}
// Here goes mockito+junit cheetsheet

Null vérifie!

if( ${word_selection} != null ){
    ${cursor}
}

if( ${word_selection} == null ){
    ${cursor}
}

Un de mes bien-aimés est foreach :

for (${iterable_type} ${iterable_element} : ${iterable}) {
    ${cursor}
}

Et traceout, depuis que je l'utilise beaucoup pour le suivi:

System.out.println("${enclosing_type}.${enclosing_method}()");

Je viens de penser à un autre et je l'ai trouvé sur Internet un jour, const :

private static final ${type} ${name} = new ${type} ${cursor};

Un petit conseil sur sysout I J'aime le renommer en "sop". Rien d'autre dans les bibliothèques java ne commence par "sop" afin que vous puissiez rapidement taper "sop" et boom, il insère.

Lance une exception IllegalArgumentException avec une variable dans la portée actuelle (illarg):

throw new IllegalArgumentException(${var});

Mieux

throw new IllegalArgumentException("Invalid ${var} " + ${var});  

Rien de fantaisie pour la production de code-mais très utile pour les revues de code

J'ai mon modèle coderev low / med / high faire ce qui suit

/**
 * Code Review: Low Importance
 * 
 *
 * TODO: Insert problem with code here 
 *
 */

Puis dans la vue Tâches - me montrera tous les commentaires de révision de code que je veux faire apparaître lors d'une réunion.

Certains autres modèles ici.

Comprend:

• Créer un objet date à partir d'une date particulière
• Créer une nouvelle ArrayList générique
• Configuration de l'enregistreur
• Log avec le niveau spécifié
• Créer un nouveau HashMap générique
• Parcourir une carte, imprimer les clés et les valeurs
• Analyser un temps en utilisant SimpleDateFormat
• Lire un fichier ligne par ligne
• Log et rethrow une exeption attrapée
• Temps d'exécution d'impression d'un bloc de code
• Créer une minuterie périodique
• Écrire une Chaîne dans un fichier

Enregistrement Slf4j

${imp:import(org.slf4j.Logger,org.slf4j.LoggerFactory)}

private static final Logger LOGGER = LoggerFactory
    .getLogger(${enclosing_type}.class);

Propriété Bean

private ${Type} ${property};

public ${Type} get${Property}() {
    return ${property};
}

public void set${Property}(${Type} ${property}) {
    ${propertyChangeSupport}.firePropertyChange("${property}", this.${property},     this.${property} = ${property});
}

PropertyChangeSupport

private PropertyChangeSupport ${propertyChangeSupport} = new PropertyChangeSupport(this);${:import(java.beans.PropertyChangeSupport,java.beans.PropertyChangeListener)}
public void addPropertyChangeListener(PropertyChangeListener listener) {
  ${propertyChangeSupport}.addPropertyChangeListener(listener);
}

public void addPropertyChangeListener(String propertyName, PropertyChangeListener listener) {
  ${propertyChangeSupport}.addPropertyChangeListener(propertyName, listener);
}

public void removePropertyChangeListener(PropertyChangeListener listener) {
  ${propertyChangeSupport}.removePropertyChangeListener(listener);
}

public void removePropertyChangeListener(String propertyName, PropertyChangeListener listener) {
  ${propertyChangeSupport}.removePropertyChangeListener(propertyName, listener);
}

Post Java 7, un excellent moyen de configurer des enregistreurs qui ont besoin (ou préfèrent) de références statiques à la classe englobante est d'utiliser l'API MethodHandles nouvellement introduite pour obtenir la classe d'exécution dans un contexte statique.

Un exemple d'extrait pour SLF4J est:

private static final Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

En plus d'être un simple extrait dans n'importe quelE, il est également moins fragile si vous refactorisez certaines fonctionnalités dans une autre classe car vous ne porterez pas accidentellement le nom de la classe avec elle.

Invoquer le code sur le thread GUI

Je lie le modèle suivant au raccourci slater pour envoyer rapidement du code sur le thread GUI.

${:import(javax.swing.SwingUtilities)}
SwingUtilities.invokeLater(new Runnable() {      
      @Override
      public void run() {
        ${cursor}
      }
    });

Lors des tests avec du code, j'ai parfois manqué de supprimer certains sysos. Je me suis donc créé un modèle appelé syt.

System.out.println(${word_selection}${});//${todo}:remove${cursor}

Avant de compiler, je vérifie toujours mes TODOs et n'oublierai jamais de supprimer un système.de nouveau.

strf -> String.format("msg", args) assez simple mais économise un peu de frappe.

String.format("${cursor}",)

Obtenir une couleur SWT à partir de l'affichage actuel:

Display.getCurrent().getSystemColor(SWT.COLOR_${cursor})

Avec syncexec

PlatformUI.getWorkbench().getDisplay().syncExec(new Runnable(){
    public void run(){
        ${line_selection}${cursor}
    }
});

Utilisez le modèle de conception singleton:

/**
 * The shared instance.
 */
private static ${enclosing_type} instance = new ${enclosing_type}();

/**
 * Private constructor.
 */
private ${enclosing_type}() {
    super();
}

/**
 * Returns this shared instance.
 *
 * @returns The shared instance
 */
public static ${enclosing_type} getInstance() {
    return instance;
}

Et un equalsbuilder, hashcodebuilder adaptation:

${:import(org.apache.commons.lang.builder.EqualsBuilder,org.apache.commons.lang.builder.HashCodeBuilder)}
@Override
public boolean equals(Object obj) {
    return EqualsBuilder.reflectionEquals(this, obj);
}

@Override
public int hashCode() {
    return HashCodeBuilder.reflectionHashCode(this);
}

Le modèle pour la déclaration logger est génial.

Je crée également linfo, ldebug, lwarn, lerror pour les niveaux de journal que j'utilise plus souvent.

Lerreur:

logger.error(${word_selection}${});${cursor}

Tout créer pour un événement

Puisque les événements sont un peu difficiles à créer en Java-toutes ces interfaces, méthodes et choses à écrire juste pour 1 événement-j'ai fait un modèle simple pour créer tout le nécessaire pour 1 événement.

${:import(java.util.List, java.util.LinkedList, java.util.EventListener, java.util.EventObject)}

private final List<${eventname}Listener> ${eventname}Listeners = new LinkedList<${eventname}Listener>();

public final void add${eventname}Listener(${eventname}Listener listener)
{
    synchronized(${eventname}Listeners) {
        ${eventname}Listeners.add(listener);
    }
}

public final void remove${eventname}Listener(${eventname}Listener listener)
{
    synchronized(${eventname}Listeners) {
        ${eventname}Listeners.remove(listener);
    }
}

private void raise${eventname}Event(${eventname}Args args)
{
    synchronized(${eventname}Listeners) {
        for(${eventname}Listener listener : ${eventname}Listeners)
            listener.on${eventname}(args);
    }
}

public interface ${eventname}Listener extends EventListener
{
    public void on${eventname}(${eventname}Args args);
}

public class ${eventname}Args extends EventObject
{
    public ${eventname}Args(Object source${cursor})
    {
        super(source);
    }
}

Si vous avez des événements qui partagent un seul EventObject, supprimez simplement celui personnalisé inséré par le modèle et modifiez les parties appropriées de raise___() et on____().

J'avais écrit un joli, petit, élégant mécanisme de concours complet en utilisant une interface générique et la classe générique, mais cela ne fonctionnerait pas en raison de la façon dont Java gère les génériques. =(

Modifier : 1) J'ai rencontré le problème où les threads ajoutaient/supprimaient des écouteurs pendant qu'un événement avait lieu. Le List ne peut pas être modifié en cours d'utilisation, j'ai donc ajouté des blocs synchronized où la liste des écouteurs est accessible ou utilisée, verrouillant la liste elle-même.

Insérer les méthodes d'analyse devraient-donné-quand-alors

J'ai vu une version similaire à celle-ci récemment alors que j'associais la programmation à un très bon développeur et ami, et je pense que cela pourrait être un bel ajout à cette liste.

Ce modèle créera une nouvelle méthode de test sur une classe, suivant l'approche Given - When - Thendu paradigme behavior-driven development (BDD) sur les commentaires, comme guide pour structurer le code. Il va démarrer le nom de la méthode avec "devrait" et vous permet de remplacer le reste du nom de la méthode factice "CheckThisAndThat" par la meilleure description possible de la responsabilité de la méthode d'essai. Après avoir rempli le nom, TAB vous mènera directement au // Given section, de sorte que vous pouvez commencer à taper vos conditions préalables.

Je l'ai mappé aux trois lettres "tst" , avec la description "Les méthodes de test devraient-être données-quand-alors";)

J'espère que vous le trouverez aussi utile que lorsque je l'ai vu:

@Test
public void should${CheckThisAndThat}() {
    Assert.fail("Not yet implemented");
    // Given
    ${cursor}

    // When


    // Then

}${:import(org.junit.Test, org.junit.Assert)}

Injection de ressort

Je sais que c'est un peu en retard dans le jeu, mais en voici un que j'utilise pour l'injection de ressort dans une classe:

${:import(org.springframework.beans.factory.annotation.Autowired)}
private ${class_to_inject} ${var_name};

@Autowired
public void set${class_to_inject}(${class_to_inject} ${var_name}) {
  this.${var_name} = ${var_name};
}

public ${class_to_inject} get${class_to_inject}() {
  return this.${var_name};
}

Voici un constructeur pour les classes non instanciables:

// Suppress default constructor for noninstantiability
@SuppressWarnings("unused")
private ${enclosing_type}() {
    throw new AssertionError();
}

Celui-ci est pour les exceptions personnalisées:

/**
 * ${cursor}TODO Auto-generated Exception
 */
public class ${Name}Exception extends Exception {
    /**
     * TODO Auto-generated Default Serial Version UID
     */
    private static final long serialVersionUID = 1L;    

    /**
     * @see Exception#Exception()
     */
    public ${Name}Exception() {
        super();
    }

    /**
     * @see Exception#Exception(String) 
     */
    public ${Name}Exception(String message) {
        super(message);         
    }

    /**
     * @see Exception#Exception(Throwable)
     */
    public ${Name}Exception(Throwable cause) {
        super(cause);           
    }

    /**
     * @see Exception#Exception(String, Throwable)
     */
    public ${Name}Exception(String message, Throwable cause) {
        super(message, cause);
    }
}

J'aime un commentaire de classe généré comme ceci:

/**
 * I... 
 * 
 * $Id$
 */

Le "I..."encourage immédiatement le développeur à décrire ce que fait la classe. Je semble améliorer le problème des classes sans papiers.

Et bien sûr Id Id is est un mot clé CVS utile.

J'ai eu beaucoup d'utilisation de ces extraits, à la recherche de null valeurs et chaînes vides.

J'utilise les modèles "argument test"comme premier code dans mes méthodes pour vérifier les arguments reçus.

TestNullArgument

if (${varName} == null) {
    throw new NullPointerException(
        "Illegal argument. The argument cannot be null: ${varName}");
}

Vous pouvez modifier le message d'exception pour l'adapter à la norme de votre entreprise ou de votre projet. Cependant, je recommande d'avoir un message qui inclut le nom de l'argument incriminé. Sinon l'appelant de votre méthode devra regardez dans le code pour comprendre ce qui a mal tourné. (Un NullPointerException sans message produit une exception avec le message assez absurde "null").

TestNullOrEmptyStringArgument

if (${varName} == null) {
    throw new NullPointerException(
        "Illegal argument. The argument cannot be null: ${varName}");
}
${varName} = ${varName}.trim();
if (${varName}.isEmpty()) {
    throw new IllegalArgumentException(
        "Illegal argument. The argument cannot be an empty string: ${varName}");
}

Vous pouvez également réutiliser le modèle de vérification null ci-dessus et implémenter cet extrait pour vérifier uniquement les chaînes vides. Vous utiliseriez ensuite ces deux modèles pour produire le code ci-dessus.

Le modèle ci-dessus, cependant, le problème est que si l'argument est définitive vous sera avoir à modifier le code produit certains (la ${varName} = ${varName}.trim() échouera).

Si vous utilisez beaucoup d'arguments finaux et que vous voulez vérifier les chaînes vides mais que vous n'avez pas à les couper dans le cadre de votre code, vous pouvez aller avec ceci à la place:

if (${varName} == null) {
    throw new NullPointerException(
        "Illegal argument. The argument cannot be null: ${varName}");
}
if (${varName}.trim().isEmpty()) {
    throw new IllegalArgumentException(
        "Illegal argument. The argument cannot be an empty string: ${varName}");
}

TestNullFieldState

J'ai également créé des extraits pour vérifier les variables qui ne sont pas envoyées en tant qu'arguments (la grande différence est le type d'exception, maintenant un IllegalStateException plutôt).

if (${varName} == null) {
    throw new IllegalStateException(
        "Illegal state. The variable or class field cannot be null: ${varName}");
}

TestNullOrEmptyStringFieldState

if (${varName} == null) {
    throw new IllegalStateException(
        "Illegal state. The variable or class field cannot be null: ${varName}");
}
${varName} = ${varName}.trim();
if (${varName}.isEmpty()) {
    throw new IllegalStateException(
        "Illegal state. The variable or class field " +
            "cannot be an empty string: ${varName}");
}

TestArgument

Il s'agit d'un modèle général pour tester une variable. Il m'a fallu quelques années pour vraiment apprendre à apprécier celui-ci, maintenant je l'utilise beaucoup (en combinaison avec les modèles ci-dessus, bien sûr!)

if (!(${varName} ${testExpression})) {
    throw new IllegalArgumentException(
        "Illegal argument. The argument ${varName} (" + ${varName} + ") " +
        "did not pass the test: ${varName} ${testExpression}");
}

Vous entrez un nom de variable ou une condition qui renvoie une valeur, suivie par un opérande ("==", "" etc) et une autre valeur ou variable et, si le test échoue le code résultant lancera une exception IllegalArgumentException.

La raison de la clause if légèrement compliquée, avec toute l'expression enveloppée dans un "!() "est de permettre de réutiliser la condition de test dans le message d'exception.

Peut-être que cela déroutera un collègue, mais seulement s'il doit regarder le code, ce qu'il pourrait ne pas avoir à faire si vous lancez ce genre d'exceptions...

Voici un exemple avec des tableaux:

public void copy(String[] from, String[] to) {
    if (!(from.length == to.length)) {
        throw new IllegalArgumentException(
                "Illegal argument. The argument from.length (" +
                            from.length + ") " +
                "did not pass the test: from.length == to.length");
    }
}

, Vous obtenez ce résultat par appeler le modèle, en tapant " de.longueur" [TAB] " = = à.longueur".

Le résultat est beaucoup plus drôle qu'une "ArrayIndexOutOfBoundsException" ou similaire et peut en fait donner à vos utilisateurs une chance de comprendre le problème.

Profitez-en!

Je l'utilise pour MessageFormat (en utilisant Java 1.4). De cette façon, je suis sûr que je n'ai pas de concaténations difficiles à extraire lors de l'internationalisation

I18n

String msg = "${message}";
Object[] params = {${params}};
MessageFormat.format(msg, params);

Aussi pour la journalisation:

Log

if(logger.isDebugEnabled()){
  String msg = "${message}"; //NLS-1
  Object[] params = {${params}};
  logger.debug(MessageFormat.format(msg, params));
}

Mes préférés sont...

1: Javadoc, pour insérer un document sur la méthode étant une méthode d'injection d'objet Spring.

 Method to set the <code>I${enclosing_type}</code> implementation that this class will use.
* 
* @param ${enclosing_method_arguments}<code>I${enclosing_type}</code> instance 

2: Fenêtre de débogage, pour créer un FileOutputStream et écrire le contenu du tampon dans un fichier. Utilisé lorsque vous souhaitez comparer un tampon avec une exécution passée (en utilisant BeyondCompare), ou si vous ne pouvez pas afficher le contenu d'un tampon (via inspect) car il est trop grand...

java.io.FileOutputStream fos = new java.io.FileOutputStream( new java.io.File("c:\\x.x"));
fos.write(buffer.toString().getBytes());
fos.flush();
fos.close();