¿Por qué a veces separamos el comportamiento de las clases en Java?

Question

Es una pregunta bastante básica, pero soy nuevo en el diseño de Java para disculparme por favor. :)

Quiero saber en qué escenarios necesitamos separar el comportamiento de la clase de la clase.

por ej.

Si tengo un empleado de la clase, tendré algunos datos en él como - nombre, edad, etc. También esta clase tendrá algún comportamiento como doWork() etc. Ahora, en qué situación podemos tener datos y el comportamiento dentro una vez clase (Empleado) solamente y en qué escenario necesitamos tener 2 clases diferentes para Datos de empleado (EmployeeDTO) y comportamiento (EmployeeService)

Pregunta muy subjetiva pero estoy buscando algunas entradas en un diseño de una pequeña aplicación donde estoy tomando datos de un archivo de texto. ¿Debería poner los datos y el comportamiento en diferentes clases o lo mismo? ¿Cuál será su razón para justificar esta decisión?

PS: Los enlaces a información sobre esto también será muy útil :)

Thankyou

Answer 1

Haga lo más simple posible. Siempre puede hacer que su código sea más generalizado más adelante y existe una buena posibilidad de que ni siquiera tenga que hacerlo.

Aplicar el principio YAGNI cada vez que necesite tomar una decisión. Extreme Programming wiki es también una buena lectura.

Pon todo en una clase en este momento. Cuando vea que su Empleado está demasiado gordo, puede hacer algunas refactorizaciones, por ejemplo, move method a otra clase. En los lenguajes con tipado estático, como Java, es superfácil porque el compilador ayuda mucho y el soporte de IDE es excelente.

La lectura del archivo, por ejemplo, parece un candidato obvio para extraer a una clase de cargador por separado. Por otro lado, si tiene un formato de entrada muy común como XML o JSON, puede crear el método estático List<Employee> Employee.loadFromFile(string fileName) e implementar la lógica de lectura en un par de líneas de código. Es lo suficientemente bueno en este momento: simple, corto y funciona bien.

Mayo ¡El Real Ultimate Programming Power estará contigo!

Answer 2

buenos defensores diseño orientado a objetos que cada clase obedecer la Single Responsibility Principle. Que no puedo resumir más elocuente que la entrada de Wikipedia:

Martin define la responsabilidad como una razón para cambiar, y concluye que una clase o módulo debe tener una, y sólo una, razón para el cambio . Como ejemplo, considere un módulo que compila e imprime un informe . Tal módulo puede ser cambiado por dos razones. Primero, el contenido del informe puede cambiar. En segundo lugar, el formato del informe puede cambio. Estas dos cosas cambian por causas muy diferentes; un sustantivo y un cosmético. El principio de responsabilidad única dice que estos dos aspectos del problema son realmente dos responsabilidades separadas de , y por lo tanto deben estar en clases separadas o módulos . Sería un mal diseño juntar dos cosas que cambian por razones diferentes en momentos diferentes.

Si lo piensas bien, puedes meter todo tu código Java en un archivo de clase, pero no es así. ¿Por qué? Porque quiere poder cambiar, mantener, adaptar y probarlo. Este principio dice que en lugar de dividir arbitrariamente su código en diferentes módulos, debe tomar el tacto de que las cosas se deben dividir por sus responsabilidades lógicas. Esto generalmente significa más pequeños módulos que sabemos que es más fácil de cambiar, mantener, adaptar y probar.

Yo personalmente recomendaría que factorice su código en clases discretas más pequeñas y las combine más adelante si esto no es razonable, esto será obvio para usted. Es mucho más fácil combinar código débilmente acoplado en el futuro que factorizar un código estrechamente acoplado.

Answer 3

Al mantener las lógicas de negocio fuera del pojo, convirtiéndolo así en un objeto de transferencia puro, tiene la ventaja de un acoplamiento flexible si algún día se encuentra en la situación de cambiar el marco Spring por EJB JavaBeans.

Al juntar los datos y la lógica comercial, se convierte en un objeto de dominio. La forma más simple de uso de frijol administrado promovido en JSF2 usa el modelo de dominio por el cual la "acción" se fusiona con los datos del formulario.

Si elige el primer modelo, puede separar claramente las preocupaciones por el diseño de la herencia y el polimorfismo para sus objetos de datos, sin molestarse si los comportamientos definidos tienen sentido, y viceversa.

Answer 4

Utiliza un DTO (como sugiere el acrónimo) cuando desea mover datos con la menor cantidad de peso posible, como por ejemplo a través de un cable de un servicio.

Answer 5

Para el registro

Su dominio rico objeto clásico vs objeto de dominio anémico.

En general, si tiene un objeto UI o un objeto de biblioteca (por ejemplo, la clase Date o la clase TextButton), y puede haber algún otro tipo de objetos, puede envolverlo todo en una sola clase en lugar de se basa en diferentes clases solo para que el producto tenga todos los atributos y métodos en la misma clase.

Sin embargo, para un Objeto de negocios clásico (BO) es diferente. Incluso si desea un objeto de dominio enriquecido, excluyendo algunos otros problemas que no quiero mencionar en este momento, es el hecho de que la capa de servicio comercial (BS) actúa como un "plan de dieta para quemar grasa" y se vuelve cada vez más rico. BO en un BO anémico.

Rich BO -------> BS ----------> Anemic BO.