Geek Answers Handbook

Keeping your javascript structured and neat (as an OO programmer)

I recently played with javascript, HTML5, chrome extensions, jQuery and all this good stuff. I am still impressed with the features of javascript, the only thing I struggle with is to structure my code and keep it clean. Before I find out, features are scattered all over the place. I always did my programming in an object-oriented manner (C ++ and C #), and I found that I was not able to maintain the order of things. It seems that I always get a bunch of static functions if I were “thinking” in C #.

I was looking for some information about objects in javascript, but it seems to come down to wrapping functions in functions. Is this a good way to structure your codebase? The surface seems a bit hacky. Or are there other ways to keep things in order for the OO to think?

+7
source share
5 answers

One of the best JavaScript OOP libraries has the Google Closure library http://closure-library.googlecode.com/svn/docs/index.html

It is structured in such a way that OOP programmers will be familiar, especially if you come from a java / C # background. Check out the source code of any file and it should feel right at home as an OOP programmer. http://closure-library.googlecode.com/svn/docs/closure_goog_graphics_canvasgraphics.js.source.html

+1
source

One important aspect to remember about Javascript is that it is a prototype language. Functions can be objects, and everything can be placed in an object, often touching related objects in the process. Because of this, there is no official way to "expand" an object. This is a concept by which it is still difficult for me to understand.

Javascript "acts" like any other OOP language, for the most part, with some exceptions, namely with the extension of objects (http://jsweeneydev.net84.net/blog/Javascript_Prototype.html).

After extensive research, I found a very, very easy way to simulate expanding objects (I use it in my GameAPI). The first field is the parent object, the second is the object that is expanding.

extend : function(SuperFunction, SubFunction) { //'Extends' an object SubFunction.prototype = new SuperFunction(); SubFunction.prototype.constructor = SubFunction; },

This link may fix some problems and misconceptions: http://www.coolpage.com/developer/javascript/Correct%20OOP%20for%20Javascript.html

Personally, I tend to be an anti-framework, and I have not yet seen a framework that does not force the programmer to significantly change his programming style in this regard. More energy for you if you find it, but most likely you will not need it.

My best advice is to try and adapt to the Javascript prototype style, rather than impose old methodologies on it. I know this is difficult. I'm still trying to myself.

The most successful thing to dig in the fire.

+2
source

I usually follow the make-an-anonymous-function-then-call-it pattern. Basically, you create an inner scope and return a single object containing your interface. Nothing else escapes, because it is all captured within the scope of the function. Here is an example using 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);

Now, after all this code has been executed, you will get one FancyWidget class, which you can then create.

You can also define several classes; instead of return FancyWidget , you can instead return an object literal:

  return { FancyWidget: FancyWidget, Frobnicator: Frobnicator, // Nested namespaces! extra: { thing: thing, blah: blah } };
+2
source

I have never used this personally, but have repeatedly seen backbone.js referring to this question. See at: http://documentcloud.github.com/backbone/

+1
source

Using some structure designed to meet similar requirements might be a good idea.

But there are some things you must do to be effective:

  • remember closing in javascript and don't forget about var keyword,
  • use callbacks where possible and reasonable, JavaScript is asynchronous in nature,
+1
source

More articles:


All Articles