Los Métodos Get:Uno vs Muchos
https://stackoverflow.com/questions/80892
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
getEmployeeNameByBatchId(int batchID)
getEmployeeNameBySSN de Objeto(SSN)
getEmployeeNameByEmailId(Cadena emailID)
getEmployeeNameBySalaryAccount(SalaryAccount salaryAccount)
o
getEmployeeName(int typeOfIdentifier, byte[] identificador) -> En este método el typeOfIdentifier indica si el identificador es batchID/SSN/emailID/salaryAccount
Que uno de los de arriba es la mejor manera de implementar un método get?
Estos métodos sería en un Servlet y llamadas estarían hechos de una API que serían entregados a los clientes.
Solución
¿Por qué no sobrecargar el getEmployeeName(??) método?
getEmployeeName(int BatchID)
getEmployeeName de objeto(SSN)(mala idea)
getEmployeeName(String Email)
etc.
Parece un buen 'muchos' enfoque de mí.
Otros consejos
Usted podría utilizar algo como esto:
interface Employee{
public String getName();
int getBatchId();
}
interface Filter{
boolean matches(Employee e);
}
public Filter byName(final String name){
return new Filter(){
public boolean matches(Employee e) {
return e.getName().equals(name);
}
};
}
public Filter byBatchId(final int id){
return new Filter(){
public boolean matches(Employee e) {
return e.getBatchId() == id;
}
};
}
public Employee findEmployee(Filter sel){
List<Employee> allEmployees = null;
for (Employee e:allEmployees)
if (sel.matches(e))
return e;
return null;
}
public void usage(){
findEmployee(byName("Gustav"));
findEmployee(byBatchId(5));
}
Si hacer el filtrado por una consulta SQL que utilizaría el Filter interfaz para redactar una cláusula where.
Lo bueno de este método es que puede combinar dos filtros fácilmente con:
public Filter and(final Filter f1,final Filter f2){
return new Filter(){
public boolean matches(Employee e) {
return f1.matches(e) && f2.matches(e);
}
};
}
y utilizarlo como que:
findEmployee(and(byName("Gustav"),byBatchId(5)));
Lo que se obtiene es similar a la Criteria API en modo de Hibernación.
Me gustaría ir con los "muchos" enfoque.Parece más intuitivo para mí y menos propenso a errores.
No me gusta getXByY() - que puede ser fresco en PHP, pero no me gusta en Java (ymmv).
Me gustaría ir con sobrecarga, a menos que tenga las propiedades del mismo tipo de datos.En ese caso, me gustaría hacer algo similar a su segunda opción, pero en vez de usar enteros, yo uso una Enumeración de tipo de seguridad y la claridad.Y en lugar de byte[], yo uso la de Objeto (porque de autoboxing, esto también funciona para las primitivas).
Los métodos son el ejemplo perfecto para el uso de la sobrecarga.
getEmployeeName(int batchID)
getEmployeeName(Object SSN)
getEmployeeName(String emailID)
getEmployeeName(SalaryAccount salaryAccount)
Si los métodos de procesamiento comunes en el interior, sólo tiene que escribir uno más getEmplyeeNameImpl(...) y extraer de allí el código común para evitar la duplicación
La primera opción, sin duda.Ser explícito.Esto será de gran ayuda en el mantenimiento y en realidad no hay inconveniente.
@Esteban:es difícil, la sobrecarga de un caso como este (en general) porque los tipos de parámetro podría no ser discriminativo, por ejemplo,
- getEmployeeNameByBatchId(int batchId)
- getEmployeeNameByRoomNumber(int roomNumber)
Ver también los dos métodos getEmployeeNameBySSN, getEmployeeNameByEmailId en la publicación original.
Voy a utilizar el método explícito nombres.Todo el mundo que mantiene que el código y después me va a entender lo que el método está haciendo sin tener que escribir los comentarios xml.
A veces puede ser más conveniant el uso de la especificación de patrón.
Por ejemplo:GetEmployee(ISpecification<Employee> especificación)
Y, a continuación, iniciar la definición de sus especificaciones...
NameSpecification :ISpecification<Employee>
{
private string nombre;
público NameSpecification(string nombre) { this.nombre = nombre;}
public bool IsSatisFiedBy(Empleado empleado) { return empleado.Nombre == este.nombre;}
}
NameSpecification spec = new NameSpecification("Tim");
Empleado tim = MyService.GetEmployee(spec);
Me gustaría utilizar la primera opción, o sobrecarga en este caso, viendo como tiene 4 parámetros diferentes firmas.Sin embargo, ser específico ayuda a entender el código de 3 meses a partir de ahora.
Es la lógica dentro de cada uno de esos métodos en gran parte de la misma?
Si es así, el único método con el identificador de parámetro puede tener más sentido (simple y la reducción de código redundante).
Si la lógica y los procedimientos varían enormemente entre los tipos, un método por el tipo puede ser preferido.
Como otros sugirieron que la primera opción parece ser la buena.La segunda podría tener sentido cuando estás escribiendo un código, pero cuando llega alguien más adelante, es más difícil de averiguar cómo usar código.( Yo sé, usted tiene comentarios y siempre se puede profundizar en el código, pero GetemployeeNameById es más auto-explicativo)
Nota:Por cierto, el uso de las Enumeraciones podría ser algo a considerar en algunos casos.
En un caso trivial de esta, me gustaría ir con la sobrecarga.Que es:
getEmployeeName( int batchID );
getEmployeeName( Object SSN );
etc.
Sólo en casos especiales habría de especificar el tipo de argumento en el nombre del método, es decir,si el tipo de argumento es difícil de determinar, si existen varios tipos de argumentos tha tiene el mismo tipo de datos (batchId y employeeId, tanto de tipo int), o si los métodos para recuperar el empleado es radicalmente diferente para cada tipo de argumento.
No veo por qué yo nunca lo use esta
getEmployeeName(int typeOfIdentifier, byte[] identifier)
ya que se requiere de ambos llamado y llamante para convertir el valor basado en typeOfIdentifier.Un mal diseño.
Si reescribir la pregunta que usted puede terminar preguntando:
"SELECCIONE el nombre DE ..."
"SELECCIONE EL SSN DE ..."
"SELECCIONE correo electrónico DE ..."
vs
"SELECT * FROM ..."
Y supongo que la respuesta es fácil y todo el mundo lo sabe.
¿Qué sucede si cambia la clase de Empleado?E. g.:Usted tiene que quitar el correo electrónico y agregar un nuevo filtro como departamento.Con la segunda solución tiene un gran riesgo de no darse cuenta de los errores si usted acaba de cambiar el orden de la int identificador "constantes".Con la primera solución que siempre previo aviso, si usted está utilizando el método en algunos olvidado las clases de otra manera te olvides de modificar para el nuevo identificador.
Yo personalmente prefiero tener el explícito nomenclatura "...ByRoomNumber" porque si usted termina para arriba con muchos "sobrecargas" que eventualmente introducir errores no deseados.Ser explícito en mi humilde opinión es la mejor manera.
Estoy de acuerdo con Stephan:Una tarea, un nombre de método, incluso si usted puede hacerlo de varias maneras.La sobrecarga de métodos característica se proporciona exactamente para su caso.
- getEmployeeName(int BatchID)
- getEmployeeName(String Email)
- etc.
Y evitar su segunda solución a toda costa.Huele "a tu olde void * de C".Asimismo, pasando de Java "Objeto" es casi tan pobre estilo como un C "void *".
Si usted tiene un buen diseño debe ser capaz de determinar si puede utilizar la sobrecarga de método o si vas a correr en un problema donde si se sobrecarga vas a terminar encima de tener dos métodos con el mismo tipo de parámetro.
La sobrecarga parece que la mejor manera al principio, pero si que terminan por no ser capaz de añadir un método en el futuro y arruinando las cosas con la nomenclatura que va a ser una molestia.
Personalmente me gustaría para el enfoque de un único nombre por el método, de esta manera no tener problemas más adelante con el intento de sobrecarga de los mismos parámetros a los métodos del Objeto.También, si alguien extendido su clase en el futuro y se implementó un hueco getEmployeeName(String nombre) no anular la suya.
En resumen, el ir con un método único nombre para cada método, la sobrecarga sólo puede causar problemas en el largo plazo.
La disociación entre el proceso de búsqueda y los criterios de búsqueda jrudolf propone, en su ejemplo, es excelente.Me pregunto por qué no es el más votado de la solución.¿Me olvido de algo?
Me gustaría ir con Objetos De Consulta.Funcionan bien para el acceso a las tablas directamente.Si usted está confinado a los procedimientos almacenados, que pierden algo de su poder, pero todavía se puede hacer el trabajo.
El primero es probablemente el mejor en Java, teniendo en cuenta que es typesafe (a diferencia de los otros).Además, para los "normales" de los tipos, la segunda solución parece sólo proporcionan engorroso de uso para el usuario.Sin embargo, puesto que usted está utilizando Objetos como el tipo de número de seguro social (que tiene un significado semántico más allá de Objeto), usted probablemente no va a salir con ese tipo de API.
Todo-en-todo, en este caso en particular me habría utilizado el enfoque con muchos de los captadores.Si todos los identificadores tienen su propio tipo de clase, me podría haber ido la segunda ruta, pero si se cambia internamente en la clase en lugar de un/aplicación definida por el tipo de identificador.
palo de todas sus opciones en un enum, el tener algo como lo siguiente
GetEmployeeName(Enum identifier)
{
switch (identifier)
case eBatchID:
{
// Do stuff
}
case eSSN:
{
}
case eEmailId:
{
}
case eSalary:
{
}
default:
{
// No match
return 0;
}
}
enum Identifier
{
eBatchID,
eSSN,
eEmailID,
eSalary
}
Estás pensando en C/C++.
El uso de objetos en lugar de un identificador de bytes (o int).
Mi Mal, la sobrecarga de enfoque es mejor y usar el número de seguro social como una clave principal no es tan bueno
public ??? getEmployeeName(Object obj){
if (obj instanceof Integer){
...
} else if (obj instanceof String){
...
} else if .... // and so on
} else throw SomeMeaningFullRuntimeException()
return employeeName
}
Yo creo que es mejor para el uso Desenfrenado de las Excepciones a la señalización de entrada incorrecta.
Documento para que el cliente sepa qué objetos a esperar.O crear tus propios envoltorios.Yo prefiero la primera opción.
