Aclaro el siguiente punto: si quién escribe este artículo es un novato, procederé con mucha cautela y cariño (sin perder la firmeza), pero si el que escribe es un desarrollador que se auto-promociona como "Senior" y a su vez como "docente", seré "despiadado".
El siguiente artículo (del mismo autor) se titula "Devolviendo mas de un valor en un metodo" y dice lo siguiente:
"Hay caso que nuestro metodo necesitamos que devuelva mas de un valor (esto no deberia ser siempre, ya que un metodo solo hace una cosa y no mas). Esto generalmente se resuelve devolviendo un array. Pero hay otra forma un poco mas clara fuera de la clase, y esto es recibiendo los parametros en una lista, el metodo nos va a devolver un array pero el que recibe los datos va a devolverlo en variables, usando la funcion List."
Amén que todo el párrafo es inentendible, me voy a detener solo en lo resaltado:
"Hay caso que nuestro metodo necesitamos que devuelva mas de un valor (esto no deberia ser siempre, ya que un metodo solo hace una cosa y no mas)"
Volvemos a lo que comentaba en el artículo anterior. Aquí el autor está repitiendo una frase que debe haber escuchado de alguna otra persona o leído en algún otro escrito y lo repite mecánicamente sin razonarlo en absoluto.
Esto en realidad se llama (para más información ver un post antiguo):
SRP - Single Responsibility Principle (Principio de Responsabilidad Única)
Enunciado formal: "Una clase debería tener solo una razón para cambiar"
Por consiguiente, es correcto que una clase debe tener una sola responsabilidad, es correcto que un método debería tener una sola responsabilidad, pero esto no tiene nada que ver con que devuelva uno o más valores, ya que no tiene sentido y se demuestra que el concepto no se entendió en absoluto y lo que se repite es lisa y llanamente pura desinformación.
Intentando seguir el razonamiento, si no se pudiera devolver "más de un valor", nunca podríamos pedirle a una clase de persistencia que nos devuelva un array con el resultado de una consulta sql, ya que nos estaría "retornando más de un valor".
Ridículo, no tiene sentido, no importa por donde lo mires.
PD: nota complementaria, me tomé el trabajo de corregir la entrada de la wiki donde se apoyaba el anterior artículo criticado, ya que no era preciso y genera que personas sin experiencia copien y reproduzcan sin entender que lo que se dice no es correcto.
19 comentarios:
Sin tener relación con el sujeto que escribió el documento original ese problema original de los lenguajes más rígidos, tal como es C/C++ donde se usan variables pasadas por referencia para capturar en ellas algunos valores del proceso que no podían ser retornados por el hecho de que este el retorno de una función de esta limitado a un solo elemento.
Siguiendo la historia encontramos la primera forma normal(NF1) en la que se expresa entre otras cosas que los elementos de las bases de datos no pueden ser listas, solo atómicos, ¿pero que pasa si un tipo de dato atómico es una lista?. De esta forma, una función o método que retorna un arreglo retorna uno y solo un elemento, porque es un y solo un tipo de dato, que en su interior pueda encapsula varios estro tema, por lo que desde otro aspecto se podría considerar ridículo pensar que una consulta SQL nos devolviera más de un valor, pues la respuesta es que devuelve un solo valor que es arreglo con cero o más filas.
Está claro que el tío o no se ha enterado de nada, o se ha equivocado. Esperemos que sea lo segundo...
Estimado Alejandro Henríquez Lazo:
Creo que estás mezclando cosas, y a pesar de todo, la idea que expreso está basada en seguir el "razonamiento" del autor original, para concluir luego que "no es lógico".
> De esta forma, una función o
> método que retorna un arreglo
> retorna uno y solo un elemento,
> porque es un y solo un tipo de
> dato, que en su interior pueda
> encapsula varios estro tema, por
> lo que desde otro aspecto se
> podría considerar ridículo
> pensar que una consulta SQL nos
> devolviera más de un valor, pues
> la respuesta es que devuelve un
> solo valor que es arreglo con
> cero o más filas.
Estás entreverando, las cosas son mucho más sencillas.
Punto 1) sigo el razonamiento que él hace, lo cual es un contexto definido y no el que tú planteas.
Punto 2) el autor quiso decir que un método "debe devolver un solo valor" y no puede devolver "más de uno", por consiguiente la forma que podría usar para poder devolver "más de un valor" es un array o un objeto.
De todas formas, conceptualmente lo que quiere transmitir es erróneo y ese es el punto de la crítica.
Este tipo de cosas se fomentan directamente desde el core de PHP.
Esto es asi por una cuestión básica: SIMPLICIDAD. Es más simple devolver un array que devolver lo que sería en realidad correcto: un objeto de instancia de fecha.
Las únicas funciones de PHP que devuelven instancias de clases son las fábricas o funciones helpers muy específicas.
Las funciones getdate o strpdate devuelven muchos valores mediante el uso de arrays.
Otro ejemplo: hay funciones de PHP que devuelven diferentes tipos de datos. La funcion strpos devuelve un integer en caso de encontrar el string, o un boolean false en caso contrario.
Entonces, para ver si un substring esta dentro de un string hay que hacer:
a)
if (strpos($haystack, $needle))
b)
if (strpos($haystack, $needle) !== false)
hay que hacer la pregunta por false con el operador especificamente tipado porque en caso que el substring esté en la posicion cero, la expresión seria false y sería como que no se encontró.
Buscar una aguja en un pajar con PHP es algo bastante delicado.
¿Está mal? Si, es un jodido problema. Hay que tener siempre a mano la documentación para ver esos casos especiales.
Saludos =)
Teniendo en cuenta que la serialización y la persistencia son conceptos que se aplican a cualquier estructura de datos (no sólo objetos, en C no hay objetos) creo, Enrique, que te has quedado algo corto con la corrección de la Wikipedia (p.ej. la entrada en inglés no hace referencia a "Persistencia de objetos", sino a "Estructuras de datos persistentes", y no hace ni una sóla referencia a objetos ni a OOP).
Estimado ramonono | Maeghith
> Teniendo en cuenta que la
> serialización y la persistencia
> son conceptos que se aplican a
> cualquier estructura de datos
> (no sólo objetos, en C no hay
> objetos) creo, Enrique, que te
> has quedado algo corto con la
> corrección de la Wikipedia
Estoy de acuerdo, solo hice una corrección rápida al texto anterior que decía cualquier disparate.
> (p.ej. la entrada en inglés no
> hace referencia a "Persistencia
> de objetos", sino a "Estructuras
> de datos persistentes", y no
> hace ni una sóla referencia a
> objetos ni a OOP).
Bien, me parece mucho mejor. Creo que ahí deberías tú hacer las correcciones así todos podemos leerlo (agregar esta aclaración que estás haciendo, ya que me parece muy pertinente).
Buen aporte ;-)
Hola, creo que lo que el autor del texto intento explicar es la siguiente accion
list($a, $b, $c) = mi_funcion();
donde el valor que retorna mi_funcion es un array
por ejemplo
function mi_funcion() {
return array(1, 2, 3);
}
y list se encarga de cargar los valores en $a, $b y $c.
Por supuesto el tipo se enredo demasiado y no quedo claro nada en absoluto, tuve que releer tres veces para medio saber de que hablaba :)
Creo que esto complementa un poco la aclaracion de Enrique.
Saludos.
¿de verdad hace falta entrar en descalificaciones para explicar algo?
Es decir; parte del post me parece bastante didáctico y ayuda a aclarar algunas cosas. Pero leyendo el titular y la primera parte de la entrada, esto parece más bien un programa de Laura Bozzo en el que la única razón de existencia es "quien grita más".
Personalmente creo que este tipo de post solo hacen crecer un mal karma
Estimado Acido 69:
> ¿de verdad hace falta entrar
> en descalificaciones para
> explicar algo?
Ya expliqué mis razones, te pueden gustar o no.
No soy de criticar sin fundamento, investiga un poco más.
Estimado emilio.rst:
> Hola, creo que lo que el
> autor del texto intento explicar
> es la siguiente accion
Me queda claro lo que intentó y no pudo, el punto que destaco no fue a continuación sino la barbaridad que argumenta al principio, lo cual no tiene ni pié ni cabeza, con el solo hecho de intentar vender que sabe, cuando en realidad es un ignorante que repite términos sin entender.
Este tipo de artículos son los que hacen mal a toda la comunidad de PHP.
Y lamentablemente, Internet está lleno de charlatanes.
Enrique Place
>Este tipo de artículos son los que hacen >mal a toda la comunidad de PHP.
Es algo muy cierto...
Correcto, el tipo habra estado delirando o algo asi :)
Estimado Alejo:
La verdad que me costó mucho entender lo que quisiste decir, te lo comento entre párrafos.
> Este tipo de cosas se
> fomentan directamente desde el
> core de PHP.
¿Que cosas?
> Esto es asi por una cuestión
> básica: SIMPLICIDAD. Es más
> simple devolver un array que
> devolver lo que sería en
> realidad correcto: un objeto de
> instancia de fecha.
Disculpa, me parece que estás divagando un poco ;-). En sí PHP te devolvería algo de tipo "fecha" si tuviera ese tipo de valor. Como no existe, o te devuelve un valor o una estructura de datos que tú elijas (de las disponibles): array o object.
> Las únicas funciones de PHP
> que devuelven instancias de
> clases son las fábricas o
> funciones helpers muy
> específicas.
¿Cuales helpers o fábricas cuenta PHP en sus funciones?
> Las funciones getdate o
> strpdate devuelven muchos
> valores mediante el uso de
> arrays.
Porque no existe el tipo Date.
> Otro ejemplo: hay funciones
> de PHP que devuelven diferentes
> tipos de datos.
Bien, el caso que expones es muy interesante, pero no sé si realmente nos estamos yendo de tema ;-)
> ¿Está mal? Si, es un jodido
> problema. Hay que tener siempre
> a mano la documentación para ver
> esos casos especiales.
Si, siempre es recomendable que "a la menor duda" consultar el manual, ya que siempre veremos la documentación de formas distintas según la óptica de nuestro problema de turno.
Todo está en el manual, no podemos subestimarlo.
Pero igual, creo que nos estamos yendo de tema, aunque gracias por el aporte, no nos confundamos.
Coincido totalmente con ácido...
Otro más?
Esta seccion deberia llamarse... "Tiremosle palos a Pablo Morales"
Si el autor fuera tan Senior y tan grande como dice que es... se limitaria a compartit sus conocimientos, no a menospreciara un supuesto colega
Estimado Francisco Rimoldi:
> Esta seccion deberia
> llamarse... "Tiremosle palos a
> Pablo Morales"
Qué le vamos a hacer... hay gente que tiene el arte de decir tonterías sin fundamento y otros el de criticar con fundamento.
> Si el autor fuera tan Senior
> y tan grande como dice que es...
> se limitaria a compartit sus
> conocimientos, no a
> menospreciara un supuesto colega
¿Colega? "¡Mi madre no cria chanchos!" (como dicen las viejas).
No confunda, tengo muy clara la calaña con que me enfrento... y lo peor de todo, nunca dejé de compartir mis conocimientos, es más, el "autor senior" de los disparates publicados tendrá más cuidado antes de escribirlos, así que no solo le hice bien a los lectores, también al autor.
La verdad que me sorprendo de la energía que emito a mi alrededor.
Enrique, te leo desde hace ya algun tiempo y la verdad es que nunca comento, pero me indigna la bajeza con la que has tratado este tema.
Creo que es cierto, esta lleno de charlatanes, pero tambien de prejuiciosos... hay que tener mucho cuidado al criticar con razon de no exceder la critica mas alla de donde corresponda.
Muchos profesionales autoproclamados seniors, y muchos otros con muchos años de experiencia y carrera tienen errores conceptuales muy graves que no por eso desmerecen el resto de los conocimientos que poseen.
Sin ir mas lejos hace algunos años me encontre con un ingeniero en software que no conocia la diferencia entre KB y kb y aportaba una explicacion completamente erronea sobre el concepto (segun él KB = 1024 bytes porque la "k" es mayuscula)
En fin, me fui un poco de tema, pero igualmente seria saludable que trates estos temas desde otro angulo mas que el de "desenmascarar charlatanes" no te olvides que sos un tipo muy respetado dentro del ambiente y tu critica puede dañar mucho la imagen comercial y profesional de cualquier colega tuyo.
Te mando un abrazo.
JAJAJAJAJAJAJA, flaco, ¿viste tu blog que te dedicas a sacarle el cuero a otros?
Otro dia, si queres, con mas tiempo, nos juntamos y te explico por que:
1) java no es 100% OO
2) el polimorfismo es un feature
3) patron estrategico es un "strategy pattern"
4) no podes hacer que 9 minas tengan un bebe en 1 mes
5) a que se referia gamma cuando decia basicamente que sobrediseñar esta mal
No tientes a la gente con otra inquisicion, no sea que termines en la hoguera =P
Estimado Santiago:
Te espero sentado.
Hola... Estoy desarrollando un sistema en Php, usando el framework SimpleMVC, una adaptación hecha de un framework existente.
Mi inquietud es la siguiente: He hecho un servicio que realiza inserciones en una tabla en postgre ssi se cumplen ciertas restricciones, si la inserción no se realiza, el servicio me devuelve un entero (por ejemplo 10: si no insertó porque el código proyecto está repetido, 20 si no insertó porque la asignación de obra está repetida), lo cual funciona perfectamente, pues he probado el modelo y me devuelve lo que debe devolver, el problema se presenta cuando en el controlador se recibe esta respuesta y se arma el mensaje de error, pues he tenido que recurrir a la función de php intval($respuesta) para que el mensaje que se muestra al usuario sea el correcto.
Alguien puede explicarme qué sucede en este marco de trabajo que hace necesario el "casteo" de la respuesta para que pueda mostrar el mensaje correcto???
De antemano muchas gracias a quien pueda ayudarme a encontrar una explicación lógica a lo que sucede con esto...
----------Virginia
Publicar un comentario