Object Oriented Programming in PHP

Posted by That Guy, 03-19-2007, 11:03 PM
Why? I want to make a login script, but I'm not sure if I should make it with PHP. What are the advantages/disadvantages? Thanks!

Posted by ak7861, 03-20-2007, 02:23 AM
Advantage/Disadvantages making a login script in PHP? All are the same. With php you can use session_register() and $_SESSION variables to authenticate. http://us3.php.net/session_register

Posted by Engelmacher, 03-20-2007, 05:18 AM
PHP has quite possibly the worst OOP implementation of any language. That being said, there is not much reason to use any advanced OOP methodologies in a login script.

Posted by bleenzorb, 03-20-2007, 06:37 AM
Right. But I'm glad PHP does have a few oop features. Some of the developers/documenters of the PHP language realize it isn't very object oriented, but others apparently (and mistakenly) think it is. Here are two excerpts from the PHP manual. In the first quote, I'm not sure how they can say what they say when PHP supports neither function overloading nor polymorphism, among other things: "PHP 5 fixes the OOP related weaknesses of PHP 4, and introduces a complete object model." ...then there's this, more reasonable, quote: "Comparing objects In PHP 5, object comparison is more complicated than in PHP 4 and more in accordance to what one will expect from an Object Oriented Language (not that PHP 5 is such a language)."

Posted by maxymizer, 03-20-2007, 10:19 AM
There are basic means for reusability, inheritance and encapsulation in both php4 and php5. If you just happen to adore to use every possible function / OOP method in your script then you have a different sort of problem and it's not of technical nature. Regarding login script, there exist scripts that are 10-15 lines of code and are used for logging in / logging out. It all depends on the all features you want to employ and you haven't given enough info about that. If you know PHP, go with it. If you know another serverside language, go with that one. Simple as that.

Posted by Renard Fin, 03-20-2007, 02:32 PM
Please note that session_register is *NOT* encouraged since PHP 4.1.0 you have to use $_SESSION. Since register_global is off by default, and if register_global is off, session_register will not work at all. Note as well that register_global will totally not work as PHP 6.0.0 as register_global will be retired.

Posted by cywkevin, 03-20-2007, 03:52 PM
PHP 6 seems to be adopting better OOP implementation. OO changes: Static Binding A new keyword will be created to allow for late static binding - static:tatic2(), this will perform runtime evaluation of statics. Namespaces It looks like this one is still undecided - if they do implement namespaces it will be using their style only. My advice? Don't hold your breath! Type-hinted Return Values Although they decided against allowing type-hinted properties (becaue it's "not the PHP way") they will add support for type-hinted return values, but have yet to decide on a syntax for this. Even so, it will be a nice addition. Calling dynamic functions as static will E_FATAL At the moment you can call both static and dynamic methods, whether they are static or not. Calling a dynamic function with the static call syntax will raise an E_FATAL. The non-compatible changes are probably going to make php 6 a niche market for a couple of years. I am excited about the removal of register_globals. That's been encouraging bad code for far too long. Last edited by cywkevin; 03-20-2007 at 04:03 PM.

Posted by ak7861, 03-21-2007, 09:05 PM
Good joke. I'm using PHP 5.2 and all hundreds of my sites use session_register with register_globals off.

Posted by Renard Fin, 03-21-2007, 10:42 PM
Up to you to use best practices or poor code. From PHP.NET: AND http://ca.php.net/manual/en/function...n-register.php I dont think it is documented just for the fun of it.

Posted by That Guy, 03-22-2007, 02:55 PM
Thanks guys. So what I got from all these replies is this: If I plan on upgrading to 6.0 anytime soon, OOP wouldn't be too bad but otherwise I should just go with imperative programming. Right?

Posted by maxymizer, 03-23-2007, 06:40 AM
If you find this: more readable and intuitive than: then go with procedural way. Don't listen to all advices, especially the ones that advise you against OO just because php compared to other languages apparently loses. That's not true and OO wasn't invented so you use absolutely every possible feature that it offers. For logging in / logging out, you can create a (OO) script within 50 lines of code, it's easier to maintain and extend it when necessary.

Posted by Renard Fin, 03-23-2007, 07:35 AM
Yep but something you forgot maxymizer is by doing the procedural way user_is_logged_in() you have to use global vars, which is far from being the best to manage your code. You then loose the structure & good practices. By the way if I am not wrong, when you cast the function user_login(&$username, &$password) you have to typecast the reference in the declaration not when you call the function. (but I may be wrong !).

