What's the real benefit of OOP?

PHP
1

I’ve heard how it can help manage code better, implement features easily, and fix bugs faster… But I don’t exactly see the difference (in terms of benefit) to procedural programming. Why make a class when a file of functions can do the same? If there really a performance trade off and how does it make it easier to manage than procedural?

I’m learning OOP in PHP5 right now, and just am not sure why it’s so desired when it looks like it’s doing stuff that could otherwise be done just as good in procedural. I’m sure there’s a benefit as many people use OOP, especially large scale applications, but I’m just at a lost as to why.

Thanks :slight_smile:

2

I figured as much. My point was that when knowledgeable people are glib and let statements like “Why make a class when a file of functions can do the same” pass with a joke – then people new to programming get the impression that procedural and OOP are just apples and oranges. They are not. OOP is a much bigger universe of design and implementation possibilities.

3

Though perhaps meant as a joke, these kind of comments belittle the huge improvement to software design that OOP and Patterns have brought to us. Let us not forget the revolutionary contribution that the GoF era thinkers made to our craft. You can joke, but there has been no serious book about procedural programming in a decade. It is a historic paradigm that is now just a subset of what is possible with OOP.

4

felgall said

It makes reusing code much easier.

This is the bootom line of the oop concept, and I agree with felgall.

Take this line of code for example:

$db->hscadd($_POST['oname']);

In the db class it looks like:

function hscadd($varpost)
		{
			$this->varpost = stripslashes($varpost);
			$this->varpost = htmlspecialchars(addslashes($this->varpost));
			return $this->varpost;
		}

Notice even in classes, there are still functions.
Now to explain something: In the real real world there is no such thing as OOP. OOP is the way something is called or used. But all OOP is still procedual code. In fact all programming code in the whole world is procedual code. The way it’s utilized, reused, etc is what gives it a concept of OOP.
I could for example just write out this every time I needed to handle a post:

htmlspecialchars(addslashes($_POST['whateverisposted']));

If I had 50 tables, as long as I include this class I can use the

$db->hscadd($_POST['whatever']);

to achieve this particular task. This is where the OOP concept is good. But remember, it still does the exact same thing as if completely written out.

Bottom line:
Real small application = use procedual or oop concepts.
Large application = use oop concepts.

5

sunwukung wins the topic.

6

Ha, never a truer word spoken.

‘Analysis Paralysis’ can also come into play too, I’ve been a victim of this myself. :smiley:

Thankfully, fellow SP member Cups to me to JFDI.

7

The main benefit of OOP over Procedural is that you get to argue all day over what Design Pattern x means rather than implementing…I mean writing any code.

8

Hi…

re. plain old procedural v. OO:

One thing that drives me mad (as a long time OO’er) are view helpers. You just want to format some string, say a CC number or something, and your framework tells you that you have to create 20 lines of view helper to do it.

Here’s an example: http://solarphp.com/manual/views.helpers

Or another: http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.initial

How does this stuff make things simpler? I recently had to fix a bug in a link (the href was being double encoded). I had to trawl through 260 lines of code to fix it. If plain HTML had been used it would have been a one liner. And it would have worked, so fixing it would have been unnecessary.

When writing UI interaction code I want to be presented with a palette with which to paint. It’s more like a documents than code, so DRY is not useful (otherwise I’d work off of the zip compressed version). Functions like h() and link() make my job a lot easier. Having to code 20+ lines of view helper, and then debug the thing, doesn’t.

yours, Marcus

9

i have been using OOP now
but i think the concept that ‘OOP makes codes shorter’ is not true or is myth i guess…
There is lots of encapsulation in OOP which makes people think that ‘oh those 3 lines are doing all the things’…but people tend of forget lots of includes files and libraries at the begining of the file…and lots have nested file calls…
so prodedural makes code long and messy is not truth either…

10

well i think it is not impossible to make functions and file do all the things that class does(after all class is collection of properties and methods itself) but
it will require extra time and bring more complexcity
class approach will be much be more extensible and easy to maintain…
more standard…

so for that people have started converting functions and files into class…
but i think saying class is totally different and functions/files cannot do what class does at all is not true…

11

A file of functions cannot do all the same things as a class. This is what you need to discover.

12

All other things apart
using OOP you will open youself to vast resources especially while extending your application …
for eg rss class can be plugged,now there is twitter class,print class and so on…
these are just some examples…
so you open door for extending your application…and create a sort of standard in your codes…

