Page 1 of 2
Best place to learn OOP side of php
Posted: Thu Apr 13, 2006 6:26 am
by rsmarsha
I've been using php for a couple of years now, and not had much use for the OOP side. This is mianly due to the fact i've worked on small projects and one large PC company website. The pc site has functions i wrote for certain bits of the code, but as most is custom on each page i havn't used classes much.
I was wondering if you could point me in the right direction to help take my php knowledge further, into the oop side of things.
Thanks in advance.
Posted: Thu Apr 13, 2006 6:30 am
by Maugrim_The_Reaper
Any PHP book which also happens to cover Design Patterns in addition to an overview of OOP is good. That and post any confusing questions here...

.
Might be a good idea to find a very small project which uses OOP and see how it works.
Posted: Thu Apr 13, 2006 6:45 am
by Oren
I just learned OOP (PHP 5) few days ago myself. I couldn't find any serious online guide for this so I had to learn from a simple tutorial on the Zend site and from writing a class that connects to my database and lets me run queries, count the results etc (still working on this class).
So here it the tutorial on the Zend site:
http://www.zend.com/php/beginners/php101-7.php
After reading the above tutorial and playing with classes for a little bit I suggest you to go to this tutorial:
http://www.zend.com/php5/articles/php5-exceptions.php
The basic is pretty easy I must admit, so play with it for a while and you should be fine.
P.S If you find any other (more serious resource) about OOP for PHP 5 please post a link here so anybody else who wishes to learn OOP will have some place to start at.
Posted: Thu Apr 13, 2006 8:17 am
by Buddha443556
OOP is more than just classes. OOP allows programmers to tackle very large and/or complex problems by identifying objects. Identifying objects is easy, they should always be the nouns. Inventing the objects to hold together the objects you identified is tricky - patterns to the rescue. Patterns are standard solutions to common problems. A good pattern is loose, so it can fit many problems and be implemented in many different ways. A pattern helps you solve your problem, it isn't the solution. There's a lot more to learn than just classes.
Here's two OOD principle to start you off, hopefully on the right foot:
Open-Closed Principle
Substitution Principle
Posted: Thu Apr 13, 2006 8:35 am
by Oren
Don't you forget something Buddha443556? We are talking here about PHP (5), not other languages

Posted: Thu Apr 13, 2006 8:53 am
by Chris Corbyn
Oren wrote:Don't you forget something Buddha443556? We are talking here about PHP (5), not other languages

But many common OOP patterns can be implemented in PHP too. A registry is a registry, a singleton is a singleton, MVC is MVC... Granted, the code will look different for obvious reasons, but the principles still stand.
Posted: Thu Apr 13, 2006 1:10 pm
by Buddha443556
But many common OOP patterns can be implemented in PHP too. A registry is a registry, a singleton is a singleton, MVC is MVC... Granted, the code will look different for obvious reasons, but the principles still stand.
Exactly.
Oren wrote:Don't you forget something Buddha443556? We are talking here about PHP (5), not other languages

Admittedly, I'm encouraging you and others here to learn the theories and principles of OO Analysis, OO Design and OO Programming. OOP is
not bound to any language. An OOP language, such as PHP5, makes it easier to implement an OOD however an OOP language is
not required. If you learn the theories and principles of OOP then you'll be able to apply them to any problem using any programming language. That's not such a bad thing for me to encourage, is it? Though maybe off topic.

