PHP and OOP

[coder_]

I just didn't know where to put this topic so i am going to assume this is a php problem and needed to be solwed. (Mods no hard feeling..  )

 

I found this article about PHP and object oriented programming.

 

http://michaelkimsal.com/blog/php-is-not-object-oriented/

 

 

So i would like to read you opinion about this topic. Just simply to discuss about PHP and OOP.

[DarkSuperHero]

That def was an interesting read...I think php is still largely procedural in nature..although im not as passionate about calling it a non-OOP language... :-P

[coder_]

Like the author said, rather Object Capable..

[Daniel0]

Meh... OOP is a programming paradigm, so obviously the language itself is not OOP. Ruby is not OOP either. If he wants to be so picky then ruby isn't OOP either. It's entirely possible to write imperatively/procedurally with ruby just as it is possible to write object orientedly (that's probably not a real word) with PHP. The fact that everything is an object in ruby doesn't make ruby OOP. The fact that your code uses objects doesn't make it OOP either.

 

OOP is about how you write your code and as such PHP, Ruby, Javascript, etc. support OOP, but they also support imperative programming. You sometimes refer to such languages as multi-paradigm languages. A language such as for instance Haskell is a purely functional language.

 

I don't think the blog post was very interesting nor very accurate actually. Sort of redundant actually, like "I'm here and I important ('have done billion dollar ecommerce projects in PHP') and clever (I supposedly knows what OOP actually is)".

[nrg_alpha]

I agree in general with what the author is saying with regards to PHP being capable of OOP, but not being in itself OO. Personally, I like the idea of being both procedural and OO capabale. It allows for flexibility / personal preferences... Those not comfortable with classes can stick to procedurals, while others who are comfortable can use classes if they wish.

 

Perhaps there’s a need to impress non PHP people, or to try to get across the idea that PHP supports objects.  Maybe that’s fair, but I don’t think so.

 

The author doesn't think it's fair to try to get the idea across that PHP supports objects??

[.josh]

You know what I think is funny about people who argue about object oriented programming being 'useless', is that those same people 99.9999999% of the time endorse using functions and properly following scope.  They fail to realize that object oriented programming is the same concept, only it just adds another layer of scope to the mix. 

 

Yes, most of the time you could have just written your program procedurally, instead of using OOP.  But that often misleads people into thinking there is no (or little) point to OOP. It's misleading because most of the time, people end up making a program to do whatever specific job they are doing, and then move on. 

 

They only really begin to grasp the appeal of OOP when they do enough jobs to notice that hey, every single job I've been doing I've been having to write a login routine or xyz routine over and over again, so why not make a general framework...like...a function, and pass the info specific to the circumstance to it?

 

And yes, even then that's fine and dandy, but the point of OOP is peace of mind.  When you write a function, the point is that the code inside that function will be doing the same thing over and over again.  The only way to be sure that when you call that function it will do what it is supposed to do every single time, is to enforce boundaries on it.  Those boundaries is the fundamentals of scope.  That's the point of scope: to ensure that complete control over what happens inside the function, stays with that function.

 

So why can't you just continue to do that with a handful of functions and variables? Well, you can, but there's no piece of mind.  Let's say you make a database handling script.  You use several variables and several functions, and each one may or may not depend on one or more of each other.  Well, if you leave out one of those functions, your system as a whole will bug or altogether break.  You want them to be grouped together and stay that way. 

 

Some of them you may want to allow for people to alter or add on to, and some of them may be the "core" of your "system" that absolutely must not be changed, in order for the "system" to do what it's supposed to be doing.  It's like changing a tire on a car.  You can buy different kinds of tires, but the tire you buy has to connect with the same amount of nuts and bolts spaced the same way, in order for it to fit on the car, the rim has to be made out of material that can support the weight of the car, etc... if you do not enforce these things, the wheel could fall off.

 

That's the point of the OOP paradigm: to ensure that your collection of functions and variables are being used the way they are supposed to be used, in order to keep the system from breaking.  You can leave it up to the user to use the variables and functions properly, knowing how they are supposed to be used, or you can put them in a class that defines how they are supposed to be used.

 

It boils down to packaging the parts up into a nice "interface" so that you or other people don't need to worry about what's going on inside.  That's why things like microwaves have all their internal parts hooked up and wrapped up inside a case and you have buttons on the front to operate the microwave's internals within the scope of how they are intended to operate.

[Daniel0]

You know what I think is funny about people who argue about object oriented programming being 'useless', is that those same people 99.9999999% of the time endorse using functions and properly following scope.  They fail to realize that object oriented programming is the same concept, only it just adds another layer of scope to the mix. 

 

Yes, most of the time you could have just written your program procedurally, instead of using OOP.  But that often misleads people into thinking there is no (or little) point to OOP. It's misleading because most of the time, people end up making a program to do whatever specific job they are doing, and then move on.

 

Those people generally do not understand OOP properly yet. I see a lot of people who are supposedly OOPifying their code. They may make a "database handling" class (to use your example) and then just slam all their existing functions into one big class called e.g. mysql or database. Then they proceed to call it OOP, but they also look at it and say "why bother?" and "how the hell would it be a benefit doing this?" and then they dismiss OOP. The thing is just that they never used OOP in the first place. They just used the class as a kind of namespace.

 

One of my teachers once said something like this: "You will be working in groups to gather information about one of the things and then present it to the class so we can get general knowledge about it, and so we can turn it into a discussion. I know most people often discuss things without knowing anything at all, but we are not going to to that."

[Mchl]

As his wife would say (if she cared about PHP at all) - “Bollocks”.

 

He's basically discussing semantics, not actual capabilities.

[.josh]

[Mis]using it as a namespace: exactly.  It's the same principle as doing this:

 

// example A
$max[0] = 10;
for ($x = 0; $x < $max[0]; $x++) {
   echo $x;
}

 

vs. this:

 

// example B
$max = 10;
for ($x = 0; $x < $max; $x++) {
   echo $x;
}

 

All by itself, example A is pointless. You do not need to be using an array to hold what you want to count to.  It's unnecessary; overkill.  Instead, just use a simple variable, like in example B.  Now, if you had a system that needed to keep track of different numbers to count to, then an array would be appropriate.  But this by itself is pointless. 

 

And that's the thing.  9/10 times when I see someone saying OOP is pointless, they are looking at OOP as being like this example (and also using classes in this manner), instead of looking at the system behind it. 

[jcombs_31]

I think people really need some form of programming education to actually fully understand it unless they are really just self motivated to learn.  I notice a lot of people jump into web design and start learning something like php out of necessity for their project without any real programming knowledge.  People do the same with database design without any real knowledge of normalization or even know what an ER diagram is. They just jump in and start talking out of their @ss.

[corbin]

I have no idea what an ER diagram is x.x.

 

 

*Googles*

[DeanWhitehouse]

I think the main problem is that these tutorials on OOP all teach you how to use it but none teach you where and why to use it, btw does anyone have a tutorial that does?

[Mchl]

Did you check tutorials on phpfreaks?

[DeanWhitehouse]

I glanced over them

[Daniel0]

Dunno what you mean exactly with teach how to use it. Learn the theory first and learn some design patterns. People often say that

class Dog extends Mammal
{
//...
public function bark()
{
	// ...
}
// ...
}

is not a real world example, but that's because they haven't got the point of OOP yet. It IS a real world example. OOP is about how objects in the real world interact with each other, and both dogs and mammals exist in the real world and Dogs inherit things that are generic to all mammals, but dogs also have behavior and traits that are specific to dogs and that not all mammals have. Dogs can bark and as such the Dog object has a bark() method. So if you want your dog to bark you call the Dog::bark() method. You don't care specifically how the bark() method is implemented, you just want it to bark. This is one of the cornerstone design principles in OOD (object oriented design): "Code to an interface, not an implementation."

 

The bark() is part of the Dog interface, the body of that method is the implementation.

 

You basically need to figure out what objects your application is composed of. Then you need to figure out how these objects interact and design their interface or API. You can do this using a UML diagram, but if it's a small application then you might not need to make a diagram. When you have figured that out you code it.

 

Another way to figure out what would be the most sensible interface is to use the TDD (test driven development) methodology and then write the unit tests before you write the implementation. In that way you get to figure out what your requirements are and if the interface you had in mind is usable. You can then write the implementation and if you did it correctly then all your unit tests should pass.

[Mchl]

How about this one?

http://www.phpfreaks.com/tutorial/design-patterns---introduction

 

It won't get any clearer than that. It's not smooth ride anymore.

[DeanWhitehouse]

Hmm from a brief read would i be correct to say that it is kind of like using CSS instead of HTML for layouts, for example you can have a page laid out usng CSS and you can then you can adjust the design easly using just CSS instead of writing the HTML.

 

Is that the right kind of concept?

[Mchl]

That would be very far analogy, but a possible one. It's more than just that.

[Daniel0]

Partially. What you are describing is about the separation of concerns, which I suppose you can say OOP to some extent is as well. For instance, the MVC pattern separates things into models, controllers, and views like you've separated your frontend into HTML, CSS, and Javascript. What you are talking about is also about progressive enhancement though, and that's not what OOP is about.

 

Try to take a look at The Object-Oriented Thought Process. It's a good beginner's book. I haven't read all of it though. It didn't give me very much new information so I got bored with it.

[DeanWhitehouse]

Hmm ok, looks like i should do some more reading about patterns etc.

[Mchl]

Yeah... patterns is where OOP gets juicy.

[Daniel0]

Don't just jump into the patterns immediately though. You need to grasp fundamental OOP concepts such as polymorphism, encapsulation, abstraction, inheritance, composition, decoupling, dependency injection etc. to understand why a particular pattern might be useful. Also remember that no pattern is set in stone; its implementation might differ depending on the context in which it is used.

[Mchl]

Yeah.

Hard as I try to use OOP, most of my classes are just stand-ins for namespaces...

[nrg_alpha]

Dunno what you mean exactly with teach how to use it. Learn the theory first and learn some design patterns. People often say that

class Dog extends Mammal
{
//...
public function bark()
{
	// ...
}
// ...
}

is not a real world example, but that's because they haven't got the point of OOP yet. It IS a real world example. OOP is about how objects in the real world interact with each other, and both dogs and mammals exist in the real world and Dogs inherit things that are generic to all mammals, but dogs also have behavior and traits that are specific to dogs and that not all mammals have. Dogs can bark and as such the Dog object has a bark() method. So if you want your dog to bark you call the Dog::bark() method. ...[chop]...

 

Doesn't that method have to be declared static to be able to call it via Dog::bark() ?

[Daniel0]

Yes, it does. You can, however, also use the foo::bar notation to simply refer to the member called bar in the class foo. I didn't instantiate any object in that snippet so the name of the object you would invoke bark() on would be unknown. I could have said $dog->bark(), but strictly speaking I could have called the object $cat.