Se acaba de anunciar la publicación de la versión 1.0 de dojo Toolkit. Esta librería, aunque pueda despistar el número de versión, es de la más veteranas en cuanto a desarrollo AJAX se refiere, en esta versión se ha reescrito gran parte de la librería, sobre todo por motivos de rendimiento y se han incluido un buen número de características como:
Se trata sin duda de una librería más que completa y muy a tener en cuenta si nos embarcamos en algún desarrollo RIA con AJAX. Claro que se trata de una librería pura JavaScript, en el caso de un desarrollo RIA esto implica que gran parte del código de nuestra aplicación estará escrito en este lenguaje, la pregunta con este tipo de frameworks puede ser ¿es posible hacer un desarrollo mantenible en JavaScript?.
Hacer un desarrollo mantenible en Javascript es tan posible como hacer una desarrollo simple con J2EE.
La pregunta ya encierra en sí misma una cierto enjuiciamiento no crees?
Estos marcos ya sea Dojo, mootools, Prototype, jQuery, YUI o cualquiera de las otras están orientadas a generar una vista muy consistente, independientemente de cuál sea la tecnología que utilices en el servidor, por tanto la idea de estos marcos no es tener "desarrollos" completos, sino ayudarte en el navegador.
La pregunta va sin juicio previo que conste, por eso es una pregunta sino seria una afirmación. Que se pueden hacer desarrollos mantenibles en JavaScript lo demuestra la misma librería dojo, quizas debería haberlo expresado mejor "¿estamos preparados para hacer desarrollos mantenibles en JavaScipt?".
No es sencillo utilizar un lenguaje que hasta ahora en la mayoría de desarrollos sólo se emplea para pequeñas validaciones o efectillos, con los que basta una función aqui y alla, que desarrollar UI's completos en AJAX y llevarse parte de la logica de la aplicación a la parte cliente. AJAX llevado al extremo supone convertir al browser en no sólo "el contenedor de la vista" sino en convertirlo en una parte más de la arquitectura de mi aplicación con perfecto derecho por tanto a contener parte de la logica de la misma. (no confundir esto con mezclar logica y presentación, esta separación se puede hacer en JavaScript también).
Dicho esto, para llevar a cabo aplicaciones de este estilo necesitamos manejar conceptos como reutilización de código, manteniblidad y legibilidad del código, profiling, pruebas... es decir hay que tratar al código JavaScript con la misma "seriedad" que se trata al código java (o lo que sea) que tenemos en el lado servidor. Y ahora viene la pregunta, ¿estamos preparados para hacer esto?, reutilizar código javascript, probarlo convenimente, hacer profiling del mismo etc,etc.
remoh, por conceptos como que "...el browser es sólo el contenedor de la vista...", o "...para pequeñas validaciones o efectillos, con los que basta una función aqui y alla..." es que a veces puede basarse el éxito o el fracaso de una aplicación. Parece ser que aparentemente para la mayoría de los desarrolladores este código javascript no es de "vital" importancia, pensando que sólo el código del lado del servidor es "realmente" código de la aplicación, cuando la realidad demuestra que sin un correcto comportamiento y agradable aspecto de la interfaz, los usuarios pueden hacer caer tu aplicación sin importar el excelente código que posea en el servidor. Lamentablemente, como dijo una vez un compañero de trabajo "javascript debe ser uno de los lenguajes mas utilizados, pero del que menos desarrolladores saben manejarlo correctamente". Saludos.
javascript debe ser uno de los lenguajes mas utilizados, pero del que menos desarrolladores saben manejarlo correctamente
Coincido totalmente con esa afirmación, he dado varios cursos presenciales de ajax y practicamente todos los alumnos ya habían usado javascript con aterioridad al curso. Sin embargo cuando explico cosas como funciones constructoras, contextos de ejecución de las funciones o el uso de prototipos, casi nadie (salvo rara excepción) conoce estos conceptos, la gente mayoritariamente ha usado JS para escribir validaciones de formularios y como mucho algún efecto en el interfaz (menús y cosas de estas). Pero por lo general este código se trata con "poco respeto", lo habitual es ir copypasteando el código JS de un proyecto a otro y santas pascuas,es raro econtrar gente que tenga su propia librería en JS y se preocupe de reutilizar este código y crear jerarquias de clases (como si se hace mucho más en lado servidor).
Dojo, Ext o prototype hacen uso extensivo de conceptos como herencia, incluso simulan la definición de métodos public, protected, private. Es decir, todos estos grandes frameworks usan intesivamente conceptos de OO que en mi experiencia poquita gente sabe aplicar con JS (que se puede, aunque no es facil). Por eso tengo la duda de si si estamos preparados para elevar JS a lenguaje de primera categoria en nuestros desarrollos, o si es recomendable hacerlo.
Totalmente de acuerdo contigo Remoh. Llevamos 7 meses usando Dojo en nuestro proyecto (Dojo 0.42, todavía no hemos actualizado a 0.9, o ahora sería a la 1.0) y todos los problemas que encontramos en el framework son heredados de javascript además de un serio problema de rendimiento que hace que tengamos que tener mucho cuidado cuando programamos, quizá el rendimiento haya mejorado radicalmente con la reescritura en la versión 0.9 pero en cuanto a las 0.4x el navegador se nos muere cuando tenemos una ventana muy "sobrecargada". La aplicación necesita mostrar muchas "ventanitas" y el cliente no quiere más que una ventana del browser así que usamos las floatingpane de Dojo. Esto hace que en IExplorer el movimiento de las ventanas sea brusco y no muy agradable, en Firefox funciona muchisimo mejor. En cuanto a los widget que trae por defecto, hemos tenido que modificar casi todos los que usamos, o crearlos nuevos, porque los por defecto no se adaptan al 100% a nuestras necesidades.
Sobre javascript, creo que es un serio problema del AJAX. Es un lenguaje propenso a programar mal, todo lo contrario que java. Un lenguaje del que estamos acostumbrados a meter 4 lineas para hacer una validación y que pasa a convertirse en el lenguaje en el que más lineas escribes en un proyecto con AJAX (en mi proyecto no se que porcentaje tenemos de javascript y cual de java pero estoy seguro que es muchísimo mayor el de javascript).
Aquí un compañero mío añade que quizá parte de nuestros problemas vengan de no saber usar Dojo a la perfección por la falta de documentación o la mala calidad de ésta.
Quizá en un futuro proyecto valoremos la utilización de otros frameworks como GWT o DWR que no son sólo un conjunto de librerías javascript (aunque claro, entonces te "casas" con java).
Un Saludo. Abel.
En realidad el único problema de Javascript es el de la gente que se empeña en usar OO basada en clases en lugar de adoptar el sistema de OO basado en prototipos propio del lenguaje. (Sólo es mi humilde y seguramente errónea opinión, claro)
Yo en esto estoy con venkman, no se trata de hacer clases como si fuese JAVA, se trata de aprovechar el estilo de orientacion a objetos que proporciona Javascript.
Se pueden crear objetos? Si, rotundamente.
Se pueden crear instancias de objetos? Si, tantas como queramos.
Se puede crear codigo HTML e interactual con el existente? Si, desde luego, esta DOM.
Se puede conectar con servidores e intercambiar informacion? Si, mediante AJAX.
Y entonces donde esta el problema? Pues que estamos acostumbrados a tratarlo como un lenguaje menor y la mayoria ni siquiera sabe (lo digo por propia experiencia) lo que se puede hacer con Javascript.
Una pena.
Pues yo creo que uno de los problemas básicos de JavaScript es que no tiene ni a un "esponsor" detrás, estilo Sun, ni un JCP... por muchos problemas que a veces eso acarrera. Me explico, no hay una directriz única de hacia donde van las cosas, ni coherencia entre las diferentes formas de hacerlas, ni homogeneidad. Cada libreria hace unas cosas, pero no hace otras, y las hace de una forma especial, y normalmente mal documentada y luego otra libreria igual pero distinto, con solapamientos pero sin cubrirlo todo...
Decir que usas AJAX y/o DHTML hoy en dia es como decir que usas "un framework web" en Java, o sea, que no dice mucho por que hay multitud de formas de hacerlo.
Y aparte de eso o como consecuencia, el soporte en los navegadores sigue siendo fuente de problemas, depurar las aplicaciones en el cliente es casi peor que en el servidor, no hay un conjunto de "widgets" estandar...
Y si, ademas la gente no tiene experiencia y como no hay formas "estandar" de hacer las cosas, pues cada uno lo hace a su bola y salen las cosas como salen.
Así que si, la gente tiene culpa, como en cualquier actividad, pero de ahi a decir que es el unico problema... yo personalmente no lo creo.
Yo creo que en este momento, quienes podrían obrar de sponsors de JavaScript (como dice greeneyed), son Google y Yahoo. Lamentablemente, por más de que mañana todos los navegadores lleguen a un acuerdo y respeten un estandar único, la gente siempre utilizará navegadores más viejos, y habrá que contemplar esos casos. Personalmente, prefiero sacrificar la expresividad de JavaScript, a cambio de la seguridad de que mi código será realmente cross-browser. Por eso es que prefiero la opción de GWT, por más antinatural que parezca. Un caso de estudio muy interesante es el de Lombardi Blueprint, un sistema de diagramado de workflows online, que fue prototipado con DOJO y con GWT. Los desarrolladores notaron una performance muy superior de GWT respecto de DOJO, y por lo tanto se decantaron por el primero. El código JavaScript generado por GWT fue un 50% menor que el código necesario para hacer funcionar el prototipo DOJO.
No sé por qué no iba a funcionar en todos/muchos navegadores Dojo. O jQuery, o Prototype, o... De hecho es una de las primeras cosas que hacen, limar las diferencias entre navegadores para que tú no te preocupes por ellas.
Otro tema es el rendimiento, pero eso creo que es más problema de que Dojo es (era?) muy pesado, más que nada.
Bueno, en realidad creo que el código que genera GWT tiene ventajas de rendimiento por sobre el resto (sea DOJO, jQuery o Prototype), debido a que aprovecha el tipado estático de Java para hacer eliminación de código muerto e inlining. Con eliminación de código muerto, me refiero a que si en ningún lugar de tu código invocas al método holaMundo(), el código de ese método no será agregado en el JavaScript resultante. Con inlining me refiero a que si tienes un método getNombre(){ return this.nombre; }, GWT se encarga de reemplazar la invocacion de persona.getNombre() por persona.nombre. GWT también aprovecha el paso de compilación para ofuscar y comprimir el código resultante. Si bien existen compresores para JavaScript, ninguno es de uso 100% seguro (ni siquiera el de YUI), ya que siempre peligra el código contenido en expresiones eval. Con GWT, en cambio, la compresión es 100% segura, ya que todo el tipado es estático.
A mi personalmente el soporte OO que ofrece JS usando prototipos me parece muy limitado. En realidad lo único que hace es "atachar" funciones/propiedades a un objeto contexto de una función constructora (una función llamada con new). Con esto se simula en parte la definición de clases, pero sólo a nivel muy basico, sin herencia, sin clases abstractas, sin interfaces, sin public/private/protected para los metodos... no se vosotros, pero yo como diseñador sin estos conceptos me siento atado de pies y manos, quiza sea demasiado dependiente de la OO, pero es donde mejor me muevo, y creo que a muchos les pasa lo mismo.
Sobre los organismos detras de JavaScript, pues se supone que para eso esta el estándar EcmaScript en el que entre otras muchas participan microsoft y mozilla fundation, otra cosa es que luego implementen las cosas como les brote. De hecho se ha publicado hace poquito el draft final de EcmaScript 4, y en este se incluyen conceptos OO más "avanzados", acercando EcmaScript mucho a lenguajes como ruby, python o incluso java o C#. Aunque claro, para ver esto en los navegadores hay que esperar más o menos o mismo que para ver las olimpiadas en madrid.
Lo que si es cierto es que esta limitación se ha intentado resolver de maneras distintas, por ejemplo una de las librerías JS más usadas, prototype, tiene su propio mecanismo para definición e clases y herencia y luego dojo tiene otro distinto
Si cosas tan basica como "como defino una clase" o "como hago herencia" dependen del framework que uses pues al final pasa lo que dice greeneyed, que no hay homogeneidad ni para las cosas más basicas.
Disiento de que ese tipo de OO sea "más avanzado". Sólo es distinto.
Y desde luego Javascript no "simula" la definición de clases. No tiene clases, tiene objetos. Esa es la diferencia. Y sí que soporta la herencia, pero es una herencia basada en la clonación, no en la instanciación.
Sí, ya, Dojo, Prototype, etc, se empeñan en añadir un modelo de clases, pero visto de otro modo... ¿qué es más avanzado, sólo poder trabajar con un modelo de OO con clases o poder montar tu propio modelo si es que lo quieres o no hacerlo si no lo quieres?
En fin, de cualquier modo no quiero montar aquí una discusión sobre tipos estáticos vs. tipos dinámicos, o prototipos vs. clases o nada similar. No llevan a ningún lado. Ya se sabe que las opiniones son como los culos.
Por cierto, ha sido una absoluta casualidad, pero justo acabo de encontrarme que alguien ha enlazado en reddit esto.
Bueno, otro clásico es Crockford's JavaScript
Vale que con javascript no "simulas" nada, tienes un planteamiento diferente, digo "simula" porque hablo desde la perspectiva de un programador java/c++.
Personalmente que tengas que montarte tu propio modelo en base a objetos me parece más un problema que un beneficio, prefiero que el lenguaje te aporte un modelo OO predefinido y te ayude a construir programas en base a ese modelo, claro que puedes tener limitaciones en ese modelo pero la contrapartida es que consigues homogeneizar la forma de utilizar el lenguaje y presentar de una forma más explicita los conceptos de la OO (extends frente a "me copio un objeto lo modifico").
Pero como tu dices son opiniones, tampoco me gusta nada el tipado dinamico :P
Sólo un último apunte...
No es que Javascript no te "aporte un modelo OO predefinido". Te lo aporta, pero no está basado en clases. Lo que decía que puedes montar o no es uno basado en clases. Pero siempre tienes el modelo de orientación a objetos basado en prototipos.
Tal y como ha dicho remoh,
para mi ha llegado el momento que pensemos en el navegador como un nivel (tier) más proyecto en el que debemos aplicar las mismos prácticas que en el lado del servidor.
Todo el código JavaScript lo tenemos que organizar en capas (layers).
Otras cosa importante es tener estructuras de datos adecuadas en JavaScript, yo personalmente tengo hecho en JavaScript las clases ArrayList y HashMap con los mismos métodos que en Java así me siento más cómodo y no tengo que aprender nuevas APIs.
Respecto al tema de OO, en JavaScript es todo un poco más duro pero con un poco de trabajo se puede hacer casi lo mismo que en Java, yo tengo enumerados, métodos estáticos, singletons, etc.
Por último está el tema de generar documentación JavaDoc del JavaScript, para ello existe una herramienta en Perl que la genera. http://jsdoc.sourceforge.net/. ¿Vamos a volver a la época en la que no generabamos automáticamente la documentación?
Saludos.
Se me olvidaba,
Una discusión en The Server Side sobre esto la teneis en:
http://www.theserverside.com/news/thread.tss?thread_id=37106
Que trata entre otros del tema:
"Application-specific JavaScript that play a role of presentation controller on the client-side"
logongas... Cuéntame un poco más de los Singletons en Javascript.
Este es el código de la clase:
/**
* Clase Singleton, no se debe nunca llamar a este constructor directamente.
*/
function Singleton() {
this.value=3;
}
/**
* @private
*/
Singleton.singletonInstance=null;
/**
* Obtiene la misma instancia del objeto.
* Este es un método estático.
* @return Instancia del objeto
*/
Singleton.getInstance=function() {
if (Singleton.singletonInstance==null) {
Singleton.singletonInstance=new Singleton();
alert("Creando instancia");
}
return Singleton.singletonInstance;
}
El código para probarla es el siguiente:
var singleton1=Singleton.getInstance();
alert("Debe ser 3:" + singleton1.value);
singleton1.value=4;
alert("Debe ser 4:" + singleton1.value);
var singleton2=Singleton.getInstance();
alert("Al ser la misma instancia debe ser 4:" + singleton2.value);
Saludos
Aham... ¿Y has pensado alguna vez en algo como esto?
Singleton = { value: 3 };var single1 = Singleton;
alert(single1.value + " es igual que 3");
single1.value = 4;
alert(single1.value + " es igual que 4");
var single2 = Singleton;
alert(single1.value + " es igual que " + single2.value);
single2.value = 5;
alert(single1.value + " es igual que " + single2.value);
logongas, la malo de ese singletton, que se parece a como lo hariamos en java, es que en realidad no es un singletton. Un singletton basicamente sirve para cerciorarse en tiempo de compilación (esto es importante) de que solo puede existir una instancia de un objeto (por eso el contructor private) y por tanto se habilita un método estatico que crea la instancia única y la devuelve.
En JavaScript la cosa cambia mucho, no hay clases, no hay tiempo de compilación, así que si quieres tener una única instancia de un objeto creala y usala (lo que hace venkman en su ejemplo). Esto resulta chocante de inicio para programadores con un enfoque como el de java, pero en realidad en este caso resulta muy natural si se piensa intentando dejar a un lado "prejuicios" que tenemos por nuestra experiencia en lenguajes como java o c++.
Por poner un ejemplo, imagina que tienes un sistema de log en JS, y como sólo existe un log para toda la aplicación no necesitas más que una instancia del objeto log, te puedes crear un fichero log.js con este código:
var Log = {
error : function (mensaje){
alert(mensaje);
},
debug : function(mensaje){
alert(mensaje);
}
}
Luego desde cualquier otra parte de tu aplicación JS sólo tienes que hacer:
Log.debug('mensaje');
Log.error('mensaje');
Con esto consigues el mismo efecto que se persigue con un singletton en java, que al fin y al cabo es que sólo haya un objeto de tal tipo en memoria, pues en js como todos son objetos, creas ese objeto una vez y ya esta. Espero que se entienda.
Hola remoh,
la forma del Singleton la he puesto aqui así para que sea más parecido a como lo pone en GoF.
Pero cuando yo escribo código sigo más tu estilo en el que creo una clase en la que llamo a métodos estático y un contructor privado.
Log.debug();
Log.error();
Sin embargo las opciones que habeis propuesto tienen una desventaja: Se documentan peor. Ya hos he comentado que uso la herramienta http://jsdoc.sourceforge.net/ y cuando usaba una variable para simular un Singleton la documentación quedaba mucho menos clara que usando una clase con métodos estáticos. Aunque en este último caso me arriesgo a que alguien cree una instancia de la clase.
Saludos
logongas, a lo que quería llegar es a que Singleton es un patrón que tiene sentido cuando trabajas con un sistema de orientación a objetos basado en clases e instanciación. Si tu sistema de objetos está basado en prototipos y clonación, el patrón pierde completamente el sentido. No instancias objetos a partir de una clase. Y la excusa de "se documenta mejor" no me convence lo más mínimo. Es una limitación de tu herramienta de documentación; no tengo por qué solucionarla cambiando mi código.
Por otro lado, si tratamos tu ejemplo concreto, me parece francamente frágil basarte en "no se debe llamar al constructor". ¿Eh? Eso no soluciona nada. No impide que alguien obtenga otra "instancia". Si realmente necesitas tener un generador/función, usa un constructor anónimo:
var Singleton = new function() { this.value = 3; };
Hola Venkman,
está claro que la forma más correcta en JavaScript es tal y como tu dices, de hecho yo empece haciendo así. Pero la pregunta correcta que deberíamos hacernos es:
¿Que va a generar menos problemas en le proyecto?¿Que el código esté bien documentado con el JavaStringDoc o que no se pueda crear una instancia?
En el framework que estoy haciendo tengo unas 4000 lineas de código y para mi era fundamental que hubiera un JavaScriptDoc perfectamente documentado.
En la programación hay que tener muy en cuenta a las personas y pensar que les va a ayudar más y ciertas veces les ayuda mas el no ser tan estricto con el lenguaje.
Y lo que dices que eso es problema de la herramienta es verdad , pero no hay otra donde elegir.
De todas formas todo estoy hay que decidirlo según el proyecto en el que estes trabajando, no es lo mismo un proyecto de 3 personas en el que todos trabajan en las 3 capas
que un proyecto de 50 personas en las que 10 hace código JavaScript y otras 40 lo usan y trabajan a 200 KM de distancia.
Saludos.
logongas, vaya por delante que comprendo perfectamente que en cada proyecto se toman decisiones que se ven influidas por muchos factores.
Sin embargo, igual que tú te planteas si es mejor que esté bien documentado o que realmente no se pueda hacer, yo me planteo otra serie de cosas:
1. Si realmente impides que se haga, ¿acaso no es una imposición mucho más clara y consistente que el hecho de que en una documentación por ahí haya un indicador que dice que tal propiedad es privada y que por favor no llamen directamente al constructor? ¿Qué pasa si luego llega uno y dice "bueno, pero realmente se puede, así que..." y va y lo llama? "Pero si la documentación dice que no se haga..." no es una buena respuesta. Si quieres realmente tener en cuenta a las personas, ten en cuenta que harán todo lo que puedan hacer.
2. ¿No es también mucho mejor que dar 3 vueltas para llegar a un sitio, darte cuenta de que ya estabas allí? Dando 3 vueltas, las probabilidades de perderte por el camino aumentan enormemente. O dicho de otra forma, ¿no es más lógico aprovechar los mecanismos del propio lenguaje, que tener que simular otro comportamiento distinto y luego imponer restricciones sobre tu simulación? Las probabilidades de introducir un error son mucho mayores.
3. ¿Realmente es lógico que la capacidad de una herramienta determinada marque de forma tan fundamental la forma de desarrollar? Más aún cuando se trata de una herramienta que, aunque importante, sí, en cierto modo es auxiliar al propio código y no parte de él. Ojo, que aprecio enormemente la necesidad de tener buena documentación, pero la documentación nunca me puede obligar a tener peor código para que esa sea mejor.
4. No hay otra, dices. ¿Pero acaso no es jsdoc libre? O incluso, ¿acaso la documentación generada es intocable? En el primer caso, si realmente lo necesitas, podrías tratar de a. modificar o añadir a jsdoc, b. pedir una mejora a los autores, c. pagar por el desarrollo de esa mejora a los autores o a otros. En el segundo caso, podrías post-procesar la documentación generada por jsdoc añadiendo o modificando lo que no te gusta.
remoh: ¿es posible hacer un desarrollo mantenible en JavaScript?
Muy muy difícil, el lenguaje y el entorno ayuda muy muy poco, hay que tener mucha disciplina y ser muy ordenadito, lo digo por experiencia (ya lejana).Admiro a la gente de Dojo de Ext-JS etc porque lo que hacen es parecido a la torre Eiffel con palillos y con la misma altura. El no tener un simple compilador que te resuelva inconsistencias, una orientación a objetos decente, un sistema de paquetes namespace lo que sea, herramientas que te permitan inspeccionar los lugares donde se declaran y se llaman a tus métodos, por no hablar de un mínima herramienta de refactorización (cambiar nombre de un método) y debuggers que consigas comprender, hace que el programar en JavaScript sea la leche salvo cosas sencillas. Por no hablar del tema de las incompatibilidades a nivel web y lo horrorosamente lento que es JavaScript.
Por eso la gente de Google que de tontos no tienen nada inventaron el compilador Java-JavaScript.
Respecto a la orientacióna objetos todo depende de como se definan las cosas, y no de acuerdo a la definición clásica (herencia, polimorfismo y encapsulación), JavaScript NO tiene POO, tiene otra cosa (prototipos), aunque se puede simular la POO clásica más o menos como bien dice remoh.
Yo uso algo parecido a la POO de Dojo, la técnica la copie de una vieja librería llamada X-Objects de un tal yasd hace unos buenos años que ya ni siquiera está online.
Es tan simple como:
function ClaseBase(dato)
{ this.getDato = getDato;
this.dato = dato;
function getDato()
{return this.dato;
}
}
function ClaseDerivada(dato)
{this.ClaseBase = ClaseBase; // preparar herencia
this.ClaseBase(dato); // Heredar - Llamar al constructor
this.super_getDato = this.getDato; // polimorfismo
this.getDato = getDato;
function getDato()
{return this.super_getDato() * 1.20; // + 20%
}
}
var obj = new ClaseDerivada(3);
alert(obj.getDato()); // Mostrará 3.6
Se puede simplificar y compactar algo más (perdiendo claridad), se pueden simular packages/namespaces también etc. Se puede minimizar via delegación a "singletons" el exceso de tiempo de proceso de construir cada objeto (porque es POO creada en tiempo de construcción).
El ejemplo de singleton de lolongas sí es un singleton remoh sólo que con la limitación obvia de que no podemos hacer constructores privados.
En definitiva con paciencia y disciplina se puede conseguir hacer arquitecturas con JavaScript pero insisto es construir con palillos.
jmarranz, creo que usas mal algunas expresiones.
"Javascript no tiene POO". Sí tiene. Dudo que puedas decir que Smalltalk o Squeak no son orientados a objetos. Incluso diría más. ¿Tiene encapsulación? Claro. ¿Polimorfismo? Más o menos. ¿Herencia? Claro.
"definición clásica". ¿Por qué "clásica"?
"sí es un singleton". No, no lo es.
Lo que sigue no usa ningún tipo de construcción especial, sino que aprovecha el funcionamiento de la POO en Javascript.
//Herencia con prototipos:
function Pieza(nombre, peso) {
this.nombre = nombre;
this.peso = peso;
};
// un par de funciones auxiliares para luego:
Pieza.Pesar = function(a,b) {
return (a.peso - b.peso);
};
Pieza.prototype.toString = function() {
return (this.nombre + " (" + this.peso + ")");
}
// PiezaMaterial hereda de Pieza.
function PiezaMaterial(nombre, peso, material) {
Pieza.apply(this, [nombre, peso]);
this.material = material;
};
PiezaMaterial.prototype = new Pieza();
PiezaMaterial.prototype.constructor = PiezaMaterial;
var miPieza = new Pieza("tabla",2);
var miPiezaDePiedra = new PiezaMaterial("soporte",4,"granito");
alert("La pieza de piedra es:\nNombre: " + miPiezaDePiedra.nombre+ "\nEs una PiezaMaterial: " + (miPiezaDePiedra instanceof PiezaMaterial)
+ "\nY además es una Pieza: " + (miPiezaDePiedra instanceof Pieza));
//Polimorfismo (más o menos) con prototipos:Por cierto, qué pequeño se ve el código, ¿no?
var misPiezas = [miPiezaDePiedra, miPieza, new Pieza("tornillo",1)];
alert(misPiezas.sort(Pieza.Pesar).join());
Ohm... perdón, me voy a flagelar un poquito a mi mismo por poner Smalltalk, que es basado en clases. Quería decir Self.
De verdad, sin entrar en peleas semánticas inútiles, un lenguaje es POO si tiene las capacidades de encapsulación, herencia y polimorfismo, es lo que he entendido siempre de toda la vida, podemos añadirle los matices propios de cómo cada lenguaje lo expresa, pero tener objetos no es suficiente. Visual Basic hasta la reconversión en .Net nunca fue POO completo aunque tuviera objetos. Si no pasa nada, si VB no ha sido POO es sencillamente porque Microsoft no tuvo ningún interés en ello, para eso tenía su C++ para las arquitecturas más complejas. Idem JavaScript los diseñadores no pensaban en que se llegaría a hacer las virguerías actuales y no les dio la gana, seguramente para que el intérprete fuera más rápido y sencillo yo que se, si herencia, encapsulación y polimorfismo y lenguajes de script no son conceptos incompatibles sino mira Groovy.
Pero no, si JavaScript no tiene funciones virtuales no es POO completo nativamente, tener objetos y herencia no es suficiente, y el polimorfismo es uno de los tres pilares y es extremadamente útil. O bien podemos distinguir POO basado en clases o POO basado en prototipos si a mi me da igual.
Si lo genial de JavaScript es que puede emular POO, incluso la encapsulación se puede emular también con variables dentro de la "función-clase" JavaScript usando var y sin asociar con this. Y por otra parte también tiene el sistema de prototipos que es una alternativa.
Hola venkman,
Un Singleton es simplemente un patronde diseño, es decir, una idea, que luego hay que implementar. En este caso la implementación no es muy buena pero eso no quita que sea un Singleton. Si yo creo un framework y digo que de una clase normal y corriente solo se puede crear una instancia, esa clase seguira el patron del Singleton aunque físicamente se puedan crear más instancias.
Por otro lado, del resto de tur argumentos ya te digo que depende del proyecto. En mi caso todo esto es para un framework Open Source que he creado para que mis alumnos vean que es el desarrollo por capas y que en las empresas todo en mas complejo que lo que suele darse en clase. Así que ni tengo dinero ni tiempo para cambiar la herramienta de jsdoc y si que es importante que todo esté bien documentado.
Saludos
Francamente, mi intención no es montar una "pelea semántica inútil" así que lo dejo, pero la verdad es que no sé demasiado bien qué esperaba...
Pa ti la perra chica, jmarranz.
logongas. Un patrón de diseño no es "una idea".
Un patrón de diseño es = un problema conocido en unas circunstancias determinadas + una solución aceptada como buena. Si tu problema no se da en esas circunstancias, probablemente ya no sea el mismo. Si además implementas tú solución ("le digo a la gente que no instancie mi clase") en lugar de la solución aceptada como buena, no estás aplicando correctamente el patrón de diseño.
Hola Venkman,
como le has dicho a jmarranz estamos acabando en una "pelea" semántica, aunque yo no pienso que sean inútiles. Siempre se aprende algo.
Del libro de Martin Fowler "Patterns of Enterprise Application Architecture" he extraido el siguiente parrafo:
"Once you need the pattern, you have to figure out how to apply it to your circumstances. A key thing about patterns is that you can never just apply the solution blindly, which is why pattern tools have been such miserable failures. I like to say that patterns are "half baked," meaning that you always have to finish them off in the oven of your own project. Every time I use a pattern I tweak it a little here and a little there. You see the same solution many times over, but it's never exactly the same."
Como dice, el patron hay que aplicarlo a tu entorno y no puedes cojerlo tal cual viene en un libro. El código que se pone en los libros suele ser para poder explicarlo mejor y si a alguien le vale directamente mejor que mejor pero no suele ser el caso.
Saludos.
logongas. No sé qué me quieres decir con eso y cómo eso contesta a algo de lo que yo haya dicho.
Te lo explico de nuevo por si acaso es que no me he explicado bien.
Patrón Singleton (malamente explicado):
- Problema: Necesito utilizar un determinado recurso en varios sitios pero no puedo dar diferentes copias de ese recurso porque debe ser único (la razón es más amplia, puede ser caro, peligroso que varios accedan a la vez, u otra razón).
- Solución: Impide que se puedan crear varias instancias de ese recurso, controlando su creación de modo que sólo se cree una vez y todos los demás obtengan referencias a la misma copia.
El patrón no es sólo el problema. Es el problema + la solución. Lo que es cierto que no abarca es la implementación de la solución.
Si tú, ante ese mismo problema, decides adoptar esta solución:
- Solución de logongas: Pon una nota en la documentación diciendo que no se llame al constructor. Cruza los dedos y confía en que nadie lo haga.
Independientemente de que la implementación (a la que aún no hemos llegado siquiera) sea mejor o peor o dependa de tu entorno, tu aplicación del patrón no es correcta. No lo es porque realmente no estás controlando ni limitando la instanciación de nada.
Yo puedo decir:
- Solución mía: Llamo a la variable objetoUnico y ya con eso confío en que la gente entenderá que no debe instanciar más copias.
¿Estoy aplicando bien el patrón? ¿Es objetoUnico un singleton?
Pero es que además, el problema real que plantea Singleton ni siquiera es ese exactamente. El problema que plantea es:
- Problema: Necesito restringir la instanciación de una clase de modo que sólo exista un objeto de dicha clase.
¿Y esto en qué situaciones ocurre? Ocurre en lenguajes con orientación a objetos basada en clases e instanciación. Si tu lenguaje se basa en prototipos... el problema no ocurre así, con lo que tratar de aplicar el patrón es un error en sí mismo.
Mira el comentario que hay en Wikipedia, donde habla de "Prototype-based singleton"
"En un lenguaje basado en prototipos, donde no se usan clases sino objetos, un singleton simplemente se refiere a un objeto del que no existen copias o que no se usa como prototipo de ningún otro objeto."
No puedes "restringir la instanciación de una clase" porque no hay clases.
Yo en este caso y sin que sirva de precedente :P, estoy con venkman.
Claro que un patron no siempre hay que aplicarlo tal cual biene en los libros, lo normal suele ser hacer pequeñas modificaciones aqui o alla para encajarlo en tu contexto, pero siempre que tu solución logre cumplir los objetivos de diseño que se marca el patron. El singletton es el más sencillo de todos, es una forma de lograr que sólo se genere una instancia de una clase en tu programa, si tu solución no cumple esa premisa (y en este caso no la cumple, puedo crear todas las que quiera) entonces no es un singletton.
Dado que en JavaScript esto de los singletton no tiene mucho sentido yo personamente lo cambiaria, sobre todo si es un framework con objetivos didacticos, o como minimo aclarar que esa clase se hace así por analogía con lo que se haria en java pero que seria mejor de este otro modo y bla,bla,bla. Sino la gente terminará pensando que esa la forma adecuada de afrontar el problema en JS y creo que no lo es.
Sobre la herencia con prototipos que ha pusto venkman, no digais que no es curioso el jodio JavaScript :P, estas dos lineas sobre todo:
PiezaMaterial.prototype = new Pieza();
PiezaMaterial.prototype.constructor = PiezaMaterial;
es un mecanismo potente desde luego, tu decides como construyes tu "clase" de modo que no es dificil hacer herencia multiple, hereder sólo los metodos que te interesen y demás combinaciones variopintas, total estas definiendo tu clase en tiempo de ejecución.
Pero personalmente sigue sin gustarme demasiado porque, en mi opinión aclaro, es bastante confuso y cuando el volumen de código se dispare puede dar lugar a lios importantes si no se anda con cuidado. al final tanta libertad me va a obligar a definir una serie de pautas de "como hacer herencia, como tratar esto otro" para que quede un código base homogeneo (lo que hacen prototype, ext, dojo...), y esas pautas son entre otras cosas las que ya me da un lenguaje estatico y con clases. Y luego me faltan muchas cosas cuando programo en JS a nivel de herramientas, que son igual de importantes ( a veces más diria yo) que la propia sintaxis del lenguaje cuando estoy en proyectos gordos. Documentación, autompletado y generación de código, refactorización, etc,etc.
Hola Venkman y remoh,
no seamos exagerados. Yo no digo que haya que documentar las cosas y dejar de evitarlas en el código. Lo único que estoy diciendo es que en este caso tengo mucho código JavaScript y que no quiero que la gente tenga que bucear en él para poder saber como usarlo.
Así que decidí que es mucho más cómodo ver el JavaScriptDoc para usar la librería. Y sí es una guarrada, lo reconozco pero quizas la gente se equivoque menos teniendo un JavaScriptDoc donde pone como gastarla aunque se puedan hacer guarradas que si no lo tubieran y hubiera que bucear en todo el código para ver como funciona.
Saludos.
logongas, a ese respecto, lo que creo que no tienes en cuenta es que la gente, eso que tú mismo dices que es tan importante en el proyecto (y lo es, claro), en un proyecto de 40 personas distribuidas en diferentes localizaciones, van a ser los primeros que 1. simplemente pasen de leerse el JavascriptDoc, 2. quizá lo lean, pero desde luego no con detalle, 3. lo lean y a pesar de ello busquen hacer algo que no has previsto o que incluso no quieres que hagan. Porque son personas, porque hay poco tiempo, porque no saben hacerlo bien y tendrían que preguntar y mostrar que no lo saben, porque para hacerlo bien tienen que esperar a que otro desbloquee el fichero que está modificando porque si no no pueden modificarlo ellos, porque hoy están cansados, aburridos, distraidos, porque es martes, porque está ahí, por probar, por mil razones que puedes imaginar y tres millones que ni siquiera podemos imaginar.
Y eso teniendo la documentación, eh. Que no se trata de buscar en el código.
Escribe tu comentario