Recientemente realizamos una revisión del código del código Java de la aplicación móvil que fue desarrollado por un contratista externo y notamos que todos los objetos de dominio / objetos de transferencia de datos están escritos en este estilo:
public class Category {
public String name;
public int id;
public String description;
public int parentId;
}
public class EmergencyContact {
public long id;
public RelationshipType relationshipType;
public String medicalProviderType;
public Contact contact;
public String otherPhone;
public String notes;
public PersonName personName;
}Por supuesto, a estos miembros se accede directamente en cualquier otro lugar del código. Cuando preguntamos sobre esto, los desarrolladores nos dijeron que este es un patrón de diseño de mejora del rendimiento habitual que se utiliza en plataformas móviles, porque los dispositivos móviles son entornos de recursos limitados. No parece tener sentido; el acceso a miembros privados a través de captadores / creadores públicos no parece que pueda agregar mucha sobrecarga. Y los beneficios adicionales de la encapsulación parecen superar los beneficios de este estilo de codificación.
¿Es esto generalmente cierto? ¿Es esto algo que normalmente se hace en plataformas móviles por los motivos mencionados anteriormente? Todos los comentarios son bienvenidos y apreciados.
fuente
Respuestas:
Suponiendo que los autores no se molestaron en proporcionar referencias autorizadas para justificar su "decisión de diseño", es bastante seguro considerar esto como un pedo cerebral de codificadores subcalificados.
He estado en la raqueta Java móvil durante varios años (todavía tengo reputación de 2 o 3K SO en etiquetas relacionadas porque lo uso como la forma de no olvidar lo básico), revisé y escribí mucho código, estudié múltiples especificaciones, tutoriales y estilo guías: ninguna de ellas mencionó ni siquiera un poco de diferencia, este tipo de diseño podría haber sido comparado con Java SE. Si está interesado en encontrar estos tutoriales y guías usted mismo, consulte los wikis de etiquetas SO en etiquetas relevantes como java-me , midp , etc.
fuente
Hay una pizca de verdad en la afirmación de su contratista.
Durante algún tiempo, se alentó a los desarrolladores de juegos de Android a evitar getters y setters internos por razones de rendimiento. Sin embargo, este consejo solo se aplica a los desarrolladores de juegos que necesitan llevar los dispositivos al límite y deben sacrificar otros beneficios para lograr sus objetivos. Además, con el lanzamiento de Gingerbread, esto incluso se benefició poco de esta práctica.
Más de una vez, me he reunido con desarrolladores que dan consejos sobre "mejores prácticas" o siguen pautas que son perfectamente válidas en un escenario (a menudo histórico) pero que simplemente no se aplican al caso en cuestión. La mayoría de las veces, esto se debe a que el desarrollador olvidó (o nunca supo) las razones por las cuales su consejo se aplicó en primer lugar, por lo que asume que debe ser válido para todos los casos en todo momento. En mi experiencia, esto es particularmente común cuando se habla de ajuste de rendimiento. Ese parece ser el caso aquí.
El enfoque correcto para el rendimiento es:
fuente
Tiene razón en que por sí solo esto probablemente no sea una diferencia significativa en el rendimiento, pero si es una señal de que, en general, los desarrolladores están atentos a reducir la cantidad de llamadas a métodos (que son relativamente costosas) y otros gastos generales, significa Están haciendo un buen trabajo.
Discutiría más en profundidad con ellos sobre su filosofía general de codificación para ver si esto es a lo que apuntan.
(también está asumiendo que los campos públicos son indudablemente malos y que los captadores / establecedores son la única forma, que no creo que encuentre soporte al 100%, incluso en este sitio)
fuente
Puede ser cierto que históricamente se hizo de esta manera; por ejemplo, porque las plataformas móviles anteriores están particularmente limitadas de recursos ... o tienen optimizadores particularmente pobres (sin nombrar ningún nombre :-)).
Pero no creo que la "práctica habitual" o "práctica histórica" sea relevante. Tiene el derecho absoluto de decir a qué estándares de codificación desea que se adhiera su contratista. Además, si su plataforma no tiene recursos limitados (o lo que sea), la justificación de "práctica habitual" de su contratista está vacía ... porque no existen las condiciones que hacen aceptable esta desafortunada práctica.
fuente
Para los objetos de dominio, este es un diseño basura: desea encapsular la lógica en los objetos de dominio, o al menos desea poder agregar lógica fácilmente más adelante .
Pero para los DTO utilizo un diseño similar, ya que no tienen lógica: son DTO.
Supongo que cualquier sobrecarga de rendimiento (que de todos modos sería minúscula) será optimizada por la máquina virtual de Java de todos modos.
fuente