¿Es aconsejable tener un método estático sea responsable de crear el objeto de la clase que reside en?

harke:

Me encontré con este tipo de código recientemente:

final class OnlyMe {
 private int a;
 private int b;

 //setter and getters for a and b.

 private OnlyMe(){}

 public static OnlyMe getOnlyMeObj(int c) {
 // use c value to connect to database
 // to populate a and b     
 if(rs.next()) {
  OnlyMe onlyMe = new OnlyMe();
  onlyMe.a = rs.getInt(1);
  onlyMe.b = rs.getInt(2);

  return onlyMe;
 } 

 // return null for everything else.
 // assume the code is under try-catch block.
 return null;
}

Por lo tanto, es parece como el 'getOnlyMeObj (int)' podría ser extraído a otra clase. Pero parece que el desarrollador quería esta clase sólo a ser creado por ese método dependiendo de la entrada a ese método.

¿Cuál sería una razón para ello?

Es algún tipo de patrón o anti-patrón o sin patrón?

¿Hay una solución mejor?

Louis Arpad:

Este es un patrón de fábrica estática. La idea es crear instancias de un objeto a través de un método estático (de nivel de clase) y devolverlo. Hay varios usos posibles de este patrón:

  • puede haber varios constructores posibles y es posible que desee evitar que el código que necesita una nueva instancia elegir el constructor
  • si hay varias fábricas, confusión puede ser reducido por su denominación
  • De esta manera se tiene la opción de validación de algunos parámetros y una instancia única si son válidos
  • usted puede tener fábricas, que podría volver subclases, no necesariamente lo mejor que puede hacer, pero sigue siendo una opción

ver: ver: https://www.youtube.com/watch?v=sOpbAOX5nJs

Supongo que te gusta

Origin http://43.154.161.224:23101/article/api/json?id=221531&siteId=1
Recomendado
Clasificación