Bruno Desthuilliers wrote:
[color=blue]
> Justin Koivisto wrote:
>[color=green]
>> Dan wrote:
>>[color=darkred]
>>> I have seen differing ways to pass values to a class:
>>>
>>> $db=new mysqlclass('localhost','user','passwd','database') ;
>>> ....
>>> OR
>>>
>>> $db=new mysqlclass()
>>> $db->host='localhost';
>>> $db->user='user';
>>> $db->passwd='passwd';
>>> $db->database='database';[/color]
>>
>> Usually, I use both ways. For instance, in the class constructor, I
>> allow parameters to be sent as arguements (usually in an array), but
>> leave them optional.[/color]
>
> So the object created without all necessary parameters is not usable.
> Bad Thing(tm).[/color]
I should have made that more clear. Objects that *need* stuff to work
would have them required, everything else is optional...
I do have a few classes that don't need to have anything passed to
work... It all depends on the implementation and what the class is for.
[color=blue][color=green]
>> I set up mutator methods like:
>> function setHost($x){ $this->host = $x; return TRUE; }
>> function setUser($x){ $this->user = $x; return TRUE; }
>> function setPass($x){ $this->passwd = $x; return TRUE; }
>> function setDB($x){ $this->db = $x; return TRUE; }[/color]
>[color=green]
>> As well as accessor methods like:
>> function getHost($x){ return $this->host; }
>> function getUser($x){ return $this->user; }
>> function getPass($x){ return $this->passwd; }
>> function getDB($x){ return $this->db; }[/color]
>
> If your object expose all of it's internal state, it's bad luck. What
> happens if you instanciate the object with all parameters and then
> change the 'User' field only ?[/color]
That was just as example... Again, it depends on what the class
represents and what it is used for.
[color=blue][color=green]
>> Then I have the ability to set up utility methods:
>> function resetConnection(){ return $this->mysqlclass(); }[/color]
>
> You don't need to expose all the object's internal state to write this
> kind of method :
>[color=green]
>> That way, if you want to change sql servers, you don't need to create
>> another object, just use something like:
>>
>> $db->setHost='localhost';
>> $db->setUser='user';
>> $db->setPass='passwd';
>> $db->setDB='database';
>> $db->resetConnection();[/color]
>
> lol, and yuck :([/color]
Funny, huh? Well, this works very well for an online listing class I
have. I use this method to set 3 or 4 options out of the 15 available to
the object at a time. I could set the variables directly, but then if I
want to add functions for checking in the class that's shot.
[color=blue]
> firstly, i'm afraid this code is awfully broken. Should be :
> $db->setHost('localhost');[/color]
Ya, I was in a hurry and didn't look over the message...
[color=blue]
> Then, what happens with this :
> $db->setPass('');
> $db->resetConnection();[/color]
That's what internal class checking is for. In this instance, the
resetConnection might return FALSE and set an error code accessible by
$db->Error();
[color=blue]
> For this to be not too awful, you'd need :
> $db->resetConnection('host', 'user', 'pass', 'db');[/color]
No, maybe I only want to change the host, nothing else...
[color=blue]
> But then - in this particular case - it's just like you've created a new
> object :
> $db = new Db('host', 'user', 'pass', 'db');[/color]
Ya, this was just an illustrative example... I said that in another post.
[color=blue][color=green]
>> You'd also be able to get the connection information via the accessor
>> methods to check what conection you have open.[/color]
>
> And if you changed one of the connection information, and then did not
> 'reset' connection ? out of sync info is worse than no info.[/color]
Again, that's where class error handling comes in... has nobody ever
though of that stuff before!?
[color=blue][color=green]
>> This method also gives you the ability to change variable names in the
>> class without effecting the API of it - making it easier to maintain
>> and sometimes more portable.[/color]
>
> Yes, what a great deal... internally rename '$this->user' to
> '$this->m_str_user_name' without affecting the 'API' (er...).[/color]
Sure, you can just go about assining your variables to user-input
without checking... A more typical mutator would be like this (for example):
function setVariable($x){
if($result=$this->_validate_type($x)){
return TRUE;
}else{
$this->_ERROR=$result*-1;
return FALSE:
}
}
[color=blue][color=green]
>> I guess it all depends if you want to go the true OOP route like C++
>> where there are private and public methods, or like PHP4, where
>> everything is public.[/color]
>
> What is 'public' is what you use outside of the class. What is 'private'
> is what you dont use outside of the class. No need to enforce this with
> builtin keywords and compiler checks.[/color]
The author may know the difference, but if you give it to another
developer, how the hell would they know what they should and shouldn't
use - afterall, the average PHP coder doesn't provide enough
documentation to explain these types of things.
[color=blue][color=green]
>> I usually try to stick with the strict C++ methodology in order to
>> force myself to create better code. (My thinking here is that if I am
>> forced to create all these methods, I may as well spend the extra few
>> minutes checking all input and writing error codes and such that re
>> easier to debug down the road.)[/color]
>
> Nothing forces you to write any getter/setter unless the client code
> really needs it. Should read the pragmatic programmer's advices :
>
http://www.pragmaticprogrammer.com/p...s/1998_05.html[/color]
Read something very similar to it before...
[color=blue]
> Now i'm not telling that getter/setter are a Bad Thing by themselves,
> just that you should make a distinction between what is the class
> 'Knowledge Responsability' (ie : what client code is entitled to ask the
> class) and what is in fact internal state. If you happen to query the
> object about it's internal state just in order to decide what you're
> going to tell him to do next, then you've broken encapsulation, and
> you'd better fix your code right now. One important rule here is that
> you never should bother about the internal state of an object before
> sending him a message.[/color]
<sic>Next time I won't bother with illustrative examples, I'll just talk
in ways that will confuse the poor OP more and eventually have them give
up on OOP so the rest of us can keep our share...</sic>
Don't read into examples like this just to prove you have a superior
intellect - it turns ppl off.
--
Justin Koivisto -
spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.
Official Google SERPs SEO Competition:
http://www.koivi.com/serps.php 
