Note: If this is the wrong place to post this I'm sorry.
Guys,
Recently I've been reading a book by APress (Objects, Pattern and Design) and it's really opening my eyes on the benefits of PHP 5's new OOP model. I can't help but think that maybe PHP 5 still has room to grow. With that being said, I wonder just how much PHP 6 will really impact and matter when/if it is released in the future. I'm really afraid of PHP 6 being released just for the sake of releasing a new version basically.
Anyways, the true menaing of this post is a series of serious questions that I'm still unsure about (mainly because I haven't reached it in the book, so the anticipation is getting to me quicker than I can read). My concerns are with the advantages of cloning classes, Abstract classes, overloading classes, and interfaces. What are the true benefits of such things in OOP? Why would I use them, and better yet, where would be ideal usages for them?
The reason I ask is 2 fold: I'm coming from the PHP 4 age where we didn't have a true OOP so we designed around that fact, making classes just for reuse and not so much for true OOP. How is using true OOP going to benefit the developer who comes in with this mentality? Why would we use the above methods if we already know how to get by without them. It just feels like they are avaiable to satisfy true OOP design, but how does it really help with speed and reusability?
Is this somehting I'm just going to have to learn and understand on my own?
Thanks.
To PHP 5 and Beyond - Understanding OOP
Moderator: General Moderators
- jimthunderbird
- Forum Contributor
- Posts: 147
- Joined: Tue Jul 04, 2006 3:59 am
- Location: San Francisco, CA
Re: To PHP 5 and Beyond - Understanding OOP
I think OO is more than just writing classes in a language, it's more like a philosophy, a mindset.
OO can be achieved with a language without the support of class structure.
One good example I think is the Drupal Core, it tries to achieve OO without using class structure, and it's sort of elegant too.
All being said, there's an old article if you are interested, http://www.geocities.com/tablizer/oopbad.htm, maybe too strong, but I think as a developer, I will just be water, be flexible, since programming philosophy is more important than a programming language.
Best Regards,
Jim
OO can be achieved with a language without the support of class structure.
One good example I think is the Drupal Core, it tries to achieve OO without using class structure, and it's sort of elegant too.
All being said, there's an old article if you are interested, http://www.geocities.com/tablizer/oopbad.htm, maybe too strong, but I think as a developer, I will just be water, be flexible, since programming philosophy is more important than a programming language.
Best Regards,
Jim
Re: To PHP 5 and Beyond - Understanding OOP
An abstract class is a superclass which isn't meant to be instantiated because it's not complete. The missing bits are (usually) defined as abstract methods. These are empty placeholders which derived classes - concrete implementations - will implement (Strategy).infolock wrote:My concerns are with the advantages of cloning classes, Abstract classes, overloading classes, and interfaces. What are the true benefits of such things in OOP?
You might create an abstract class if you find several other classes which have some common functionality but a part of this is implemented in different ways - eg the validate method in the phppatterns example. The shared stuff would be refactored into an abstract class leaving the unique bits in the concrete classes. Since you get the base functionality "for free", it's easy for programmers to add new concrete implementations. All they have to do is implement a method or two; they don't have to figure out how the class plugs in to the design as a whole.
Essentially, the abstract keyword is just documentation. This would work just as well:
Code: Select all
/* abstract
*/
class Foo {
...
...some common functionality...
...
function bar() {
// abstract
}
}
An interface announces the fact that you've got lots of different classes which do the same thing in different ways. For example, a Database interface with query(), ping(), etc could be implemented by a MysqlDatabase, a PostgresqlDatabase, and so on. Defining an interface defines the API via which these objects provide their services. Used like this, interfaces are basically just documentation: you've still got the common API whether the interface exists or not. Although you want to avoid documentation and comments as far as possible in this case I do think interfaces can be useful.
Another use for interfaces is dependency injection. A DI container like Phemto uses type hints and reflection to figure out how to fill dependencies. The hints don't have to be interfaces but these are often the best thing to hint on since the client code ends up depending on an interface rather than a specific implementation.
Overloading. As a rule, I'd ignore __get and __set. You shouldn't access properties directly but only via an interface. One nice use for __call is when you are decorating objects by aggregation. Saves tediously having to chain together all the decorated object's public methods to namesakes in the decorator:
Code: Select all
class Foo {
function __construct($bar {
$this->_bar = $bar;
}
function __call($method, $args) {
return call_user_func_array(
array($this->_bar, $method),
$args);
}
...
...
...
}
Code: Select all
The reason I ask is 2 fold: I'm coming from the PHP 4 age where we didn't have a true OOPI'm actually quite worried about where the php devs will go with the language. I don't think they are sophisticated OOP programmers.
Re: To PHP 5 and Beyond - Understanding OOP
McGruff,
As always man, thanks a lot for your intelligent insight on this. Your response was exactly what I was looking for. I too worry that most of the PHP devs (including myself!) are not very OOP oriented, and it's both our fault and PHP's (but only in a way). The reason I say PHP does play a little part of it is because we learned PHP based on what was given to us. While PHP 4 did allow OOP, I do not agree that it can be considered to have given us a true OOP environment since Objects and values were passed via arrays/copies instead of true references as they are in PHP 5+.
Either way, I think the new way of OOP in PHP 5 is truely what is making a lot of developers go to it so slowly, and it's mainly due to being over burdened with having to learn to do OOP the correct way, not the way PHP 4 taught us.
Thanks for the great response! It's exactly what I was hoping to hear/learn!
As always man, thanks a lot for your intelligent insight on this. Your response was exactly what I was looking for. I too worry that most of the PHP devs (including myself!) are not very OOP oriented, and it's both our fault and PHP's (but only in a way). The reason I say PHP does play a little part of it is because we learned PHP based on what was given to us. While PHP 4 did allow OOP, I do not agree that it can be considered to have given us a true OOP environment since Objects and values were passed via arrays/copies instead of true references as they are in PHP 5+.
Either way, I think the new way of OOP in PHP 5 is truely what is making a lot of developers go to it so slowly, and it's mainly due to being over burdened with having to learn to do OOP the correct way, not the way PHP 4 taught us.
Thanks for the great response! It's exactly what I was hoping to hear/learn!