2011-12-29 15 views
7

Recientemente he estado jugando con javascript, HTML5, extensiones de cromo, jQuery y todas esas cosas buenas. Estoy bastante impresionado hasta ahora con las posibilidades de javascript, lo único que me cuesta es estructurar mi código y mantenerlo ordenado. Antes de darme cuenta, las funciones están dispersas por todo el lugar. Siempre he hecho mi programación de una manera orientada a objetos (C++ y C#), y no puedo mantener las cosas ordenadas. Siento que siempre termino con un montón de funciones estáticas de utilidades, si tuviera que 'pensar' en C#.Mantener su javascript estructurado y ordenado (como programador de OO)

He estado buscando información sobre objetos en javascript, pero es seems to come down to wrapping functions in functions. ¿Es esta una buena forma de estructurar tu código base? En la superficie parece un poco hackish. ¿O hay otras formas de mantener las cosas ordenadas para una mentalidad de OO?

+1

http://addyosmani.com/blog/essential-js-namespacing/ y http://dustindiaz.com/namespace-your-javascript/ son buenas lecturas – naveen

+0

"Envolviendo funciones en funciones" no es "hackish" en absoluto. Los programadores de Haskell lo hacen todo el tiempo. –

+0

Desde entonces he leído sobre la programación funcional y cierres y tienes razón. Es solo un cambio de mentalidad de OOP, por lo que a primera vista puede parecer un poco extraño. – diggingforfire

Respuesta

1

Uno de los mejores POO javascript bibliotecas por ahí es la biblioteca de cierre de Google http://closure-library.googlecode.com/svn/docs/index.html

Está estructurado de forma que los programadores de POO estarán familiarizados con todo si usted viene de un Java/C# fondo. Eche un vistazo al código fuente de cualquier archivo y se sienta como en casa como un programador OOP. http://closure-library.googlecode.com/svn/docs/closure_goog_graphics_canvasgraphics.js.source.html

+0

La fuente realmente parece muy familiar, y el uso de cierres me da una muy buena idea de cómo resolver las cosas. – diggingforfire

1

Usar una estructura diseñada para cumplir requisitos similares puede ser una buena idea.

Pero hay algunas cosas que realmente debe seguir para ser eficiente:

  • recordar acerca de cierres en JavaScript y no se olvide de var palabra clave,
  • devoluciones de llamada de uso siempre que sea posible y razonable, JavaScript es asincrónica naturaleza,
2

Un aspecto importante para recordar acerca de Javascript es que es un lenguaje prototípico. Las funciones pueden ser objetos y cualquier cosa puede colocarse en el objeto, lo que a menudo afecta a objetos relacionados en el proceso. No hay forma oficial de 'extender' un objeto debido a esto. Es un concepto que todavía me cuesta entender.

Javascript 'actúa' como cualquier otro lenguaje OOP en su mayor parte, con algunas excepciones, a saber, la extensión de objetos (http://jsweeneydev.net84.net/blog/Javascript_Prototype.html).

Después de una extensa investigación, encontré una manera muy, muy ligera de simular la expansión de objetos (estoy usando su uso en mi GameAPI). El primer campo es el objeto principal, el segundo es el objeto que se expande.

extend : function(SuperFunction, SubFunction) { 

    //'Extends' an object 

    SubFunction.prototype = new SuperFunction(); 
    SubFunction.prototype.constructor = SubFunction; 
}, 

Este enlace puede aclarar algunos problemas y conceptos erróneos: http://www.coolpage.com/developer/javascript/Correct%20OOP%20for%20Javascript.html

Personalmente, tiendo a ser anti-marco, y no he visto todavía un marco que no obliga al programador cambiar significativamente su estilo de programación en este sentido de todos modos. Más poder para ti si encuentras uno, pero es probable que no lo necesites.

Mi mejor consejo es tratar de adaptarme al estilo prototípico de Javascript, en lugar de forzar viejas metodologías sobre él. Sé que es complicado; Todavía estoy intentándome a mí mismo.

Best of luck diggingforfire.

2

Generalmente sigo el patrón make-an-anonymous-function-then-call-it. Básicamente, creas un ámbito interno y devuelves un único objeto que contiene tu interfaz. No se escapa nada más, porque está atrapado dentro del alcance de la función. Aquí hay un ejemplo usando jQuery:

var FancyWidget = (function($) { 
    // jQuery is passed as an argument, not referred to directly 
    // So it can work with other frameworks that also use $ 

    // Utility functions, constants etc can be written here 
    // they won't escape the enclosing scope unless you say so 
    function message(thing) { 
     alert("Fancy widget says: " + thing); 
    } 

    // Make a simple class encapsulating your widget 
    function FancyWidget(container) { 
     container = $(container); // Wrap the container in a jQuery object 
     this.container = container; // Store it as an attribute 

     var thisObj = this; 
     container.find("#clickme").click(function() { 
      // Inside the event handler, "this" refers to the element 
      // being clicked, not your FancyWidget -- so we need to 
      // refer to thisObj instead 
      thisObj.handleClick(); 
     }); 
    } 

    // Add methods to your widget 
    FancyWidget.prototype.handleClick = function() { 
     this.container.find("#textbox").text("You clicked me!"); 
     message("Hello!"); 
    }; 

    return FancyWidget; // Return your widget class 
         // Note that this is the only thing that escapes; 
         // Everything else is inaccessible 
})(jQuery); 

Ahora, después de todo este código se ejecuta, se termina con una clase, FancyWidget, que luego se puede crear una instancia.

Puede definir múltiples clases de esta manera también; en lugar de utilizar return FancyWidget, puede devolver un objeto literal en su lugar:

return { 
     FancyWidget: FancyWidget, 
     Frobnicator: Frobnicator, 

     // Nested namespaces! 
     extra: { 
      thing: thing, 
      blah: blah 
     } 
    }; 
Cuestiones relacionadas