Debería cargar los datos de mi Java de los objetos en la construcción, o explícitamente a través de una llamada al método?

Question

Esta es una cuestión de diseño. Estoy tratando de decidir entre 2 implementaciones.

Con el fin de explicar bien esto necesito un ejemplo. Por lo tanto, por el bien de ejemplo:

Tengo una clase que genera un informe sobre, digamos, ciertos valores de mercado en un día específico. Se crea un objeto StockMarketReportGenerator, pasándolo a fecha de hoy, y se genera un informe basado en los valores de mercado de hoy en día.

El StockMarketReportGenerator "tiene un" objeto StockMarketData. La finalidad del objeto StockMarketData es contener todos los valores de la bolsa que se almacenan en una tabla (probablemente llamada Stockmarket :)) en la base de datos, y algunos otros valores calculados a partir de los datos de la tabla. Tiene métodos privados que conectan con la base de datos, recuperar los datos, hacer los cálculos necesarios, y almacenar los valores finales de las variables miembro del objeto. (A continuación, tiene métodos getter para exponer estos valores, pero no hay métodos setter.) La clase StockMarketData es básicamente un "titular" de los valores de datos del mercado de valores. Tengo una función central llama algo así como "calculateStockMarketData()" que llama a todos estos métodos de ayuda privadas y establece el objeto. (Soy consciente de que todo esto procesamiento realmente podría ser más fácilmente manejado por un marco como Hibernate;. Pero la decisión fue tomada para hacerlo de forma manual, ya que es un proyecto muy pequeño, algo temporal y no vale la pena la configuración)

Mi pregunta es la siguiente - de mi clase ReportGenerator, sólo necesito el objeto StockMarketData con el fin de acceder a sus propiedades / variables miembro - post-procesamiento y post-cálculos. Lo que significa que en realidad, quiero conseguir el objeto precargada con datos. Y así sigo el método calculateStockMarketData privado y lo llaman de forma automática desde el StockMarketData constructor. Pero me siento un poco incómodo acerca de hacer todo mi procesamiento en un constructor y luego no tener ningún métodos públicos. Es este un defecto de diseño? O es realmente la forma más lógica de hacer esto? Básicamente, ¿cuál de las siguientes implementaciones 2 es mejor?

1) (Mi implementación actual) Hacer el método calculateStockMarketData() central privado y lo llaman desde el constructor método StockMarketData (que pasa a fecha de hoy), de modo que cada vez que tenga un objeto StockMarketData, ya está lleno. Así que todo lo que necesitaría de la clase ReportGenerator antes de empezar a usar las propiedades del objeto es la línea:

StockMarketData myData = new StockMarketData(someDate);

2) Hacer que el público central método calculateStockMarketData(), por lo que con el fin de establecer un objeto StockMarketData necesita llamar explícitamente al método. Así que desde la clase ReportGenerator Me código:

StockMarketData myData = new StockMarketData(someDate);
myData.calculateStockMarketData();

La primera me parece el mejor diseño, sobre todo porque no hay entonces posibilidad de utilizar las propiedades de los objetos antes de que se inicializan. Pero también estoy seguro acerca de las normas relativas a la ejecución de una gran cantidad de código de un constructor ... ¿Qué debería elegir?

Answer 1

Me gustaría ir con el número 2, especialmente si existe la posibilidad de añadir métodos a la clase que no se basan en que los datos de estar allí.

Por otro lado, si usted consideraría la clase para estar en un estado no válido sin los datos pobladas, debe hacerlo en la construcción.

Answer 2

Martin Fowler ha escrito un buen ensayo sobre inyección de dependencias (Constructor vs inyección Setter) . Su consejo es "tanto como sea posible, para crear objetos válidos en el momento de la construcción".

OMI, lo mejor es construir objetos válidos si es posible, ya que hace que sea más fácil de leer / observar el comportamiento del código, ya que se puede suponer que los objetos se construyen adecuadamente, y usted tiene menos errores relacionados con los objetos no siendo rellenado correctamente. El tema de la moda frente a la inyección de constructor es diferente de lo que se está planteando, sin embargo, que es una cuestión de dónde para ejecutar la lógica de negocio. Creo que lo mejor es utilizar el constructor para crear un objeto válido y luego ejecutar la lógica de negocio real en otro método público (el # 2), por lo que la construcción del objeto puede suceder en un momento diferente de la lógica de negocio real.

Answer 3

I siempre cargar explícitamente, post-construcción.

Llamar a una base de datos desde un constructor puede hacer difícil para la depuración, más frágil código, inflexible, y causar problemas de rendimiento si el uso del objeto cambia.

Answer 4

Una buena práctica consiste en no ejecutar una gran cantidad de código dentro de un constructor.