You might have seen all of my recent discussion questions here on CF, and forgive me. I've been watching video after video (lynda) to learn as much as I can about the PHP language and testing it on my own with prior knowledge... Which leads me to this question.
I've been working with Java/C++ so all I've know up to this point is OOP. Starting with PHP was interesting since I didn't have all that header code, just a few brackets. I've gotten to the chapter on OO PHP and I'm trying to decide when I would use it. I'm beginning to ask myself when I should use OO PHP and when I should just stick with procedural?
I've googled this question and it seems I'm getting a lot of people asking "Procedural vs oop" and I find that completely bogus. I believe each method is used to solve different problems, and so this isn't a question asking for a comparison, but I'm rather trying to grasp when I would use one over the other. Thanks!
As you may have understood after reading different threads with people discussing this it's not really possible to give a simple answer to your question. I think the best method of getting the hang of when to use which way of programming is to really just try both the methods yourself in different programs. After a while you'll know how both ways work and in which way you personally prefer solving different problems.
...I've googled this question and it seems I'm getting a lot of people asking "Procedural vs oop" and I find that completely bogus. I believe each method is used to solve different problems, and so this isn't a question asking for a comparison, but I'm rather trying to grasp when I would use one over the other. Thanks!
Yeah, people are fighting the wrong battle there , its NOT a question of proc vs OO in PHP since neither is better than the other at any particular task and its pointless to even compare them that way.
e.g. there is no single task (that I am aware of) that OO can do that procedural can not (apart from the obvious OO related stuff like reflection etc which you wont need unless you are using OO in the first place)
The only time that one may appear 'better' than the other is when you start to scale, at that point OO code is probably easier to manage but procedural code will have the edge on speed (ignoring external optimization)
The real question is which OO ? I use OO a lot in PHP, but Fou-Lou might not call my code 'true' OO, more a collection of objects that sometimes talk to each other..
I might look at Fou-Lou's code and (with ALL RESPECT) suggest that his approach seems better suited to Java than to PHP and that the overhead of a Java type implementation in PHP defeats the purpose of using PHP in the first place.
+I am not a fan of MVC as applied to the simple web.
So there are all different levels of OO usage in PHP, from
procedural no objects,
procedural code using PHP' built in OO interface for some functionality (mysqli etc)
procedural code using some home grown objects for specific tasks
my style of ...all OO but not as Java would know it
the full MVC Java-stack style stuff
and there are probably many levels in between !
Many will say that this is confusing, they are not wrong, but its a trade-off of initial confusion over the incredible flexibility that PHP affords, and for that purpose suits me down to the ground.
MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)
The Following 2 Users Say Thank You to firepages For This Useful Post:
@ firepages post: I've seen it mentioned that PHP isn't a "true" OO language. I have no idea, since it's the only programming language I've used, and I've only known what OO is for a few weeks. Still, all I've really seen of PHP-OO seems to be "objects" containing procedural code in the methods. Can PHP even hold a candle to the OO in languages like Java? I'd be interested to see what magic Fou-Lu does if he isn't using procedural in his objects..
Last edited by Custard7A; 11-24-2012 at 12:46 PM..
Can PHP even hold a candle to the OO in languages like Java?
Probably not, but whilst Java is loading the object hierarchy for wax to overload the candle PHP has pulled 20 of then from the DB lit then and stuck them in a chandelier in the pattern of your choice
For years its been noted that PHP OO does not have, this that or the other... overloading, abstracts, interfaces all jump to mind, we have those now , namespaces etc + the old multiple inheritance question which no one can agree on in any language
Fou-Lou can I am sure give more specifics about what is missing in the PHP implementation vs other languages, he has a far broader knowledge than most here.
But whilst PHP allows loose/weak typing then its probably not going to be considered capable of being a 'true' OO language.
Though Wikipedia says this...
Quote:
Originally Posted by http://en.wikipedia.org/wiki/Object-based_language
Object-based languages that do not support inheritance or subtyping are usually not considered to be true object-oriented languages
So it depends on the definition of 'true' OO , PHP passes the above test?
MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)
Still, all I've really seen of PHP-OO seems to be "objects" containing procedural code in the methods.
As opposed to what?
Quote:
Originally Posted by firepages
For years its been noted that PHP OO does not have, this that or the other... overloading, abstracts, interfaces all jump to mind, we have those now , namespaces etc + the old multiple inheritance question which no one can agree on in any language
PHP has overloading?
------------
From what I've seen of PHP OO, it seems fairly strong. Sure, it's missing some things but one of the core advantages remains: reusability. I think it's also more legible at times as well. As far as slugging the system, I don't think PHP OO compares to Java in that manner at all. You write objects and methods that you will need, not use a database like Java's.
No, the overloading in PHP is limited explicitly to the magic methods (__set, __get, etc). The best we can do with the overload is via exploiting the namespaces, but that still doesn't apply to objects only to main level functions. Of course that isn't overloading, but at least we can make procedural code with our own names now (like count()). It support full override, but overload is still beyond PHP's capability (and always will be since they've always governed using optional arguments instead of explicit). With the datatype weakness, even with the typehinting, I can't see ever getting full overloads.
One I wished we could do is generics. Its a pity that we cannot, but at the same time writing an extension to an existing collection and adding the verification needed (via a callback would be easiest) would be quite simple. Once again goes hand in hand with the datatype weakness. Another I would like is checked exceptions, but once again since PHP is datatype weak, even the exceptions cannot be dereferenced to a type until runtime, so checked wouldn't work. Pity.
As for objects being just methods containing procedural code, yeah that's exactly what they are. You still need to process the logic, but the objects are a container; the paradigm itself is completely different in how its accessed and used versus procedural.
As for my PHP OO programming approach, yes it is very much like java. In fact, I learned the PHP OO development by applying my java knowledge translated directly into PHP code; at the time it wasn't as easy as it is now since that was early 5.0 generation PHP. I even model my PHP API interfaces off of the Java core API (almost literally, same method names, usually the same signatures). Stuck with doing it that way since.
No, the overloading in PHP is limited explicitly to the magic methods (__set, __get, etc). The best we can do with the overload is via exploiting the namespaces, but that still doesn't apply to objects only to main level functions. Of course that isn't overloading, but at least we can make procedural code with our own names now (like count()). It support full override, but overload is still beyond PHP's capability (and always will be since they've always governed using optional arguments instead of explicit). With the datatype weakness, even with the typehinting, I can't see ever getting full overloads.
DOH, sorry, I guess __set and __get are not true overloading.
Quote:
Originally Posted by http://php.net/manual/en/language.oop5.overloading.php
PHP's interpretation of "overloading" is different than most object oriented languages. Overloading traditionally provides the ability to have multiple methods with the same name but different quantities and types of arguments.
MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)
I don't know. Firepages said something about "full MVC Java-stack style stuff". I thought maybe the criticism about PHP's OO was related to it having always procedural in it.
It doesn't matter to me how "true" PHP-OO is, doesn't make me like it less.
I think PHP OO is the easiest way of setting up a larger project. If you're only using some PHP in a website, it's quicker to do it procedural style.
That being said, on a larger project OO is definitely worth the extra time-investment at the start, as it makes handling objects (whether it being a blog-post, shopping cart or whatever) so much easier once defined as an object. It also makes code more readable IMHO. I've just rewritten a procedural style function call in a page to an object, which changed my pages code from
I rarely use procedural style any more when OO gives me a clearer view on the matter. It's still a programmers choice though and I suppose you should go with what you're comfortable with.
I think PHP OO is the easiest way of setting up a larger project. If you're only using some PHP in a website, it's quicker to do it procedural style.
That being said, on a larger project OO is definitely worth the extra time-investment at the start, as it makes handling objects (whether it being a blog-post, shopping cart or whatever) so much easier once defined as an object. It also makes code more readable IMHO. I've just rewritten a procedural style function call in a page to an object, which changed my pages code from
I rarely use procedural style any more when OO gives me a clearer view on the matter. It's still a programmers choice though and I suppose you should go with what you're comfortable with.
Very cool. Can you pass objects to and from a database? Or do you store each variable.
Very cool. Can you pass objects to and from a database? Or do you store each variable.
You can't store an object as such in a database (not as far as I'm aware anyway), but my first port of call is usually create a Class for every database-table.
So if I have a table 'comments' in my database with an ID, commenter, comment, original_post and time_posted, I'd start by programming a PHP class with $id, $commenter, $comment, $original_post and $time_posted and load these with a query in $comment->get_data(). That way, any changes made to the comment during the life time, can be saved easily by calling $comment->store_data(), which UPDATES the db with the current $this variables.
So it would look like this:
PHP Code:
function get_data() {
$sql = "SELECT * FROM comments WHERE id='{$this->id}';";
$result = $this->query($sql);
while($r = $result->fetch_assoc()) {
$this->id = $r['id']
[...]
}
}
function set_data() {
$sql = "UPDATE comments SET commenter='{$this->commenter}' [..] WHERE id='{$this->id}';
$this->query($sql);
}
On the front end, the only thing you'll have to do is something like this.
PHP Code:
$comment = new Comment();
$comment->id = 1;
$comment->get_data(); // You could combine these by using $comment->get_data(1), obviously build in an if statement in get_data checking if $id is set or something)
$comment->commenter = 'Martin';
$comment->set_data();
Okay, granted, a bit useless for this particular example, but with an object with 20 variables or something it really pays off
That's a good point Thyrosis. It's often said how OO will make handling a large project easier, but it's also just great for clear and intuitive code.
I've been playing around with structuring myself. The below kind of deal would use autoloading, static properties (not featured: methods), and __construct as pillars.
PHP Code:
<?php new assets("page"); ?>
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta charset="utf-8">
<title> Page </title>
</head>
<body>
<p> Hello World! </p>
<p> .. or rather, <?php echo user::$name; ?> </p>
</body>
</html>
Emphasis on "playing around", although I'm quite interested in the whole affair.
You can't store an object as such in a database (not as far as I'm aware anyway), but my first port of call is usually create a Class for every database-table.
You could through serialization however I would say you should almost never do it. It defeats the entire purpose of a relational database.
Quote:
Originally Posted by Thyrosis
So it would look like this:
PHP Code:
function get_data() {
$sql = "SELECT * FROM comments WHERE id='{$this->id}';";
$result = $this->query($sql);
while($r = $result->fetch_assoc()) {
$this->id = $r['id']
[...]
}
}
function set_data() {
$sql = "UPDATE comments SET commenter='{$this->commenter}' [..] WHERE id='{$this->id}';
$this->query($sql);
}
On the front end, the only thing you'll have to do is something like this.
PHP Code:
$comment = new Comment();
$comment->id = 1;
$comment->get_data(); // You could combine these by using $comment->get_data(1), obviously build in an if statement in get_data checking if $id is set or something)
$comment->commenter = 'Martin';
$comment->set_data();
Okay, granted, a bit useless for this particular example, but with an object with 20 variables or something it really pays off
So do you validate the data as part of the class before the set_data call? E.g. to be sure the values don't contain an SQL injection attack?
---------------------------------------
As firepages has said earlier, OOP is a tool, the trick is to know when to use it and how to use it effectively. When you get into OOP it can be easy to object orientate yourself into a corner. You either under or over design your objects or worse start to create an inner platform effect with your software.
So do you validate the data as part of the class before the set_data call? E.g. to be sure the values don't contain an SQL injection attack?
Yes, good point. Obviously all user input is validated and checked on multiple levels, including SQL injection, size, duplication and the sort. I thought that would exceed the scope of this example, that's why I didn't include it.
Quote:
That's a good point Thyrosis. It's often said how OO will make handling a large project easier, but it's also just great for clear and intuitive code.
I've been playing around with structuring myself. The below kind of deal would use autoloading, static properties (not featured: methods), and __construct as pillars.
PHP Code:
PHP Code:
<?php new assets("page"); ?>
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta charset="utf-8">
<title> Page </title>
</head>
<body>
<p> Hello World! </p>
<p> .. or rather, <?php echo user::$name; ?> </p>
</body>
</html>
Emphasis on "playing around", although I'm quite interested in the whole affair.
I'm currently working on a small-scale CMS for a client, who will have different pages in different languages. Hence my table pages has a language attribute. This would make your line of code look something like
PHP Code:
<html lang="{$page->lang}" dir="ltr">
I don't actually know whether it would make a difference at all to the search engines and all that, but I thought it was pretty cool
Saying that, you could load a blog post into a class and have $post->comments filled with an array of comment objects... I think? Can you load objects into an array at all?
Before you post, read our: 