Posted: Thu Apr 13, 2006 2:31 pm
by Christopher
Buddha443556 and
d11wtq make really valid points here. The thing about OO is that it is a way to think about and design software -- on top of some coding practices. Most PHP code you find around that uses the class construct is still basically procedural. I would imagine that
Oren's code is mainly procedural as well, just namespacing function libraries. That's a good first step. Just keep at it, read as much as you can, ask questions here, and let the ideas wash over you until, one by one, the concepts become clear to you.
Because OO is a methology/practice you need to accept its premises. Unfortunately programming best practices are usually counter-intuitive. That means that what you will be reading will often be the opposite to what has seemed obvious to you up until now. If you can keep an open mind there is a wealth of knowledge available from really smart people that can make you a better programmer. And beyond OO are Agile methodologies which provide more tools to make you a better designer and programmer.
Buddha443556 points to some good material. That site also has some general OO information as well:
OO Design Tips
OO Design Tips II
Posted: Thu Apr 13, 2006 3:46 pm
by Oren
arborint wrote:I would imagine that Oren's code is mainly procedural as well...
Well, I would call it "semi-procedural" as I'm not just writing it for future use but also in order to learn OOP - actually, I don't really need the class I'm working on at all currently - but I'll use it in the future.
I decided to move on and use OOP for 2 main reasons:
1. The new __autoload() function - now I don't need to use require_once() each time I need to use a certain function.
2. I'll be able to write big applications with a much more clean and simple code - if you can't keep your code clean and simple then don't code at all. The most sophisticated and great code is the most simple code.
P.S
arborint: "just namespacing function libraries" - what exactly do you mean and what is considered a real object from you point of view?
Posted: Thu Apr 13, 2006 6:03 pm
by Buddha443556
Oren wrote:I'll be able to write big applications
OOP can be used to write large applications. One of the benefits of OOP is reuse, when tackling a project where you can reuse code there maybe a significant benefit (50% increase) to using OOP. However, where code reuse isn't a factor OOP is no better than procedural. Of course, anytime you can reuse design and/or code you'll increase productivity.
A developer can only write so much code a day. To produce really large application in a reasonable amount of time takes lot of developers.
... with a much more clean and simple code
OOP does not guarantee clean or simple code. Clean and simple code takes discipline and experience.
Posted: Thu Apr 13, 2006 6:19 pm
by Christopher
Buddha443556 wrote:However, where code reuse isn't a factor
For a professional programmer, code reuse is always a factor. Only for amateur programmers is code reuse not a factor.
Posted: Thu Apr 13, 2006 6:25 pm
by Buddha443556
arborint wrote:Buddha443556 wrote:However, where code reuse isn't a factor
For a professional programmer, code reuse is always a factor. Only for amateur programmers is code reuse not a factor.
True.
Posted: Thu Apr 13, 2006 6:59 pm
by Christopher
Buddha443556 wrote:True.
Though I delta'd from your central point which was that neither Procedural or OO guarantee clean, well designed code -- and clean, well designed code is the goal. That's where your "discipline and experience" comment is right on the mark.
Oren wrote:P.S arborint: "just namespacing function libraries" - what exactly do you mean and what is considered a real object from you point of view?
A "real object" is simply anything geneated by a
new statement. Just using classes and objects does not mean using OO. The links provided above can explain it better.
Here is another like I came across today
http://www.developerdotstar.com/mag/art ... _main.html
Posted: Thu Apr 13, 2006 7:17 pm
by Buddha443556
arborint wrote:Buddha443556 wrote:True.
Though I delta'd from your central point which was that neither Procedural or OO guarantee clean, well designed code -- and clean, well designed code is the goal. That's where your "discipline and experience" comment is right on the mark.
Probably a little off topic but ... While code reuse is important, it should be pointed out that it's not the only kind of
reuse. Code reuse is probably the simplest and easiest to achieve though.
Delta me anytime Arborint.

Posted: Fri Apr 14, 2006 1:50 am
by jmut
Would like to share my humble experience as well.
1. You should use php5 for sure. 5.1 is preferable as there is some good stuff in this library
http://php.net/spl
2. Three books I would suggest
- PHP 5 Objects, Patterns, and Practice by Matt Zandstra
- Patterns of Enterprise Application Architecture by Martin Fowler (examples in Java and C#) - Design patterns bible sort of speak

- Refactoring Improving the Design of Existing Code by Martin Fowler
These books you will review for many times to come (especially the 2nd and 3rd) and it requires a lot of experience to get into proper design. As everything is
specific to circumstances there are only few patterns you can just blindly apply and know it works good.
There is now way you get your design/code good the first time (nobody does)...even Martin Fowler....so one very important part of the whole
application construction is unit testing.
http://www.lastcraft.com/simple_test.php and
http://pear.php.net/package/PHPUnit2 are the prefferable choice for php.
Tests give you confidance. The confidance you will so badly need when you modify your code (applying the knowledge from the 3rd book) and when you transfer your project to another platform/system - we already mentioned there is no way to build the application the first round around
This is from me. Wish you happy coding
