OOP Script!!!

[Unknown]

Comment about it.

[RadarBob]

OK
BTW this post should not be in the "post a javascript" area. This area is really for complete, "use this if you want", code


A Rose by any other name is anybody's guess what it is
Remember your Hi-Skule English - that's the watch word here.

Objects should be nouns - the name of a "person, place, or thing." Also the name should be descriptive. "h1guy". What is an "h1guy"? Maybe "player"? or some "kindofplayer".

Methods should be action verb - object pairs. Like "takeawayPoints", or "hitMe" or "damagePlayer"...

Object construction
Complete your Design
One thing that stands out is that you must have different status states (or values). Your getstatus() method suggests zero points is a state of dead. You should create these states explicitly as "constants". These will come in very handy later on (see design for change below).

function h1guy (...) {
   this.DEAD = 0;
   this.FULL_HEALTH = 100;
   . . .
   this.health = health;
} 

Encapsulate Methods
Put your methods *inside* the h1guy object. As it is, they are defined outside the h1guy object. When you include this code in you web page, these functions have "global scope" as it were. If these function/method names conflict with any other function names on the page, well, the page is broken.

By putting the names inside the object function you encapsulate them w/in the function. THEN other objects can have the same function names; or the same function name can appear somewhere else on the page. Finally the code is made more reusable.

Here's how it could look:

function hlguy(name, health, armor, weapon)
{
this.name=name;
this.health=health;
this.armor= armor;
this.weapon=weapon;

this.getstatus = function getstatus() { ... };
this.display = function display() { ... };
this.hurt1hp= function hurt1hp () {...};
this.hurt2hp= function hurt2hp () {...};
this.hurt3hp= function hurt3hp () {...};

} 

Superfluous Methods
You have three methods all doing the same thing. Here's what it could look like:

function hurtPlayer (numOfPoints) {  // remember, good method names
   this.health -= numOfPoints;
} 

Design for Change
This takes some foresight, experience, practice..

I think your getStatus() method could be written differently to facilitate changes later on... As it stands if you need to add new statuses (stati?) you'll be adding "else if"s to the code here. Not only is that changing the existing control structure (from just "else" to "else if") but IMHO it's more error prone than a switch statement. Here's what it could look:

function getstatus () { // poor name. Should be getHealth
   return this.health;
}

. . .

function displayHealth () {  
// better name might be getHealthMessage() or buildHealthMsg()
// OH! even better - getStatusMessage() 
   var myStatus = new String();
   
   switch (true) {
      case this.health == this.DEAD:
         myStatus += this.name + "is Dead!";
         break;

       case this.health == this.FULL_HEALTH :
          myStatus += this.name + "is rip-roaring to go!";
          break;

      default
         myStatus += "Houston, we have a problem - unknown player health = " + this.health;
   } //switch

   return myStatus;
} 

Notice how several things come together here to make a method with some good attributes.

• extensible adding another case clause is much easier than modifying an if/else if structure. Also, should you ever re-define the status of DEAD to be 10 (ten or less is the intent) for example, then you don't even have to touch any function code!
• clarity By using those constants, it's clear even to the casual reader what's going on.
• Reusable You're never gonna be able to reuse your h1guy object if you tie methods directly to specific form fields on the page. Your methods should always return something - in this case a message about the players status. It's then up to the calling code to do something with this message.
• Structured programming technique - A primary principle is "minimize coupling and maximize cohesion." OK, that doesn't make sense.. but what "cohesion" means is make a function do ONE thing and ONE thing only. A function like "getStatus()" should get the status (ok "health" - the function is poorly named). If you need to throw up various alerts based on health, then rename the function.
• Structured Programming 2 One principle of structured programming is "enter (only) at the top and exit (only) at the bottom." We enter at the top ok (the function call doesn't start in the middle of the function code - as some pgming languages allow). "Exit at the bottom" means there is only one "return" statement and we do that at the end of the function. This is why I create a string and pass that, rather than return "this guy is xxxx" for every CASE clause.
• OOP standard practice is to have a set of setxxx and getxxx functions that fetch and set the object's attributes. OK, tha's not necessary in JavaScript because any code that creates a h1guy object can reference the properties directly; but if you want to adhere to OOPs "best practices" don't do that. In a real OOP language, you have to create these functions because the properties will be "private".

[SvendTofte]

You could force usage of getters and setters, by using a closure to hold the variables.

js> x.getBaz();
js> function foo() {
    var baz = 42;
    this.getBaz = function bar () {return baz;}
};
js> x = new foo();
[object Object]
js> x.getBaz();
42
js> x.baz; // nothing
js>

[liorean]

Svend! Imagine seeing you here...
Welcome!

[RadarBob]

Originally posted by SvendTofte
You could force usage of getters and setters, by using a closure to hold the variables.

js> x.getBaz();
js> function foo() {
    var baz = 42;
    this.getBaz = function bar () {return baz;}
};
js> x = new foo();
[object Object]
js> x.getBaz();
42
js> x.baz; // nothing
js>

So Svend,
Are you saying that if we create the object's properties as "var" instead of "this." that we get all the function and benefits of an 'object scope' property and also the encapsulation of a local variable?

[liorean]

Yes he is. Have a look at <http://www.pbwizard.com/Articles/class_inheritance.htm>