OOP clarification

[Atli]

The thing about getters and setters...

Implementing a getter and setter on the same variable (effectively making it a public variable) might seem unnecessary, seeing as we have the public keyword, but simply making it public restricts how you can use it in the future.

Consider if, in the soon to become present, you have the need to run some code on the new value of a variable before it is set. If you had had the foresight to create a setter for it, this would be no problem. But if it is just a public variable, you can't do that without breaking every code that uses this variable.

As you have found out, a simple change to the class design can have a devastating effect on your entire application.

And moreover, if you intend to have some variables read-only and some public, having getters for some of them and direct calls to others will make your class horribly inconsistent. (I HATE inconsistencies :P)

In my mind it's either/or. Use getters/setters on everything or nothing.
(My preference being everything.)

Supposedly, the getters and setters reveal too much implementation detail because they are typed. What happens if the type changes in the future then everything that calls those getters and setters might have to be updated.

How is that any different from a public variable?
Would the code not have to be altered just as much if the type of a public member changed?
Not that this is an issue in PHP. It's a loosely-typed language so there is no need for typed methods/members.

[Dormilich]

Supposedly, the getters and setters reveal too much implementation detail because they are typed. What happens if the type changes in the future then everything that calls those getters and setters might have to be updated.

that's why there are interfaces for the classes, that prevents such problems.

on the other hand side, the calls for __get() and __set() are unlikely to change (though they don't work on public properties)

[fjm]

I think it's about having control. you'll see that if you look at an exception backtrace. if there's a (g|s)etter involved, you know the property had (not) been touched.

and on the other hand, how else would you code read-only properties?

I agree with you Dormi. Here.... I found an excerpt of why these are *supposedly* so bad:

Supposedly, the getters and setters reveal too much implementation detail because they are typed. What happens if the type changes in the future then everything that calls those getters and setters might have to be updated.

[Dormilich]

And, BTW: what's all the fuss about using getters and setters?

I think it's about having control. you'll see that if you look at an exception backtrace. if there's a (g|s)etter involved, you know the property had (not) been touched.

and on the other hand, how else would you code read-only properties?

[fjm]

Hey Dan, thanks for this great comparison. Let me ask you a few questions about the methods you chose plus I'd like to respond to a few of your comments.

1. Frank, I think you're treating a class like it's a script. Two things lead me to this; one is the quote:
. And second is how your constructor is sort of like a trigger and creates a domino affect.

Yes, agreed... I see it now only because it happened to me where a small change created this huge ripple effect throughout my program. A lesson well learned. The good thing is that I never seem to get tired of refactoring my code. :) I'll now go back and redo these classes the right way.

I do not use getters and setters if all they do is directly alter the private member. Might as well make it public anyway. You should have functions that are like "verbs" or actions to the class. For example if the class was a car, accelerate(valu e) , turnOnHeadlight s() etc. while gas-pedal, headlight, wheel where private members. Say to yourself if this was a real life object what would it "do".

All of my methods are using verbs like you suggest. Only thing that I'd like a bit of clarification on is that I noticed that you have a method for accelerate(). In my mind, there are other things that need to happen before actually accelerating such as pressing down the accelerator pedal. I know it may seem like I'm splitting hairs here but I'm just trying to understand is all. Would you just combine the pressAccelerato r() method in with the accelerate() method? Is there such a thing as taking something out too far? I mean, you could conceiveably say that the accelerator pedal should only move downward a certain amount of distance. Should that be its own method? I know that my examples are corny but I hope you see my point in it.


Thanks,
--Frank

[fjm]

And, BTW: what's all the fuss about using getters and setters? I have read a lot of things about how a "true" OO system really isn't OO if you use setters and getters. I'm sure you guys know what they are talking about but its a bit over my head. Can someone please explain?

If needed, I will grab some of these links.

[fjm]

Hey!! I never got notification that this post was updated since I last posted here!!! :(

Well, I'm glad to see that this thread is still going. I came back today to tell you guys that I now see the point about designing classes where it won't affect your application code. Here's what happened to me this past weekend....

I needed to add some functionality to my app and when I went into the class to make the change, everything was cool..... that is, until I started the app again and saw that everything was broken. Designing a class with a single action is a very bad thing. It had a rippling effect through the app where this class was being used. Luckly for me though, I had a handy-dandy search/replace function built into my trusty IDE so I was back up and running in no time. :D

So listen up kids... don't design your classes to do single functions. dlite22 summed it up pretty well with his car class comparason. Actually, all you guys are great and are truly helpful. Thanks!

[Atli]

So what's the object oriented way of getting rich?

$$$$$$$$$$

[code=php]$this->money++;[/code]
8-)

