|
Posted by Simon Dean on 08/16/06 14:12
mootmail-googlegroups@yahoo.com wrote:
> 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.
You won't believe this, but that's exactly what I was thinking. Thinking
more than 2 dimensionally too, there's no reason, if I want to tidy
things up, that I can't have say a Login class that then relies upon the
Password and Session class. The Login process, by definition, validates
the passwords and creates the session, but that Password and Session can
remain separate.
>
[snip my celebrity stuff]
>>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?
You're reading my mind. Yes, i want to expand this beyond just
Celebrities. And I want this to be more than just actors and actresses.
So the next logical conclusion, is music, musicians, so I want a band
website at some stage with lists of their CD's, all intermingled but
subtly separated.
Mind you, I've been talking about doing that for several years.
Part of the issue for me, is that I need to produce a different menu
structure, depending on what the user is doing. So the class needs to
know whether a user is logged in, whether they have admin rights, if
they are looking at a celebrity, or a band, or a film, I need to present
a list of associated links, whether it's "CD Releases and Band Members",
or "Filmography and Biography". etc.
Currently I generate the menu in the Open Page functionand then I
generate a path >> Celebrity Researcher > Administrator > Geddy Lee >
Biography (for example), and build the appropriate menu.
But I guess if this is all split out, there's no reason why I can't say
new Page(Title);
BuildMenu($LoggedIn, $Administrator, $CelebrityPage, $CelebrityName);
AddPath("SomePath");
OpenPage();
Of course, where I had one line of code originally, OpenPage();, I now
stand to get four at least.
> 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.
>
Or there is this I guess :-p
So that would be used for maybe interacting with the Celebrity Class I
have, or the Papparzi class as you rightly say.
Thanks for your help.
Simon
Navigation:
[Reply to this message]
|