Captadores/Configuradores. Demonio. Y punto

Artículo de Egor Bugaenko 19 de septiembre de 2014 | Publicado en: Core Java Este viejo debate fue iniciado por Allen Holub en su famoso artículo, allá por 2003, ¿ Por qué los métodos getter y setter son malos ? ¿Son los getter/setter un antipatrón y deberíamos evitarlos, o es algo que debemos evitar? seguro que se necesita en la programación orientada a objetos. Agregaré mi granito de arena a esta discusión. La esencia del texto siguiente es la siguiente: los captadores y definidores son malas prácticas; quienes los utilizan no tienen excusa. Pero nuevamente, para evitar malentendidos, no estoy sugiriendo en absoluto que se deba evitar el uso de get/set siempre que sea posible. No. Estoy diciendo que ni siquiera les permitiste acercarse a tu código . ¿Qué opinas de esta declaración? ¿Digno de tu atención? ¿Ha estado utilizando el patrón get/set durante 15 años y es un arquitecto de Java respetado? ¿Y ni siquiera quieres escuchar estas tonterías de boca de un extraño? Bueno... entiendo tus sentimientos. Sentí lo mismo hasta que encontré el libro de David West "Object Thinking": es el mejor libro sobre programación orientada a objetos que he leído. Así que por favor. Cálmate y trata de entender lo que estoy tratando de explicar. Tema de controversia Hay varios argumentos en contra de los "accesores" (otro nombre para captadores y definidores) en el mundo orientado a objetos. Y todos ellos son argumentos muy correctos. Echemos un vistazo rápido a ellos. Pregunte, no diga : Allen Holub dice: "No pida la información que necesita para hacer un trabajo; 'pida' a la entidad que tiene esa información que haga el trabajo por usted". Principio de encapsulación violado : un objeto puede ser desarmado por otros objetos porque pueden incrustar cualquier dato en el objeto, a través de configuradores. Un objeto simplemente no puede encapsular su propio estado de forma suficientemente segura porque cualquiera puede cambiar ese estado. Detalles de implementación revelados : si puede obtener un objeto de otro objeto, entonces estamos confiando demasiado en los detalles de implementación del primer objeto. Si mañana cambia (por ejemplo, el tipo de resultado), entonces tendremos que cambiar el código. Todas las justificaciones anteriores ciertamente tienen sentido, pero esto pasa por alto el punto más importante. Concepto erróneo básico La mayoría de los programadores creen que un objeto es una estructura de datos con métodos. Cito el artículo de Bozhidar Bozhanov: Los captadores y definidores no son malos.. Pero la mayoría de los objetos para los que se crean captadores y definidores simplemente contienen datos. ¡Esta idea errónea es el resultado de un gran malentendido! Los objetos no "solo almacenan datos". Los objetos no son estructuras de datos con métodos adjuntos. Este concepto de "almacenamiento de datos" provino de la programación orientada a objetos y de los lenguajes procedimentales, especialmente C y COBOL. Lo repetiré nuevamente: un objeto no es solo una colección de elementos de datos y funciones que los manipulan. Un objeto no es un objeto de datos. ¿Entonces que? Ball and Dog En la verdadera programación orientada a objetos, los objetos son seres vivos, como tú y como yo. Son organismos vivos, con comportamiento, propiedades y ciclo de vida propios. ¿Puede un organismo vivo tener un setter? ¿Puedes colocar (“colocar”) una pelota en un perro? No pienses. Pero eso es exactamente lo que hace el siguiente código:

Dog dog = new Dog();
dog.setBall(new Ball());

Entonces ¿cómo te gusta? ¿Puedes sacar (“sacar”) la pelota del perro? Bueno, supongamos que puedes. En caso de que se lo comiera y la operaras. En este caso, sí, podrás quitar (“sacar”) la pelota del perro. Esto es exactamente de lo que estoy hablando:

Dog dog = new Dog();
Ball ball = dog.getBall();

O un ejemplo aún más ridículo:

Dog dog = new Dog();
dog.setWeight("23kg");

¿Te imaginas esto en la vida real? ¿Parece que escribes todos los días? En caso afirmativo, entonces es un programador de procedimientos. Solo admítelo. Esto es lo que dice David West en la página 30 de su libro: El primer paso para transformar un desarrollador procedimental exitoso en un desarrollador objetivo exitoso es una lobotomía. ¿Necesitas una lobotomía? Definitivamente lo necesitaba y lo obtuve mientras leía el libro de West "Object Thinking". Pensamiento objetivo Empiece a pensar como un objeto e inmediatamente cambiará el nombre de estos métodos. Esto es lo que podría obtener:

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

Ahora tratamos al perro como a un animal real que puede quitarnos la pelota y devolvértela si se la pedimos. Por las dudas, observo que el perro no puede devolver NULL. ¡Los perros simplemente no saben qué es NULL! El pensamiento objetivo (pensamiento) elimina inmediatamente las referencias NULL de su código. Un pez llamado Wanda (1988) de Charles Crichton Además, el pensamiento objetivo conducirá a la inmutabilidad de un objeto, como el "peso del perro" en nuestro ejemplo. Reescribirías el código de esta manera:

Dog dog = new Dog("23kg");
int weight = dog.weight();

Un perro es un organismo vivo inmutable que no permitirá que nadie externo cambie su peso, tamaño, nombre, etc. Puede "decir", si se le solicita, su peso o su nombre. No hay nada de malo en los métodos públicos que exponen consultas sobre ciertas propiedades "internas" de un objeto. Pero estos métodos no son "captadores" y nunca deberían recibir el prefijo "obtener". No "salimos" del perro. No sabemos su nombre. Le pedimos que nos diga su nombre. ¿Ves la diferencia? Ni siquiera estamos hablando de semántica aquí. Diferenciamos el enfoque procedimental de la programación del orientado a objetos. En la programación procedimental trabajamos con datos, los manipulamos, los obtenemos, los configuramos y los eliminamos si es necesario. Nosotros estamos a cargo y los datos son simplemente un componente pasivo. Un perro no es nada para nosotros: simplemente "contiene datos". Ella no tiene vida propia. Podemos obtener (obtener) libremente todo lo que necesitamos y poner (configurar) cualquier dato en él. Así funcionan (funcionan) C, COBOL, Pascal y otros lenguajes procedimentales. Y la situación es completamente opuesta en el mundo orientado a objetos. Aquí tratamos a los objetos como organismos vivos, con su propia fecha de nacimiento y momento de muerte, con su propia personalidad y hábitos, si se quiere. Podemos pedirle al perro que nos dé un dato (por ejemplo, su peso) y él nos puede devolver la información. Pero recuerda siempre que el perro es el componente activo. Ella decide qué sucede después de la solicitud. Y es por eso que es absolutamente incorrecto que los métodos de un objeto comiencen con set o get. Y ni siquiera se trata de violar la encapsulación, como mucha gente piensa. Se trata del hecho de que o estás pensando como un objeto o todavía estás escribiendo COBOL con sintaxis Java. PD . Y sí, puede preguntarse: "¿Qué pasa con JavaBeans, JPA, JAXB y muchas otras API de Java que dependen de get/set?" ¿Qué pasa con la función incorporada en Ruby que facilita la creación de descriptores de acceso? Bueno, ¿qué puedo decirte? No tienes suerte. Es mucho más fácil permanecer en el mundo primitivo del COBOL procedimental que comprender y abrazar el maravilloso mundo de los objetos reales. P.P.S._ _ Olvidé decir que sí, insertar dependencias mediante un configurador también es un antipatrón terrible. ¡Pero más sobre eso en la próxima publicación! Artículo original