2011-12-29 9 views
7

Recentemente ho giocato con javascript, HTML5, estensioni chrome, jQuery e tutte quelle cose buone. Sono abbastanza impressionato finora con le possibilità di javascript, l'unica cosa con cui faccio fatica è strutturare il mio codice e tenerlo in ordine. Prima che io lo sappia, le funzioni sono sparse dappertutto. Ho sempre fatto i miei programmi in modo orientato agli oggetti (C++ e C#), e non riesco a mantenere le cose in ordine. Mi sembra di finire sempre con un sacco di funzioni di utilità statica, dovevo "pensare" in C#.Mantenere il javascript strutturato e ordinato (come programmatore OO)

Ho cercato alcune informazioni sugli oggetti in javascript, ma è seems to come down to wrapping functions in functions. È un buon modo per strutturare il codice base? In superficie sembra un po 'hacker. O ci sono altri modi per mantenere le cose in ordine per una mentalità OO?

+1

http://addyosmani.com/blog/essential-js-namespacing/ e http://dustindiaz.com/namespace-your-javascript/ sono buone letture – naveen

+0

"Le funzioni di wrapping nelle funzioni" non sono affatto "hackish". I programmatori Haskell lo fanno sempre. –

+0

Da allora ho letto su programmazione e chiusure funzionali e hai ragione. È solo un po 'un cambiamento di mentalità da OOP, quindi a prima vista potrebbe sembrare un po' strano. – diggingforfire

risposta

1

Uno dei migliori OOP JavaScript librerie là fuori è la biblioteca di chiusura di Google http://closure-library.googlecode.com/svn/docs/index.html

E 'strutturato in modo che i programmatori OOP avranno familiarità soprattutto se si proviene da un Java/C# sfondo. Dai un'occhiata al codice sorgente di qualsiasi file e dovrebbe sentirsi a casa come programmatore OOP. http://closure-library.googlecode.com/svn/docs/closure_goog_graphics_canvasgraphics.js.source.html

+0

La sorgente sembra davvero molto familiare e l'utilizzo delle chiusure mi dà un'idea abbastanza precisa di come risolvere il problema. – diggingforfire

1

L'utilizzo di un framework progettato per soddisfare requisiti simili può essere una buona idea.

Ma ci sono alcune cose che si dovrebbe davvero seguire per essere efficienti:

  • ricordare di chiusure in JavaScript e non dimenticare var parola chiave,
  • uso callback, ove possibile e ragionevole, JavaScript è asincrona da nature,
2

Un aspetto importante da ricordare su Javascript è che si tratta di un linguaggio prototipo. Le funzioni possono essere oggetti e qualsiasi cosa può essere messa sull'oggetto, spesso influenzando gli oggetti correlati nel processo. Non esiste un modo ufficiale per "estendere" un oggetto a causa di ciò. È un concetto che ho ancora difficoltà a capire.

Javascript "agisce" come qualsiasi altro linguaggio OOP per la maggior parte, con alcune eccezioni, ovvero estendendo gli oggetti (http://jsweeneydev.net84.net/blog/Javascript_Prototype.html).

Dopo una ricerca approfondita, ho trovato un modo molto, molto leggero per simulare gli oggetti in espansione (lo sto usando usando nel mio GameAPI). Il primo campo è l'oggetto genitore, il secondo è l'oggetto che si espande.

extend : function(SuperFunction, SubFunction) { 

    //'Extends' an object 

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

Questo link potrebbe chiarire alcuni problemi e malintesi: http://www.coolpage.com/developer/javascript/Correct%20OOP%20for%20Javascript.html

Personalmente, tendo a essere anti-quadro, e non ho visto un quadro ancora che non forza il programmatore a cambiare in modo significativo il loro stile di programmazione a questo proposito. Più potere a te se ne trovi uno, ma è probabile che non ne avrai davvero bisogno.

Il mio consiglio migliore è di provare ad adattarsi allo stile prototipico di Javascript, piuttosto che imporre vecchie metodologie su di esso. So che è difficile; Sto ancora provando a me stesso.

Buona fortuna per scavare.

2

Generalmente seguo lo schema make-an-anonymous-function-then-call-it. Fondamentalmente, si crea un ambito interno e si restituisce un singolo oggetto contenente l'interfaccia. Nient'altro sfugge, perché è tutto intrappolato nell'ambito della funzione. Ecco un esempio utilizzando 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); 

Ora, dopo tutto questo codice viene eseguito, si finisce con una classe, FancyWidget, che è quindi possibile creare un'istanza.

È possibile definire più classi in questo modo; invece di usare return FancyWidget, è possibile restituire un oggetto letterale invece:

return { 
     FancyWidget: FancyWidget, 
     Frobnicator: Frobnicator, 

     // Nested namespaces! 
     extra: { 
      thing: thing, 
      blah: blah 
     } 
    }; 
Problemi correlati