Posted by maxymizer, 03-23-2007, 09:47 AM
I didn't want to go in-depth in procedural vs oo, the example was to show the most basic difference and yes, it's a good observation - you have to use global vars in procedural way. Regarding references when calling the function, it's just a practice that I'm used to. I use references when calling and declaring the function. As I said, PHP (even version 4) has the basic means for OO - reusability, encapsulation and inheritance and that's more than enough for a simple login script.

Posted by Burhan, 03-23-2007, 11:35 AM
For a login script, you will not see any advantages if you go with procedural or object based programming; unless you have an established backend that is using objects. Just going OO without really understanding its benefits is not going to gain you any speed or performance.

Posted by That Guy, 03-23-2007, 05:25 PM
Hm....thanks guys. To be honest I want to create one login script that I can use for more than one large project so I don't have to create a login script for each one.

Posted by feedsfarm, 03-25-2007, 11:25 AM
How about this in OOP:

Posted by maxymizer, 03-25-2007, 01:04 PM
sigh* I didn't try to discuss the method that should be used, but for multiple user logins with your script you need to create multiple objects.

Posted by karlkatzke, 03-25-2007, 04:14 PM
Huh? Why would he need to create multiple objects if he has multiple users logging in? The object would always be created at the user's runtime and would pull info from the user's session, and would take on the properties of that user -- just like every other user authentication / login object... objects don't persist between pageloads unless you serialize them and store them somewhere.

Posted by maxymizer, 03-25-2007, 05:42 PM
If you use one class for logging in various types of user and if you require multiple logins (I have a project where I require that), wouldn't it be easier if you invoked a member twice instead of creating a same object just to pass 2 different combinations of usernames and passwords?

Posted by feedsfarm, 03-25-2007, 06:24 PM
Make a static class then. authentication::login('user', 'password'); In the class: public static $users = array(); Which would be ammended like so: public function login($user, $pass) { if ( SIMPLE CHECK HERE ) { self::$users[$user] = true; } } Then in the rest of the scripts: if (authentication::$users['feedsfarm']) { // laddi daddi da }

Posted by maxymizer, 03-25-2007, 07:13 PM
Why? I already posted what I consider more readable and easier. It's a member function that takes 2 arguments and logs you in. I never use any "static" classes, it beats the purpose of OO and is the same thing as procedural code. It's only that your code looks more "leet" because of the usage of scope resolution operator. I think I'll skip that and stick to what's proven to be working just fine for about every single person I work with on daily basis.

Posted by feedsfarm, 03-25-2007, 07:23 PM
Benefits are modularity and the ability to inherit the authentication class via other classes.

Posted by karlkatzke, 03-25-2007, 08:01 PM
I was just going to say. You create a static class, and then you inherit that static class so that you don't have to write procedural code to process the other logins.

Posted by maxymizer, 03-25-2007, 08:25 PM
Which is also achievable without creating static class. The topic went the other way, I was referring to your initial example where you passed user login info to the constructor and completely ignored the use of other members and then you mentioned static class. It can all be done without the use of static class and without passing parameters to the constructor, but to a member that's responsible for logging someone in. It also comes down to preferences - if you find using static class easier - that's up to you. For me it has no advantages.

Posted by That Guy, 03-26-2007, 02:47 PM
Read up a bit more on PHP OOP and I've decided to use it. Thanks guys.

Cette réponse était-elle pertinente?

 Imprimer cet article

Consultez aussi

Lots of dedicated server problems.

Posted by erix920, 05-07-2007, 08:26 PMOur current problem is that when we try to start sshd...

Trojan detected on initial load of site

Posted by geekie246, 01-08-2008, 02:10 PMHi. I have 2 reseller accounts with one provider, and...

CMS for File Management?

Posted by Sammy89, 02-18-2011, 05:27 PMis there a php app out there that allows you up...

how protection upload from members {jpg-gif-png} only ?

Posted by 3okl, 09-18-2008, 07:06 PMif member have none photo the uploader start upload anyfile...

Alorithm help

Posted by Red_wolf6, 03-07-2010, 04:41 PMHello, I have a Question - I couldn't solved it...