Jump to content


Photo

Question about OOP and PHP


  • Please log in to reply
5 replies to this topic

#1 Joe Haley

Joe Haley
  • Members
  • PipPipPip
  • Advanced Member
  • 103 posts
  • LocationCanada, eh?

Posted 16 July 2006 - 10:59 AM

Im wondering where to draw the line of "make it its own object / class"

Like with the user system im making:

Got your class "user", with propertys to define things like his username, and methods to do things like log him in and out.
Should password be its own class? (as one wants to encrypt and compare passwords, and functions would be the way to go for that.)

How much overhead is created by making nearly everything into objects? (for the purposes of abstraction, and a fancy "OOP PHP Programer" on the ol' resume)

Is it worth, in your oppinion, to do such things?
Give a man a fish; you have fed him for today.  Teach a man to fish; and you have fed him for a lifetime
Don't teach men to program. Teach them to fish.

Please, try the RTFM solution before asking for help:
http://php.net/manual/en/index.php

#2 hvle

hvle
  • Members
  • PipPipPip
  • Advanced Member
  • 667 posts
  • Locationmelbourne, Australia

Posted 16 July 2006 - 11:17 AM

is there a good reason why should you concern about this issue?
it's a script, run and exit, load and unload.  Memory is not a big issue.
Life's too short for arguing.

#3 Joe Haley

Joe Haley
  • Members
  • PipPipPip
  • Advanced Member
  • 103 posts
  • LocationCanada, eh?

Posted 16 July 2006 - 11:21 AM

Memory isnt so much an issue as the time it takes the compiler to deal with objects as opposed to variables. (small, i know. But stuff adds up...)

And beyond the overhead, look at it from a design standpoint.

(im relativly new to complex system design)
Give a man a fish; you have fed him for today.  Teach a man to fish; and you have fed him for a lifetime
Don't teach men to program. Teach them to fish.

Please, try the RTFM solution before asking for help:
http://php.net/manual/en/index.php

#4 hvle

hvle
  • Members
  • PipPipPip
  • Advanced Member
  • 667 posts
  • Locationmelbourne, Australia

Posted 16 July 2006 - 11:38 AM

first of all, this user object is store in server, via session, so, user had no way to access this object.  Suppose the password is a member var of this user class, the password should already encrypted.  I don't see any reason to make an own class for password.

Life's too short for arguing.

#5 Joe Haley

Joe Haley
  • Members
  • PipPipPip
  • Advanced Member
  • 103 posts
  • LocationCanada, eh?

Posted 16 July 2006 - 11:43 AM

Yes, but where would one stick the functions to encrypt and compare a password?

And its not just this specifically, its generally. Is there some sort of rule of thumb, or just mess with it till it works and still makes sense? x)
Give a man a fish; you have fed him for today.  Teach a man to fish; and you have fed him for a lifetime
Don't teach men to program. Teach them to fish.

Please, try the RTFM solution before asking for help:
http://php.net/manual/en/index.php

#6 hvle

hvle
  • Members
  • PipPipPip
  • Advanced Member
  • 667 posts
  • Locationmelbourne, Australia

Posted 16 July 2006 - 11:54 AM

If you're familiar with OOP, it'll just be very similar in PHP.

you can create a member function for user class to compare the password.
yeah, you have to went thru the same encryption mechanism.  Normally, we used md5 hashing.  If you still feel unsecure with md5, you can add a salt.  Yes, PHP took care most of the complex works.


Life's too short for arguing.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users