Starting anew: OOP? PEAR?

lanny

Hello,

there is an overwhelming amount of info which would take me so long to read that I would never do any code. I am not a newbie in the general sense - but have just started to learn PHP. I believe I can write basic procedural code but:

1) Should I be using the OOP method as much as possible (meaning I would have to crack the philosophy, too) ?

2) What about PEAR - is it something like CPAN in perl (I use perl now) and should I use it to shurtcut the development?

What I want to write is an application to do specialized reservation of multiple resources over time. The database model (E/R) based on the business needs is ready.

I would be gratefull just for being pointed to unbiased but focused information. I am not much interested in the Computer Science theories, I am interested in the practical php experience.

Thanks

Kudose

After years of procedural, I've found OOP to be much better, but it does have a learning curve (which I am still tackling).

I've found PEAR to be like CPAN in the sense it provides a central repository for tools and is useful to stop re-inventing "the wheel".

My 2 cents would be to go with OOP and use PEAR for large scale sites that you need rapid implementation of "the wheel".

lanny

Kudose wrote:
...
My 2 cents would be to go with OOP and use PEAR for large scale sites that you need rapid implementation of "the wheel".

Thanks for the quick reply.

It took some convincing from my younger friends to go with PHP to start with. But I'd like to do it right. So far, I only saw having to prewrite all these classes and methods and what have you, where writing a piece of code to access mysql, do a query and display the results took me a few minutes.

When does one start seeing the OOP benefits? Are there any if I am the team.

PEAR - if similar to CPAN approach I would understand using right away. I am going there to see what they have now :-)

Again, thanks.

NogDog

OOP benefits tend to appear greater in proportion to the size of the application, the number of developers working on it, and the length of the application's lifetime (i.e.: how much maintenance it will require). It also provides a long-term benefit by increasing the re-usability of any code you write (or the ability to integrate OOP code from third-party sources).

I've gotten to the point now where even when I create small, simple scripts, I still use OOP techniques. I find that it helps to force me to organize both my thoughts and the application's design, often resulting in less total development time and usually a more robust application.

lanny

NogDog - I like your notion of having to follow discipline - that is a very convincing argument. Having said that: how do I weed through the available PHP stuff to know, which is OOP and which is not. What I mean is that, for example, db acces has so many alternatives.

NogDog

Theoretically, at least, an OOP application should have all of its code defined within class { ... } definitions. However, using classes does not really enforce true object-oriented design and implementation, it only allows it. For instance, the following trivial script uses a class to achieve its desired output, but there is really no modeling of real world things or concepts via the use of software objects, just the use of a class's constructor method to output some text:

class Example
{
   function Example()
   {
      echo "Hello, World.";
   }
}
$test = new Example();

This tutorial, though Java-based, provides a good introduction to the general concepts of OOP.

PS: I am by no means a OOP expert, just someone who a couple years ago or so was more-or-less where you are now: discovering OOP and teaching myself how to use it (and still trying to learn).

ahundiak

Try reading through the Zend_Framework manual and maybe a tutorial or two.

http://framework.zend.com/manual

That should give you an idea of how a reasonably modern OOP framework should work.

As far as db access goes, you are absolutely correct in noting that there are many solutions out there. The Zend classes might fit your needs. PHPDoctrine and Propel are two additional OOP systems that will also work well.

lanny

ahundiak: Thanks for the links, I will go there today.

While perusing PEAR, I found DB_DataObject. I ran a few scenarios and, honestly, I did not get convinced.

rr1024

Well I'm not a pro coder but I am a hardware engineer and have spec embedded code and worked with software programmers a lot.

I believe everything has it's place....If I re-use a function more than 4 times then generally I'll spend the extra time to create a class for it and add more functionality...UNLESS it makes sense and is easier to continue using it as a function.

Now if I have two or three similar functions and doing similar but different tasks I will almost always turn that into a class.

I'd say that 80% of my code is straight functions and the rest is classes.... I know for the most part end users prefer functions because they are usually easier for thier coder to debug or modify.

just my 2 cents

lanny

Well. I am finding that going hybrid makes little sense, because the code then has two looks, i.e. state->switch and switch[state]. I believe now that I either go truly object oriented or stay with the procedural, function enlightened, code.

In rr1024 way, I would code one way and then, when I reach some level of repetition, go back and make classes and rewrite what I already wrote. I might be off in the left field and not understand it fully but reviewing some PHP code, I found a lot of it incomprehensible because of the mix of methodology.

I am in no rush, my project is just in the stage of blue skying.

Kudose

lanny wrote:
I would code one way and then, when I reach some level of repetition, go back and make classes and rewrite what I already wrote.

With OOP you only have to rewrite a little bit, not the whole thing.

laserlight

Theoretically, at least, an OOP application should have all of its code defined within class { ... } definitions. However, using classes does not really enforce true object-oriented design and implementation, it only allows it.

Coming from a C++ background*, I would go a step further and say that not only does the existence of classes not imply that your design is necessarily object oriented, but the existence of free functions does not imply that your design is necessarily not object oriented.

The idea is that, with function overloading and template programming, free functions sometimes provide better abstractions and encapsulation. Though since PHP does not have function overloading in general, I suspect that does not apply.

But when I talk to C++ programmers, I say I come from a PHP background, lol 🙂