OOP clarification
Collapse
X
-
frank,
Like you said, you seem to gravitate towards a single-function class. If me and you were to design a CAR class:
testDrive.php // uses car class
car.class.php // the car class
you'd be more likely to create one that would start, drive forward, turn left, turn right, reverse and stop all with one call to the class.
If I designed it, I would do it so that it can do it in that same order you did AND most importantly in /any/ other combination possible. For example I could make it start, make 4 left turns and stop WITHOUT even changing my class file, i'd make another file that uses it and call it testDriveTwo.ph p.
My point demonstrates two important benefits of OOP: Extensibility and Reuse.
Think like the manufacture of the object. Would one design a microwave that /only/ reheated pizzas?
Hope that clarifies that subject of Reuse.
DanComment
-
Models, and the concept of separating data-interaction from the business logic, belong to the MVC and tier-3 design patterns, not OOP.
(Although, OOP designs tend to end up in that territory.)
OOP is just the tool used to implement these patterns.
You don't have to know how to read a blueprint to operate a hammer :P
I do agree tho that once you start building OOP applications, using these design patterns is a very very good idea. The separation of the data, business and presentation layers is essential in any large application.Comment
-
But yea, that's exactly the point I am trying to make.
Classes are more like function libraries than single functions.
They should provide the option of performing tasks, but not simply perform a single task on creation.Comment
-
Can't really agree with you on that one.
Models, and the concept of separating data-interaction from the business logic, belong to the MVC and tier-3 design patterns, not OOP.
(Although, OOP designs tend to end up in that territory.)
OOP is just the tool used to implement these patterns.
You don't have to know how to read a blueprint to operate a hammer :P
I do agree tho that once you start building OOP applications, using these design patterns is a very very good idea. The separation of the data, business and presentation layers is essential in any large application.
Mark (also still a newbie(ish) at OOP).Comment
-
Maybe I just need to loosen up a bit :)
But, yea.
Encapsulation and abstractation / interfaces are very important OOP concepts.
This thread covers the first one. Next thread: Abstractation :)
Inheritance and polymorphism should also make that list.
Although you can't really talk about abstractation without inheritance, can you...Comment
-
Comment
-
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 :PComment
-
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)?Comment
-
I didn't state that for nothing…
if JavaScript would have had classes, it wouldn't be prototype-based…
I may have misunderstood you.
(I was/am very tired :P)
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.Comment
-
Code: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.
EDIT: what I wanted to say, is inheritance depending only on classes? or is it like OOP more of a concept?Comment
-
just because I'm reading about JS inheritance… an example
Code:// 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; }
Code:/* 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);
Comment
Comment