[dlite922]

So what's the object oriented way of getting rich?

$$$$$$$$$$

[Dormilich]

just because I'm reading about JS inheritance… an example

// by Gavin Kistner
// because there is no native "extend" functionality
Function.prototype.extends = function( parentClassOrObject )
{
	if ( parentClassOrObject.constructor == Function )
	{
		//Normal Inheritance
		this.prototype = new parentClassOrObject; // this is the inheritance
		this.prototype.constructor = this; // reset the constructor name
		this.prototype.parent = parentClassOrObject.prototype; // attaching prototype chain
	}
	else
	{
		//Pure Virtual Inheritance
		this.prototype = parentClassOrObject;
		this.prototype.constructor = this;
		this.prototype.parent = parentClassOrObject;
	}
	return this;
}

/* and now for the example part */

Lebewesen = { 
	die: function() {
		this.state = "dead";
	},
	born: function() {
		this.state = "alive";
	} 
}

function Animal()
{
	this.born();
	this.type = "Animal";
}

Animal.extends(Lebewesen);

Animal.prototype.toString = function()
{
	return this.state;
}

Animal.prototype.getType = function()
{
	alert(this.type);
}

function Horse(name)
{
	this.born();
	this.type = "Horse";
	this.name = name;
}

Horse.extends(Animal);

var x = new Horse("Binky");
x.getType();
x.die();
alert(x);

[Atli]

You've got a point there.

Inheritance or extensibility.. . I guess that's just semantics. Both achieve the same thing, even tho they use different methods; an object that inherits it's base functionality from another object/class.

[Dormilich]

Classes aren't objects. They are blueprints for creating objects.
[…]
Prototype-based objects are already objects.

well, objects are object, whether they come from a blueprint or not. you can also look at inheritance like that: if an object uses a member, that is not part of it's own declaration, then there is inheritance. how that member was attached to the object is of no concern.

Extending such an object involves "physically " cloning the object and then modifying the newly existing clone.

or creating the object from scratch.

var obj = {}; // empty object like stdClass

It's like... Say there is an old car you want to upgrade.
On one hand (prototype-based), you could take the old car, build another one exactly like it, and then modify it to apply your upgrades.
Or (class-based), you could modify the blueprint for the old car and build a new one based on the modified blueprint.

and in either case you have a new car with extended functionality. and your neighbour wouldn't know if you used a paper plan or daddy's old car for the blueprint.

EDIT: what I wanted to say, is inheritance depending only on classes? or is it like OOP more of a concept?

[Atli]

I didn't state that for nothing…

if JavaScript would have had classes, it wouldn't be prototype-based…

O, so we were actually saying the same thing?
I may have misunderstood you.
(I was/am very tired :P)

and looking from this side, what is the difference between inheritance and extensibility then (I dimly remember there is a keyword "extends" in PHP)?

Well, the way I see it...

Classes aren't objects. They are blueprints for creating objects.
So when you extend a class, you are inheriting instructions on how to build an object, which you can use at runtime to build the object the child class describes.

Prototype-based objects are already objects.
Extending such an object involves "physically " cloning the object and then modifying the newly existing clone.

It's like... Say there is an old car you want to upgrade.
On one hand (prototype-based), you could take the old car, build another one exactly like it, and then modify it to apply your upgrades.
Or (class-based), you could modify the blueprint for the old car and build a new one based on the modified blueprint.

[Dormilich]

JavaScript doesn't have inheritance (or abstractation, for that matter)... It has extensibility.
It has no concept of classes (object blueprints), so there is nothing to inherit.

I didn't state that for nothing…

if JavaScript would have had classes, it wouldn't be prototype-based… and looking from this side, what is the difference between inheritance and extensibility then (I dimly remember there is a keyword "extends" in PHP)?

[Atli]

as long as we're not discussing class based (PHP) and prototype based (JavaScript) inheritance… just had a look at OOP @ wikipedia

JavaScript doesn't have inheritance (or abstractation, for that matter)... It has extensibility.
It has no concept of classes (object blueprints), so there is nothing to inherit.

You can only extend preexisting objects, which are always initially created as blank objects, and then initialized by either adding prototypes or just adding properties (which are essientially just array elements gone wild).

... or so I have been lead to believe. I'm no Javascript expert, really :P