OOP Question - Whats the point of the 'Constructor' in a Class?

[superwormy]

RIGHT, I REALIZE THAT, THAT'S WHY I STATED BEFORE, FOR NON-STATIC VALUES:

So... basically a Constructor is used to initialize variables to a NON-STATIC value ( I see no value of using it to initialize static values, cause you can do that when you declare the vars in your var $varname statement. )

Now, I ask AGAIN:

So... basically a Constructor is used to initialize variables to a NON-STATIC value ( I see no value of using it to initialize static values, cause you can do that when you declare the vars in your var $varname statement. )

OR

To call another object or method when the current object is created.

Yes? Is this pretty much the case across all languages out of curiosity? Any other purposes?

[g00bster]

Originally posted by superwormy
RIGHT, I REALIZE THAT, THAT'S WHY I STATED BEFORE, FOR NON-STATIC VALUES:




Now, I ask AGAIN:

So... basically a Constructor is used to initialize variables to a NON-STATIC value ( I see no value of using it to initialize static values, cause you can do that when you declare the vars in your var $varname statement. )

OR

To call another object or method when the current object is created.



Yes? Is this pretty much the case across all languages out of curiosity? Any other purposes?

yes. take caps off and stop flaming ppl that are trying to help you

[Weedpacket]

Originally posted by superwormy
Now, I ask AGAIN:

Gee, why are you sounding so desperate - you got a school assignment or something? 🙂

Constructors are used to construct objects from classes, hence the name. What more do you want? Laundry services?

As for whether it's the same across langauges - it depends entirely on the language. Some languages don't even have variables, let alone objects.

[jimson]

if you got to create more than 100 classes in your application, why don't just make it procedural code.

OOP and its constructor just a way to manage code.
they don't really help IMHO. 🙂

[superwormy]

All I wanted was to know if constructors did anything else besides initialize variables to non-static values and / or call other objects.

Do they do anything else besides that?

So far crosbystillsnas has posted a useless thing without reading previous posts, g00bster has explained to me that they only apply to objects, which I knew, hence the title of the tread, OOP Question..., and now jimson is going totally off topic and telling me about how its better to just use procedural code.

Don't you find that frustrating when half the posts to your topic are entirely off-topic or posted without people actually reading your question?

[ahundiak]

The only thing that other functions/methods can do that you cannot do with a constructor is to return a value.

For example, code in the constructor could easily open a connection to a database, query some records, perform some calcs and output some html code.

In fact, most of my scripts have one master script object. I just create one of these objects and let it run. This object in turn creates many other helper objects which contain most of the actual code.

[jimson]

i thought i already answered u... well... ok..

Whats the point of the function / method User()?
<< it functions as class constructor.

What is it supposed to do
<< people use it to initialize variable and its values.
<< some also use it to run a function / method whenever the object is initialized with new User();

Why is it always in every class I see
<< because every people have a different way of initializing variables and it values or u might want to say attributes. It also depend on the application scale.

why is it alwasy used to set a variable equal to a value
<< because this is one of the constructor's function

when I can just set its value when I initialize it with var $varName?
<< like i said before, unless u are in the medium large size application. people get confused when they have thousand of class and they want the class to have a same attributes.

$a = new user();
$a->type = 'user';

$b = new user();
$b->type = 'user';

$c = new user();
$c->type = 'user';

/*
if u got thousand classes, u will find it stupid to do same things 
again and again. thats why there is a need of constructor. so u 
just need to declare the variable and no worry about being 
confused or forget to initialize the user object with attribute type 
='user' whenever u declared it...
*/

like i said before.

OOP and its constructor just a way to manage code.
they don't really help IMHO. 😉

[Doug_G]

A constructor in a class will do whatever you need to have happen when your program creates an instance of a class. This may include initializing variables, opening database connections, or whatever.