13
Off Topic:

I just wanted to say I like the wording of the topic title. Makes it seem like there is a ‘fake benefit’ hehe.

14

I’m going to add two more to the list - although they are not so fundamental as the other texts mentioned here:

“Domain Driven Design” by Eric Evans
“Data Access Patterns” by Clifton Nock

The former because it helps shed light on WHEN to use patterns and how to interpret real world problems as OOP architecture.
The latter because it goes into greater detail than PoEAA (though not always) on the core data access patterns

15

Hi…

Yes. This is about basic OO skills.

That’s older :).

Not only that, but that one has dated a little more (Singleton is dead). Both are worth reading and you should read them both. Read the refactoring book as the highest priority, at least the first three chapters anyway.

The other classic is Patterns of Enterprise Application Architecture (Fowler again) as it defines a lot of the design language we currently use (e.g. ActiveRecord, DataMapper, FrontController), although Registry is going the way of Singleton.

The other classic is the Pragmatic Programmer by Hunt/Thomas.

Buy them. Read them all. Refer to them constantly.

yours, Marcus

16

Code can get very complicated very, very quickly but the computer doesn’t care what kind of spaghetti mess you write so long as it parses. If a PC had a mind, it’s a mind which can follow tortuous threads of logic with ease. It’s a mind with gigabytes of memory which can hold many things in its head at one time.

We can’t do that and that’s why we have OOP. You’re right to say it doesn’t do anything new which you can’t also do with procedural but then you’re looking at it from the wrong direction. Code has to be read and understood by humans as well as machines and that’s what OOP is all about. Making computers do stuff is the easy bit. The real challenge is to write code which is easy to understand, or at least as easy as it can be. Even something as simple as naming is incredibly important.

With OOP, the idea is to isolate different kinds of logic and meaning into separate components. If you need to change something, you’ll hopefully have all related logic in one location rather than scattered across the app. This also makes it possible to test the component in isolation. Loosely-coupled components can be swapped out easily to tweak the application logic.

OOP and test-driven design is really what you want to learn. TDD is a nice way to work. Lots of little steps make complex projects much easier to work through.

17

In most class-based languages, an object has a pointer to a single symbol-table, which belongs to the concrete class. Resolving the function is a single lookup.

I’m not an expert on the JVM, but I’m rather sure that the final keyword was never intended as an optimisation.

Mostly nitpicking here - I agree with the rest of your post.

18

Does it really worth reading…
well after seeing some many recommendation i thought of reading it but it says it was published in mid 1999
I think there has been huge and many drastic changes since then in 11 years…
so i have not read that 464 paged book yet…
but i am confused should i read it…
reading does take some time…

well style and preaching are normally outdated…but many tools/techniques has emerged since then

rather than that i was reading Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma
seems like it would be better

thanks

19

I suppose you could sort-of implement OOP using procedural languages, but last time I tried, PHP’s reference handling left a lot to be desired. :slight_smile:

The advantages of OOP are immense, mostly in terms of just keeping the code clean. With exceptions, you don’t have to check the return value of every single function, just wrap them all in a try / catch block.
(I don’t know about you, but personally, I’m pretty horrible about checking the return value of every single function call)

With inheritance, you can override methods for specific cases, a good example is a “stub” class with methods that do nothing. The parent calls these stub functions on an unknown object with parameters, if you need to do something with this information, you can inherit from the stub and safely ignore methods you’re not interested in.

Class names save you from having to write out obnoxiously_long_function_names_hoping_not_to_collide_with_anyone()

Because, you can just have $obj->obnoxious() and not need to worry about it. (this is actually desired, if 5 objects have a obnoxious() method, that does more or less the same thing, then other code can work with those objects in the same way)

As far as performance, OOP is probably not quite as good as procedural, depending on implementation of course, dynamic languages have to walk through the inheritance tree to figure out which actual function to run. (this is one of the reasons why java has “final” for methods you can’t override, the compiler can pre-compute the inheritance for such methods)

Also, all functions have a hidden “self” parameter as their first argument, which adds to the call-stack, which adds workload.

For the most part, the performance trade-offs are well worth it. In very rare cases (tight loop for example) you might consider using a function.

20

This is very true. That’s the book which, once I bought it, I cursed my self for not getting my hands on it two years prior.