Buenos días lectores, quiero agradecer la entrada del día de hoy a Shout porque me dio la idea de que debería explicar por que hago ciertas cosas, que quizá a muchos les parezca hipócrita, o código basura.
En primer lugar voy a utilizar el comentario de ésta entrada para basarme en el mismo y realizar una entrada explicando cosas que quizá por falta de conocimientos, por no tomarse el trabajo de pensar las cosas o por lo que fuera, hay cosas que llaman la atención y parecen hacer al código basura.
Para empezar debo decir que ésta entrada no trata de criticar el comentario de shout que desde mi perspectiva es completa mente comprendible, por lo que le pido una disculpa pública por hacer una entrada basada en su comentario, pero fue gracias a él que se me ocurrió que muchos lectores quizá no comprendían por qué escribo lo que escribo.
Inicialmente aclararé por qué buscaba usar la función get_browser que propone la documentación de php y no usar la clásica super global de php _SERVER, en realidad los códigos que ustedes verán en mi blog suelen ser pruebas de cosas que me parecieron útiles y quería probarlas, por ejemplo la función get_browser, luego cambié de opinión porque me surgieron problemas dependiendo de la configuración del php.ini y me pareció totalmente fuera de lugar el hecho de obligar a quien lo usara a configurar su php.ini (Son formas distintas de obtener los valores que buscaba).
Dejando ese tipo de cosas de lado, voy a ir a lo que realmente importa, el código "inflado" o "basura" o como le quieran llamar responde a la implementación de ciertos criterios de calidad de software que expliqué a lo largo de mis publicaciones en el blog.
Se trata de hacer hasta el código más pequeño correctamente, las interfaces promueven la implementación de clases dejando de lado el conocimiento real del funcionamiento de la misma, tomando únicamente la cabecera de la función como referencia, ¿Por qué? si uno quiere hacer reusable un código lo primero que debe tener en cuenta es que es importante que el usuario de la clase o módulo (un programador que quiera implementarla por ejemplo) no debe tener como requisito para la implementación el conocimiento extendido de la clase. Las interfaces promueven este estilo de programación basado en calidad, y expresan un cambio de ideología en el código. No obstante no son obligatorias, pero usándolas adecuadamente son muy útiles en éste y otros aspectos. Debo admitir de todos modos que en la clase esa no estaban siendo implementadas las interfaces correctamente, las puse porque trato de hacerme con una "rutina" de crear interfaces para no olvidarlas, al no ser necesarias para la ejecución del código, hay que hacerse la "inercia" de crearlas.
Por otra parte, algo sumamente importante son los getters y setters que aunque parezcan innecesarios, son de mucha utilidad puesto que si seguimos con un modelo de calidad buscamos que el usuario no necesite conocer (en calidad de la reusabilidad) el origen de los valores que obtiene de la clase, pero no podemos romper el criterio de encapsulamiento, por lo que no podemos poner variables públicas, aunque por otra parte explicarle a un usuario de nuestro código que tiene que usar funciones para obtener valores dejando de lado la idea de atributos de los objetos, es un poco hipócrita, para evitar esto manteniendo el criterio de encapsulamiento diseñé el property para php, que en otros lenguajes existe y es automático prácticamente. De este modo mantenemos la ideología de los objetos (el paradigma en si) y además llevamos correctamente el criterio de encapsulamiento.
Ahora tengo que cerrar la publicación explicando que como menciona shout la clase en si es inútil e innecesaria por lo que las interfaces, las variables, y funciones realmente son innecesarias, por lo que hacen a todo el código lo que podríamos considerar una basura.
¿Entonces para qué hice la prueba usando una clase y no directamente la función que quería probar?
En realidad decir que la clase es totalmente inútil, es una verdad a medias, ya que como expresé en una entrada anterior, esto sería verdadero (totalmente inútil) si estuviéramos en un lenguaje de programación que no fuera php, pero como dije, php tiene la costumbre de a lo largo del tiempo ir cambiando cosas (véase la variable _SERVER) que fue incorporada hace un tiempo, pero originalmente era otra variable, el hecho es que en php las cosas tienen la tendencia a cambiar mucho, quitar funciones y agregar otras, y utilizar cosas que quedan obsoletas no es muy aceptable. Entonces desde mi punto de vista, algunas cosas son más factibles que cambien que otras, para evitarme modificar todo el código completo cuando a php se le ocurra cambiar una función, a algunas cosas les pongo alias, o si como la variable _SERVER tienen muchos factores que pueden cambiar las divido y creo un objeto en relación a los datos que aporta (por ejemplo agent), y junto cosas relacionadas al user agent. (aclaro que cuando digo que php cambia me refiero a que el equipo de php cambia el lenguaje a lo largo del tiempo, no por si solo)
Otra cosa que pueden ver inútil o basura es mi extraña costumbre de hacerle un alias a echo/printf cuando trabajo con PHPCli, la razón es que la salida en pantalla si es implementada directamente afecta el criterio de extensibilidad y robustez, ya que ancla el código a una sola salida que si no se modifica todo el código no puede ser modificado.
En fin, como verán no suelo escribir código porque esté aburrido, generalmente trato de escribir el menor código posible (salvo cuando hago pruebas claro está), a diario vendo códigos y generalmente cobro muchísimo más de lo que cuestan las cosas (aunque josé Orellana cobra mucho más) pero siempre trato de que mis códigos no tengan que ser reescritos, no den problemas y siempre estén preparados para cambios, esto lo logro siguiendo cierta teoría (que obviamente no es invento mío).
Si después de leer toda la entrada aún creen que el código de ese tipo es basura, les invito a leer teoría sobre programación, quizá eso les aclare un poco la mente y puedan comprender algunas cosas, se que aveces es dificil comprender todos los aspectos de la programación y sobre todo ideologías de distintos autores, salvo que se de el caso de que ocurra una situación en donde aparece la razón por la que algo fue hecho, pero con reflexionar un poco sobre lo que se programa no se muere nadie.
Mando saludos a todos mis amigos y sobre todo a mis lectores abituales (Eddy Wilson, que siempre deja un comentario por google plus), José Moruno de Sifer-L4bs, José Orellana (El segundo redactor del blog), 2Fac3r, Fermino, Xt3mp (hace rato no hablo con él y lo aprecio mucho espero verlo uno de estos días) a ~Yoya~ que siempre hace comentarios interesantes. y a la gente de Underc0de, Infiernohacker y elhackernet. Les mando mis saludos porque en estas comunidades tengo varios amigos y conocidos, y siempre se encuentra buena lectura, las recomiendo para pasar el rato :P
Saludos lectores!
En primer lugar voy a utilizar el comentario de ésta entrada para basarme en el mismo y realizar una entrada explicando cosas que quizá por falta de conocimientos, por no tomarse el trabajo de pensar las cosas o por lo que fuera, hay cosas que llaman la atención y parecen hacer al código basura.
Inicialmente quiero decir que ésta entrada tratará de explicar por qué implemento interfaces, por qué hago clases que para muchos no son necesarias, y por qué pongo tantos getters y setters.
Para empezar debo decir que ésta entrada no trata de criticar el comentario de shout que desde mi perspectiva es completa mente comprendible, por lo que le pido una disculpa pública por hacer una entrada basada en su comentario, pero fue gracias a él que se me ocurrió que muchos lectores quizá no comprendían por qué escribo lo que escribo.
Inicialmente aclararé por qué buscaba usar la función get_browser que propone la documentación de php y no usar la clásica super global de php _SERVER, en realidad los códigos que ustedes verán en mi blog suelen ser pruebas de cosas que me parecieron útiles y quería probarlas, por ejemplo la función get_browser, luego cambié de opinión porque me surgieron problemas dependiendo de la configuración del php.ini y me pareció totalmente fuera de lugar el hecho de obligar a quien lo usara a configurar su php.ini (Son formas distintas de obtener los valores que buscaba).
Dejando ese tipo de cosas de lado, voy a ir a lo que realmente importa, el código "inflado" o "basura" o como le quieran llamar responde a la implementación de ciertos criterios de calidad de software que expliqué a lo largo de mis publicaciones en el blog.
Se trata de hacer hasta el código más pequeño correctamente, las interfaces promueven la implementación de clases dejando de lado el conocimiento real del funcionamiento de la misma, tomando únicamente la cabecera de la función como referencia, ¿Por qué? si uno quiere hacer reusable un código lo primero que debe tener en cuenta es que es importante que el usuario de la clase o módulo (un programador que quiera implementarla por ejemplo) no debe tener como requisito para la implementación el conocimiento extendido de la clase. Las interfaces promueven este estilo de programación basado en calidad, y expresan un cambio de ideología en el código. No obstante no son obligatorias, pero usándolas adecuadamente son muy útiles en éste y otros aspectos. Debo admitir de todos modos que en la clase esa no estaban siendo implementadas las interfaces correctamente, las puse porque trato de hacerme con una "rutina" de crear interfaces para no olvidarlas, al no ser necesarias para la ejecución del código, hay que hacerse la "inercia" de crearlas.
Por otra parte, algo sumamente importante son los getters y setters que aunque parezcan innecesarios, son de mucha utilidad puesto que si seguimos con un modelo de calidad buscamos que el usuario no necesite conocer (en calidad de la reusabilidad) el origen de los valores que obtiene de la clase, pero no podemos romper el criterio de encapsulamiento, por lo que no podemos poner variables públicas, aunque por otra parte explicarle a un usuario de nuestro código que tiene que usar funciones para obtener valores dejando de lado la idea de atributos de los objetos, es un poco hipócrita, para evitar esto manteniendo el criterio de encapsulamiento diseñé el property para php, que en otros lenguajes existe y es automático prácticamente. De este modo mantenemos la ideología de los objetos (el paradigma en si) y además llevamos correctamente el criterio de encapsulamiento.
Ahora tengo que cerrar la publicación explicando que como menciona shout la clase en si es inútil e innecesaria por lo que las interfaces, las variables, y funciones realmente son innecesarias, por lo que hacen a todo el código lo que podríamos considerar una basura.
¿Entonces para qué hice la prueba usando una clase y no directamente la función que quería probar?
En realidad decir que la clase es totalmente inútil, es una verdad a medias, ya que como expresé en una entrada anterior, esto sería verdadero (totalmente inútil) si estuviéramos en un lenguaje de programación que no fuera php, pero como dije, php tiene la costumbre de a lo largo del tiempo ir cambiando cosas (véase la variable _SERVER) que fue incorporada hace un tiempo, pero originalmente era otra variable, el hecho es que en php las cosas tienen la tendencia a cambiar mucho, quitar funciones y agregar otras, y utilizar cosas que quedan obsoletas no es muy aceptable. Entonces desde mi punto de vista, algunas cosas son más factibles que cambien que otras, para evitarme modificar todo el código completo cuando a php se le ocurra cambiar una función, a algunas cosas les pongo alias, o si como la variable _SERVER tienen muchos factores que pueden cambiar las divido y creo un objeto en relación a los datos que aporta (por ejemplo agent), y junto cosas relacionadas al user agent. (aclaro que cuando digo que php cambia me refiero a que el equipo de php cambia el lenguaje a lo largo del tiempo, no por si solo)
Otra cosa que pueden ver inútil o basura es mi extraña costumbre de hacerle un alias a echo/printf cuando trabajo con PHPCli, la razón es que la salida en pantalla si es implementada directamente afecta el criterio de extensibilidad y robustez, ya que ancla el código a una sola salida que si no se modifica todo el código no puede ser modificado.
En fin, como verán no suelo escribir código porque esté aburrido, generalmente trato de escribir el menor código posible (salvo cuando hago pruebas claro está), a diario vendo códigos y generalmente cobro muchísimo más de lo que cuestan las cosas (aunque josé Orellana cobra mucho más) pero siempre trato de que mis códigos no tengan que ser reescritos, no den problemas y siempre estén preparados para cambios, esto lo logro siguiendo cierta teoría (que obviamente no es invento mío).
Si después de leer toda la entrada aún creen que el código de ese tipo es basura, les invito a leer teoría sobre programación, quizá eso les aclare un poco la mente y puedan comprender algunas cosas, se que aveces es dificil comprender todos los aspectos de la programación y sobre todo ideologías de distintos autores, salvo que se de el caso de que ocurra una situación en donde aparece la razón por la que algo fue hecho, pero con reflexionar un poco sobre lo que se programa no se muere nadie.
Mando saludos a todos mis amigos y sobre todo a mis lectores abituales (Eddy Wilson, que siempre deja un comentario por google plus), José Moruno de Sifer-L4bs, José Orellana (El segundo redactor del blog), 2Fac3r, Fermino, Xt3mp (hace rato no hablo con él y lo aprecio mucho espero verlo uno de estos días) a ~Yoya~ que siempre hace comentarios interesantes. y a la gente de Underc0de, Infiernohacker y elhackernet. Les mando mis saludos porque en estas comunidades tengo varios amigos y conocidos, y siempre se encuentra buena lectura, las recomiendo para pasar el rato :P
Saludos lectores!
0 comentarios:
Publicar un comentario