[BOOJS] when or when not to use oo javascript

[Pauline McNamara]

Welcome to the ranch Stoyan.

Given that object-oriented in javascript doesn't necessarily look the same as object-oriented in java, I'm wondering about "creating objects in javascript" (as one chapter is called). Does that refer to creating your own objects, as opposed to using built-in ones?

For people who are just beginning to learn or use javascript, when should they be thinking about creating objects? Even when they're doing what seem like simple scripting tasks?

Is there a fuzzy line where you decide, "OK, better refactor this to be more object-oriented...", but before that point it's not really worth it?

Oops, that looks like a bunch of questions in one post, but it's really just a bunch of ways to put mostly one thing that I'm wondering about into words.
[ August 26, 2008: Message edited by: Pauline McNamara ]

[B Webb]

If the objective is to show a message stating "hello world", a simple function in the main bode of the page would suffice (eg. alert("hello world"). On the other hand...

I'll use the car analogy here...If you want to show a car on your home page, and you want to allow the user to design their car first, would you put that code in the main body of the page? Likely not...you would create a car class that receives various parameters submitted by the user, which would return a car object (xml response of various attributes like size, color, number of doors, etc.), that the DOM uses to show the car. This allows you to onSubmit instantiate a car class and pass the parameters in your function...much cleaner and more maintainable.

[Pauline McNamara]

Clearly two examples at different ends of the spectrum. I'm wondering more about the process, as when a project grows, and when it starts to make sense to switch/refactor to object creation. Reflections from the trenches as it were...

[Stoyan Stefanov]

In javascript pretty much everything is an object, so you'll be writing OO code even if you don't realize it. No escaping from OO, so it's better to embrace it from the beginning

Even for the simplest tasks, one good thing to do is to namespace your code. Let's say all you need is a function to validate a form, let's say you have a simple search box and you want to check if there's something typed in it before to send a request to your tired old server.

so you can easily do something like:

<form action="search.php" onsubmit="if (this.elements[0].value === '') {alert('please type a search string'); return false;}">
  <input name="q">
</form>

However, this is wrong on so many levels

First off, mixing content (HTML) and behavior (JS) is a no-no. All your JS code should be in a separate file and the markup should be clean and semantic. So slightly better example:

HTML:

<form action="search.php" id="search-form">
  <input name="q">
</form>
<script src="some.js" type="text/javascript"></script>

JS:

var myform = document.getElementById('search-form');
 
function validate () {
  if (myform.elements[0].value === '') {
    alert('please type a search string');
    return false;
  }
};
 
myform.onsubmit = validate;

Now, this can be improved and you can turn validate() into a reusable general-purpose validation function, but we're talking about the simplest scenario here and for the sake of the example we assume that this page will never get more complex than that (this never happens )

What else is wrong here? Globals. We have a global 'myform' variable and a global validate() function. What can happen? Well, we start rotating ads using some ad provider which serves us random pieces of html. These ads also have scripts. Or, somewhere down the road you include a 3rd party widget of some sort and lo and behold, it comes with a javascript that has a function called validate(). Oops, naming collision.

To prevent such cases, you should always start with namespacing your code.

var JAVARANCH = { // or something you hope is pretty unique
 
  attachSubmitListener: function() {
    if (!this.myform) {
      this.myform = document.getElementById('search-form');
    }
    this.myform.onsubmit = this.validate;
  },
 
  validate: function() {
    if (JAVARANCH.myform.elements[0].value === '') {
      alert('please type a search string');
      return false;
    }
  }
 
};
 
JAVARANCH.attachSubmitListener();
 

This way you pollute the global namespace with only one variable, anything else you need, including other objects, functions and so on, you put as a property of your single global variable.

So, voila, here's an example how OO is the recommended way to go even for the simplest tasks. True, it may be just a little longer than the first example, but we get the benefits: namespacing, separation of concerns (content vs behavior) and maintainability/readability, since the first example is a little hard to read.

[Pauline McNamara]

So, voila, here's an example how OO is the recommended way to go even for the simplest tasks.

Nice example, thanks. I really like that namespacing approach, it looks kind of like an equivalent to class creation in java. For someone who doesn't write much javascript it looks like a good (and simple) way to start out with good habits.

var JAVARANCH = { // or something you hope is pretty unique

We think javaranch is pretty unique indeed. Thanks for visiting with us!

[Stoyan Stefanov]

Originally posted by Pauline McNamara:


We think javaranch is pretty unique indeed. Thanks for visiting with us!

Thank you, I enjoy all the questions on the ranch very much

The JAVARANCH namespace example is kinda inspired by the idea how packages are named in Java, so they are unique, like "com.javaranch.whatever" since domain names are unique.

[Stoyan Stefanov]

btw, the topic title [BOOJS] is kind of funny, like "Boo, JS!" ;P "Get back to your corner!"