Great OOP Tutorial

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
User avatar
protokol
Forum Contributor
Posts: 353
Joined: Fri Jun 21, 2002 7:00 pm
Location: Cleveland, OH
Contact:

Great OOP Tutorial

Post by protokol »

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
will
Forum Contributor
Posts: 120
Joined: Fri Jun 21, 2002 9:38 am
Location: Memphis, TN

Post by will »

that's definitely a good intro to OOP, but i am reminded of what Tim Perdue said in regards to using OOP...
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...
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.

i tend to agree with him.
User avatar
protokol
Forum Contributor
Posts: 353
Joined: Fri Jun 21, 2002 7:00 pm
Location: Cleveland, OH
Contact:

Post by protokol »

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.
will
Forum Contributor
Posts: 120
Joined: Fri Jun 21, 2002 9:38 am
Location: Memphis, TN

Post by will »

to the credit of OOP, one of hte very few things i've found it useful for is connecting to two seperate databases on two different servers in the same page.... to do it functionally would be quite ridiculous with a very large page with many queries.
User avatar
protokol
Forum Contributor
Posts: 353
Joined: Fri Jun 21, 2002 7:00 pm
Location: Cleveland, OH
Contact:

Post by protokol »

well, i think we can both agree that OOP has it's strengths as well as its weaknesses

nonetheless, each coder will see the differences differently
will
Forum Contributor
Posts: 120
Joined: Fri Jun 21, 2002 9:38 am
Location: Memphis, TN

Post by will »

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.
User avatar
twigletmac
Her Royal Site Adminness
Posts: 5371
Joined: Tue Apr 23, 2002 2:21 am
Location: Essex, UK

Post by twigletmac »

Date: 07/28/00 02:21
I always wonder if comments made 2 years ago still hold true :roll: . But I agree with the stuff above - OOP does have some benefits for some larger projects but is generally overkill for smaller ones.

Mac
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Doh!

Post by BDKR »

I always wonder if comments made 2 years ago still hold true :roll:


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)
will
Forum Contributor
Posts: 120
Joined: Fri Jun 21, 2002 9:38 am
Location: Memphis, TN

Post by will »

twigletmac wrote:I always wonder if comments made 2 years ago still hold true
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.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

A Tim Perdue addendum

Post by BDKR »

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)
jason
Site Admin
Posts: 1767
Joined: Thu Apr 18, 2002 3:14 pm
Location: Montreal, CA
Contact:

Post by jason »

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.
User avatar
twigletmac
Her Royal Site Adminness
Posts: 5371
Joined: Tue Apr 23, 2002 2:21 am
Location: Essex, UK

Post by twigletmac »

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
will
Forum Contributor
Posts: 120
Joined: Fri Jun 21, 2002 9:38 am
Location: Memphis, TN

Post by will »

jason wrote: [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.
yeah, i think that is really the heart of the matter.... if we keep that in mind, this all kinda becomes a moot argument.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

OOP (unofficial) benchmarks

Post by BDKR »

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)
Post Reply