Keep in mind when you create an instance of a class in your code, you may immediately try to read a property variable of the class and if the variable hasn't been initialized properly you'll get some garbage or an error back to your program.

Hopefully classes in PHP5 will include some of the currently missing features that should be there, particularly private functions and variables that aren't exposed by an instance of the class.

I'd like to see a destructor also.

[Weedpacket]

Originally posted by Doug G
Hopefully classes in PHP5 will include some of the currently missing features that should be there, particularly private functions and variables that aren't exposed by an instance of the class.

I'd like to see a destructor also.

From what I've seen of the beta, it does; along with things like class constants, which is nice.

[Weedpacket]

Originally posted by jimson
OOP and its constructor just a way to manage code.
they don't really help IMHO. 😉

You've also said before that you don't have much experience, so it's a bit early for you to be getting religously anti-OO.

If I want to read from an object with a read() method, I don't want to have to care whether it's reading from a file or an array or a resource or a device or its navel; I just $object->read(). Let the object figure out how read() is supposed to work. And I'm ralfed if I'm going to rewrite read() every time I come up with a new source to read from.

But, as superwormy pointed, this is off-topic.

[Codewarrior123]

So... basically a Constructor is used to initialize variables to a NON-STATIC value ( I see no value of using it to initialize static values, cause you can do that when you declare the vars in your var $varname statement. )

That isn't exactly true (at least in PHP4).

Another thing to consider is that (as hard as it tries) PHP isn't really an OO language. Heck, this whole type juggling system dosn't lend itself to strict derivation and whatnot very well at all.

Constructors and destructors serve a purpose in more fully object oriented langauges. C++, and it's dynamic memory allocation scheme, is an excellent example.

You need to be able to get an object 'ready' to play with the rest of your code by allocating memory and whatnot, depending on the circumstance. That's all handled by the constructor. Where would your favorite vector class be if it were uninitialized?

Likewise, you must explictly free memory that you've allocated. This would be very inconvienet if you had to write and call your own functions every time an object went out of scope. If you forgot, you would be left with any number of memory leaks, and one hell of a debugging problem. To save you C++ provides the destructor, which is gaurnteed to be called when your object goes out of scope. It's essentailly a cleanup function.

[jimson]

If I want to read from an object with a read() method, I don't want to have to care whether it's reading from a file or an array or a resource or a device or its navel; I just $object->read(). Let the object figure out how read() is supposed to work. And I'm ralfed if I'm going to rewrite read() every time I come up with a new source to read from.

i believe the OOP approach is to help programmer towards manageble code. but it seems that it fails to do so, IM"H"O.
IM"H"O, OOP is just "grouping functions" and assign it into object.

i believe the most important part about OOP is object modelling.

if one have a lousy modelling technique, then the code also lousy.

but sometime/or mosttime, the event, process or whatsoever are hard to model.

we can make class very tiny like atom or large like computer.
then if u have hundred of major classes and you call it manageble code, then i have nothing to say.

if you are fully into OOP mode, then there should be a class that you only initialize it one time. then there is tiny classes that probably u call it nearly hundred over times.
if that happened, why don't u just turn the tiny class into function...?

IMHumbleO, OOP is just for people who are disinterest in procedural grouping.

[Codewarrior123]

if one have a lousy modelling technique, then the code also lousy.

Of course that's true of everything.

[Weedpacket]

Well, I don't have a barrow to push either way, really; procedural, OO, functional, whatever the programming paradigm. I don't see why "procedural grouping" (whatever that is) is any better that it automatically makes anyone not using it Wrong. Ah, but who cares?

And yes, I do find I can understand class hierarchies with thousands of members, if they're designed right. Maybe, Jimson, your problem is that you aren't skilled enough to design them right.

[jimson]

Maybe, Jimson, your problem is that you aren't skilled enough to design them right.

he he... 😉 ... maybe... :?
is a class with hundreds of methods a good class?

or it shoulds be break into more smaller class (more deeper)?