Great OOP Tutorial
Moderator: General Moderators
- protokol
- Forum Contributor
- Posts: 353
- Joined: Fri Jun 21, 2002 7:00 pm
- Location: Cleveland, OH
- Contact:
Great OOP Tutorial
Today I have run across an excellent tutorial explaining the theory of OOP as well as providing very good examples of its uses.
I HIGHLY recommend reading it and learning more about OOP in PHP
Doing it with class: Using OOP in PHP http://www.sdphp.net/talks/sdphp_class
I HIGHLY recommend reading it and learning more about OOP in PHP
Doing it with class: Using OOP in PHP http://www.sdphp.net/talks/sdphp_class
that's definitely a good intro to OOP, but i am reminded of what Tim Perdue said in regards to using OOP...
i tend to agree with him.
for those who don't know Tim, he is the owner of PHPBuilder, but more importantly the system architect and one of the original founders of SourceForge.Date: 07/28/00 02:21
I think it was just an example - personally I do not use objects in PHP. I think there's too much overhead in a web environment. I mean you have to set up all these vars, instantiate the objects, etc and then it is all destroyed at the end of the page generation.
OO makes a lot of sense in a traditional application, but I don't personally use it on the web. Others will disagree...
i tend to agree with him.
- protokol
- Forum Contributor
- Posts: 353
- Joined: Fri Jun 21, 2002 7:00 pm
- Location: Cleveland, OH
- Contact:
Well, actually, OOP is easier to work with for many reasons. Thinking in an OO manner makes everyone's life a lot easier. I know that I have saved hours in programming time because I used an OO method as opposed to straight functions and passing variables, etc.
And also, if you are storing objects in a $_SESSION variable (using serialize() and unserialize() also) then you aren't creating a new instance of an object each time a script is called. You are simply accessing the object that was created the 1st time and is stored between pages.
So, sorry, but I disagree with you.
And also, if you are storing objects in a $_SESSION variable (using serialize() and unserialize() also) then you aren't creating a new instance of an object each time a script is called. You are simply accessing the object that was created the 1st time and is stored between pages.
So, sorry, but I disagree with you.
oh it's definitely a powerful way of coding and I love using it (Java and I are good friends
), but i just find very few web applications that justify all the overhead that it comes with.... although as web applications gradually become more and more complex and powerful (the whole .NET idea), i think OOP may be one of the only ways to efficiently do the required tasks.... it's just that we're not there yet.
- twigletmac
- Her Royal Site Adminness
- Posts: 5371
- Joined: Tue Apr 23, 2002 2:21 am
- Location: Essex, UK
Doh!
I always wonder if comments made 2 years ago still hold true![]()
And that's a very good point!
Additionally, in a community such as this one, where code and examples of
code are distributed very freely, classes make a ton of sense. It makes for extremely
elegeant coding and eases the process (depending on how well an interface is
designed) of integrating elsewhere developed hunks of code into a system
under development.
But it's use by some has been pure overkill. I think Pear is a perfect example of this.
Just becuase we can OOP doesn't mean we should ALL THE TIME. Some of the
classes created by Pear are HUGE! The question then becomes what percentage of an
objects given number of methods are going to be used at each instantiation? If you have a class with 30 methods (or member functions), but on average, you only use one or two,
then the object should be broken down into smaller objects, if possible.
This is analagous to the CISC vs RISC arg with CPU's. First generation (P5) Pentuims (as an example) were considered CISC (complex instruction set) processors. The RISC (Reduced Instruction Set) crowd said, "Why have all these seldom used esoteric instructions?" So, the number of instructions were reduced and the instruction length made uniform. For dealing with those old comeplex, seldom used instructions, it was found that a series of simple instructions could do the same thing, AND FASTER. Now, Intel and AMD still chew on the same X86 code, but use RISC cores as they saw the logic of the argument.
Perhaps we should think the same way. Why slow down the system and allocate memory that isn't going to be used by using these huge classes?
However, why throw out the use of classes all together. Small (!) connection objects, query objects, iterator objects, pagination objects, can work extremeley well and with very little overhead as well as tremendously easing developement.
What do you think?
Later on,
BDKR (TRC)
generally, i would agree with you. but in this case, everything he mentioned is still overhead accompanying OOP.... it's just the way it works. such concepts are fundamental to the paradigm, and won't ever change in 2 years or 200 years.twigletmac wrote:I always wonder if comments made 2 years ago still hold true
A Tim Perdue addendum
One more thing. Tim doesn't own or run PHP Builder anymore. It's been owned for a good share of time now by internet.com group, whoever they may be.
And it shows. Updates are few and far between. There are more ads, and it appears that those ads are plugged in as an after thought. It's funny, the title for PHP Builder says "The Resource For PHP Developers", but that's no longer true! It still has a good number of stories and such, and it's message board is extremely active, but it's inactivity is killing it.
Also, Tim himself has stated after Sourceforge had been finished for some time, that he was suprised he wrote some of that stuff. He, just as all of us learn more and more as we go. And the programmer that looks back at what he did to make what he does, or will do better is a good programmer.
Tim Perdue fits that well. So does Linus Toorvalds (Linux Creator), Rasmus Lerdorf (PHP creator), Larry Wall (Perl creator), and the best of all, John Carmack (Doom and Quake series creator).
Later on,
BDKR (TRC)
And it shows. Updates are few and far between. There are more ads, and it appears that those ads are plugged in as an after thought. It's funny, the title for PHP Builder says "The Resource For PHP Developers", but that's no longer true! It still has a good number of stories and such, and it's message board is extremely active, but it's inactivity is killing it.
Also, Tim himself has stated after Sourceforge had been finished for some time, that he was suprised he wrote some of that stuff. He, just as all of us learn more and more as we go. And the programmer that looks back at what he did to make what he does, or will do better is a good programmer.
Tim Perdue fits that well. So does Linus Toorvalds (Linux Creator), Rasmus Lerdorf (PHP creator), Larry Wall (Perl creator), and the best of all, John Carmack (Doom and Quake series creator).
Later on,
BDKR (TRC)
Well, if you consider what your overhead is? Most work on a system is done on the back end. Sure, the front end of a system is important, but if you consider intranets, admin sections to websites, and specialized programs for individual things, objects in PHP are not going to kill you.
I can attest to this fact with running PHP on a commercial system, where a lot of the transaction based work is done with objects. In fact, I am developing the next transaction/translation system, and it's completely OO. There really is not easy way I could do it using normal procedural code. The object gives me the data protection and abstraction that I need.
Sure, using objects is overhead. But those that argue that 90% of an object is stuff they don't need, they using poorly designed Objects. Using Objects in you PHP code where it makes sense is better than forcing procedural just because you don't want to use an object. If you are that in need of speed, just cut to C.
I find people who nitpick over " and ' (as I once did) as a holy grail of speed don't really understand PHP. " and ' (the same as objects and procedural) aren't really going to make a difference in the grand scale of things if you know what you are doing and what your project really entails.
I can attest to this fact with running PHP on a commercial system, where a lot of the transaction based work is done with objects. In fact, I am developing the next transaction/translation system, and it's completely OO. There really is not easy way I could do it using normal procedural code. The object gives me the data protection and abstraction that I need.
Sure, using objects is overhead. But those that argue that 90% of an object is stuff they don't need, they using poorly designed Objects. Using Objects in you PHP code where it makes sense is better than forcing procedural just because you don't want to use an object. If you are that in need of speed, just cut to C.
I find people who nitpick over " and ' (as I once did) as a holy grail of speed don't really understand PHP. " and ' (the same as objects and procedural) aren't really going to make a difference in the grand scale of things if you know what you are doing and what your project really entails.
- twigletmac
- Her Royal Site Adminness
- Posts: 5371
- Joined: Tue Apr 23, 2002 2:21 am
- Location: Essex, UK
Thanks for that Jason, I was just about to ask exactly what the overhead was since everything written just seems to be abstract and a warning that OOP will make your code slow. Nobody ever says what slow is though or compares OOP code to non-OOP code in a quantitative way.
My OOP stuff just doesn't seem to run slower than the non-OOP stuff (and my 's don't make a difference either but I can cut and paste my HTML code and make it XHTML complient without lots of backspaces
).
Mac
My OOP stuff just doesn't seem to run slower than the non-OOP stuff (and my 's don't make a difference either but I can cut and paste my HTML code and make it XHTML complient without lots of backspaces
Mac
OOP (unofficial) benchmarks
This is some interesting stuff that I've stumbled across and kept in mind for some time.
Twig, you may be interested in this. Check it out here http://php.weblogs.com/discuss/msgReader$537?mode=day
Tally ho,
BDKR (TRC)
Twig, you may be interested in this. Check it out here http://php.weblogs.com/discuss/msgReader$537?mode=day
Tally ho,
BDKR (TRC)