Tutorials

OO PHP Part 2: Boring OO Principles

by John Kleijn on Jun 7, 2008 11:20:14 AM

1 Core OO(P) Principles

1.1 Inheritance

Remember these classes from part 1?

I used them to explain the concept of inheritance to you. Class Dog inherits Animal’s properties and methods when an object is instantiated, if it doesn’t re-declare them itself.

Animal could be the base class for other animal classes, like Bird and Cat. Subclasses like these would have a common interface defined by Animal. Confused? Sharing an interface simply means other components of your application can interact with the classes in a similar way. This interaction is defined by the calling routines (methods and method arguments – the name, arguments and return value of a method is also referred to as the method signature).

In this ridiculously simply example, eat is the whole of the interface. Any class extending Animal is guaranteed to have a eat method which takes a single argument, because even if they don’t declare it themselves, Animal defines the default behaviour.

1.2 Polymorphism

Let’s take a look at a possible Bird…

As you can see, Bird isn’t all that different from Dog. They both eat food. However, because they are not the same type of Animal, they behave differently in response to the $food they are being fed. This is referred to as having their own implementations of the interface provided by Animal, or simply: implementations of Animal.

This is at the core of the principle of polymorphism: Different types of objects can be handled in the same way, even though their implementations vary.

1.3 Encapsulation

Encapsulation refers to ‘isolating’ meaningful parts of your application from each other. This involves hiding information (both data and the implementation of a specific behaviour), and breaking your application into meaningful parts. Often encapsulation is used as a synonym for Information Hiding. But this is only half of the story. The other half, breaking your application into meaningful parts, will be covered in the next chapter.

For a practical example of Information Hiding, check out the heuristic “All Properties Should be Private” later in this tutorial.

Comments

Great. You're moving faster than I would've thought. Personally I'm looking forward to reading part six through eight.

I haven't read this one yet, but when I have I'll try to write what I think about it :)

1. Daniel Egeberg on Jun 7, 2008 12:19:04 PM

Curses! You revealed that I have 8 parts planned! Jinx....

2. John Kleijn on Jun 7, 2008 12:27:09 PM

Haha... now you're obliged to write them all :D

3. Daniel Egeberg on Jun 7, 2008 12:36:21 PM

Okay, so I've just finished reading it. I think it's really good, but I'm wondering, seeing as "All properties should be private", do you think it would be wrong to have protected properties so that children classes may modify it?

Edit: I modified your TOC so the page numbers from your .doc are no longer there.

4. Daniel Egeberg on Jun 7, 2008 12:53:18 PM

Strictly, yes.

Absolute best practice would be to have only private properties. Especially when keeping classes 'open for extension', you risk losing the benefits of defensive programming if you declare properties protected instead of private. If you want to give child classes some special privileges, write a protected method that allows them to execute those privileges.

But, I cheat a little in that respect myself and use protected in some cases as well. In particular when I have a class that doesn't have any accessors yet, I can be lazy and use protected instead of accessors. But being lazy doesn't exactly make good practice..

In all, it isn't cast in stone, just best practice.

5. John Kleijn on Jun 7, 2008 2:58:14 PM

I suppose that makes sense. I'll keep that in mind for future projects I'll be working on.

6. Daniel Egeberg on Jun 7, 2008 3:17:48 PM

Putting defensive programming aside, there's another reason why using accessors, within a hierarchy or even in the class itself is a good idea:

"The reason why I chose to use the get_*() and set_*() methods inside the class even though the properties are accessible as well is because if one later wanted to change how to retrieve or set the data only those functions would have to be updated and not everything using them."

Does that quote look familiar? This is about cohesion and centralizing responsibility as well.

7. John Kleijn on Jun 7, 2008 3:24:33 PM

Indeed it looks familiar :D

8. Daniel Egeberg on Jun 7, 2008 3:33:33 PM

Wow.... This was one of the best things I've ever read on OOP. For some reason, the whole responsibility and coupling and what not thing had never clicked before....

Looking forward to part 3 ;p.

9. Corbin H on Jun 9, 2008 12:48:44 AM

Puff! Yay, catching up with the tutorials, love them! :)

10. allenskd on Jul 5, 2008 8:52:37 PM

Just finished reading all 3 of your articles on OOP and I was taking a second look at this and noticed a spelling error. Thought you might like to know so you can fix it :-)

2.3 Don’t Repeat Yourself (DRY)
Second Code Block
'findHigestPoster' -> 'findHighestPoster'

11. Brandon Frohs on Sep 11, 2008 9:00:19 PM

Brandon,

Actually, that's a typo. Not to say there aren't loads and loads of spelling mistakes and grammatical errors in all of my tutorials. I need to find the time look them over properly, but I'm afraid that won't happen too soon.

Thanks for the feedback though.

If anyone wants to volunteer proofreading my tutorials in say a Language Editor function, let me know. ;)

12. John Kleijn on Sep 12, 2008 4:43:32 AM
Login or register to post a comment.