Tutorials

OO PHP Part 2: Boring OO Principles

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

Views: 12150

Introduction

How about that catchy title eh? If you are reading this, you must be REALLY dedicated to learning about Object Orientated applications!

This article will try to explain some OO principles to you, as well as some ‘good practice’.

Know what to expect: there will be no funny pictures, no diagrams. There will be some code, but that won’t be very exciting either. This is all pretty dry stuff. Regardless, it is important. This tutorial will include some of the things intentionally left out of part 1, as mentioned in section 1.2 of that tutorial.

Still feel like it? Come on then, time to get your foundations in place!

Index

1 Core OO(P) Principles
1.1 Inheritance
1.2 Polymorphism
1.3 Encapsulation
2 Coupling, Cohesion and Some Related Principles
2.1 A practical example
2.2 Single Responsibility Principle (SRP)
2.3 Don’t Repeat Yourself (DRY)
2.4 Open-Closed Principle (OCP)
3 Defensive Programming
4 Heuristics
4.1 Avoid global data
4.2 All properties should be private
5 In conclusion

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
Login or register to post a comment.