|
|
Posted by mootmail-googlegroups on 08/16/06 12:53
Simon Dean wrote:
> I've created a Password class that can do:
>
> function Validate($pLogin, $pPassword) {
> function MailPassword($pLogin, $pPassword, $pEmail) {
> function GeneratePassword() {
> function ResetPassword($pLogin, $pEmail) {
>
> But then I had the validate function, and I was wondering whether
> Session creation should be called from the Validate function, passing
> the Session object back, or just have the calling program Create a
> Session Object.
Classes give you the flexibility and power to create very specialized
components which can be combined to make a complete system. Think of
them as Legos. You have a 2x2 blue piece, and a 4x2 red piece, put
them together with a few others, and voila...you have a Tie Fighter.
But if they made a one-piece Tie Fighter Lego piece, what are you going
to do with it other than make a Tie Fighter...make two?
Keep your classes as independent as possible. You may, some time down
the road, want to reuse your password class in another project which
may not use the Session. Your Validate function should do one thing:
Validate. Let some code call it, get a yes or a no, and then figure
out what to do with the result itself.
>
> So then I find a situation say with Opening a Page, where dependant upon
> whether Im looking at an item, or say, whether the user is logged in or
> not (ie we have a session object set), we want to do something
> different, So I was working on:
>
> <?
>
> Class Celebrity {
>
>
> var $DName;
> var $DAge;
>
> function Celebrity() {
> }
> }
>
> Class Page {
> var $Celebrity;
>
> function Page() {
> }
>
> function Open() {
> if(isset($this->Celebrity)) {
> echo "Celebrity is set as " . $this->Celebrity->DName;
> }
> else {
> echo "No celebrity is set";
> }
> }
> }
>
> This way, my Page class can get all the information it needs from the
> Celebrity object while generating a page, and it's easy to expand upon.
> Though it is reliant upon another class? I did the same thing with a
> Session object, so I could tell it to construct a different menu, and
> even present the name of the user from the session object for example.
>
> Or perhaps it IS better, just to work out what information I actually
> need, and just pass that across on function parameters?
>
> Which way is right?
>
Again, there is no "right" way to do it. Classes can include/rely
upon/use other classes. That kind of thing happens all the time. I
would hesitate to use the design you mentioned, though, with your Page
class. Is every single page in your project going to need a Celebrity
object? If the answer is 'yes', it probably won't be for long. And
what happens when you want to do another project and you have to
rewrite your Page class to get rid of the Celebrity stuff? A much
cleaner design, in my opinion, would be to restrict your Page class to
only functions dealing with a generic page (validating the user, etc).
You can then create a CelebrityPage class which inherits from the Page
class and add in all of your specific code there. That way, to the
application, CelebrityPage acts as expected, but if somewhere down the
line you need to create a PaparazziPage, you won't have to rewrite the
generic page functionality...only the specific code.
Navigation:
[Reply to this message]
|