How much OO is too much?

[timvw]

But in working with php/mysql, I haven't seen a reason to go OO at all. All the data is stored in the Database as an array and its just as effective an quick for me to write functions to manipulate the data as classes.

I don't agree.

As example a page which displays data from 2 separate databases..
Offcourse you can keep the $from, $where, $limit of each database together yourself, with a class it would (imho) require less effort to not mangle them.

I would say only use OO if you see a clear advantage, don't just use it to "look cool" or "look professional" because its not worth it and the code in reality isn't any better.

I agree, but that is true for each technology/methodology..

[Dr Livingston]

To look professional, you have to be professional, it takes a particular expertise for that. To get that particular expertise, you need to know how to use the tools of the trade, and in most cases, those tools do include object oriented programming for one.

There are of course, others but it just dumbfounds me why in this post, and others that you have made, you have a complete disregard of the true meaning and purpose, and are showing a total lack of knowledge for object oriented programming.

Yet, here you are (again) making a statement that one shouldn't use, nor even consider the use of, object oriented programming.

Not sure who you are trying to impress, but I'm certainly not impressed. If anything, I'm more annoyed and worried that some members actually pay attention to you

[mx2k]

not to hijack the thread but this reminded me of something and i couldn't find the thread that touched on this. but i remember an ealier discussion of frameworks and turning each type into an object, what i mean is something like

class string, class array, class integer, etc.

i remember reading it, but i don't remember all the pros and cons and i can't seem to find the thread when doing a search.

[printf]

I think people that replied to me are missing my point. So this time I will make it very clear so you understand what I was trying to say!

PHP has a easy learning curve, so people tend to only do what is absolutely necessary to perform a task that they wish to do. Look at the thousands of script you can buy or get for free. Some are very dangerous, most others have terrible logic, basing most of their coding on core functions when other core functions are faster and more resource friendly for what they are trying to do! Why does this happen, because people don't take the time to understand that reinventing the wheel is important for bringing better logic to the over all design!

So using the OO way and still writing terrible logic will do nothing but have people believe you understand what you are doing when you don't which will just create more dangerous scripts to learn from for free on the Internet! Sure you might call me cynical, but following coding standards is principle that very few people live by and the others that don't follow those standards tend to make up their own which only tells me they think they know more than what they really do!


So use what ever you want to use. But you should start asking your self this...

'Is what you just copied or wrote truly the best way to do what you want done'

You can be sure it will never be the best until you try to do it many different ways, and even asking for help may open your eyes to other ways that you have not ever learned!

I have not failed. I've just found 10,000 ways that won't work.

printf

[Captain Proton]

and I would bet that your "bottlenecking" is more theoretical than real.

Superstition is not theory

[lastcraft]

Hi...

If your writing a massively OO PHP guestbook, you've probably taken it a bit too far.

What if you write a small OO guestbook?

yours, Marcus

[DougBTX]

An oo guestbook?

[lastcraft]

Hi...

Yea, we probably share something there. Seems like an inherant mistake to me to have a "single use object", because if you only need to use it once, why bother with an object?

But if I test it, then I've used it twice...

yours, Marcus

[REMIYA]

OOP is the reason why C++ was created, it was created with the idea of developing large programs above 50 000 lines of code.

Can anyone imagine 50 000 lines in procedural programming, and how would they be kept up to date

[arborint]

But if I test it, then I've used it twice...

That is a concept that is difficult to understand unless you have been there (and back).

I think one of the great misunderstandings about OOP is not understanding that it is about design more than coding. Think about the number of new design possiblities that occur when you add functions to a language. Well, adding classes adds additional new design possiblities. I think that some programmers see OO as competetive to procedural, rather than seeing it as expanding their design possiblities.

Lastcraft once quoted a coworker as say that OO is about the connections between the bits of code that make up a program, rather than about the code itself.

[bonefry]

Why does this happen, because people don't take the time to understand that reinventing the wheel is important for bringing better logic to the over all design!

So using the OO way and still writing terrible logic will do nothing but have people believe you understand what you are doing when you don't which will just create more dangerous scripts to learn from for free on the Internet! Sure you might call me cynical, but following coding standards is principle that very few people live by and the others that don't follow those standards tend to make up their own which only tells me they think they know more than what they really do!


So use what ever you want to use. But you should start asking your self this...

'Is what you just copied or wrote truly the best way to do what you want done'

There is one problem with your statement. Should we stop using Linux because only God knows what incomplete idiots worked on it ?
Of course not, because it is TESTED BY THE COMUNITY

[Archbob]

No one in their right mind would right a 50,000 line php file, thats what includes and modules are for.

Despite Dr. Livingston's "true meaning and purpose" post, there is no "true meaning and purpose" in programming. You write code to achieve a specific purpose and try to make the code moddable. Whether you do it in OO, straight procedural, or functions, is up to you. One is not better than the other.

Yes, it is possible to write really crappy OO code or try to implement OO everywhere(even when its not needed).

Do I use OO in C++ and java: Yes
Do I use it in PHP: Sparingly


I prefer to write files with functons I regularly use instead of writing classes, it works easier for me that way and its very easy for me to go back and edit later. I've programmed lots of forums and CMS system and I haven't really run up agianst a case where using OO beats using function straight out.

Its one of the reason I don't like .NET as much as PHP because its forcibly makes you use OO, even on a small application wher its not needed.

OO is completely different from procedural of functional programming and for desktop apps, it needs to be used. But for the most common web apps, I just don't see too much of a need for it.

[bonefry]

I think one of the great misunderstandings about OOP is not understanding that it is about design more than coding. Think about the number of new design possiblities that occur when you add functions to a language. Well, adding classes adds additional new design possiblities. I think that some programmers see OO as competetive to procedural, rather than seeing it as expanding their design possiblities.

So, you see OOP as an extension to procedural ? That means you understood nothing.
Those language additions are nothing more that helpers. And it's not about expanding design posibilities, it's a whole paradigm shift.

[REMIYA]

No one in their right mind would right a 50,000 line php file, thats what includes and modules are for.

Includes and modules are part of the code, although you set them in different files

[Archbob]

Includes and modules are part of the code, although you set them in different files

Yes, but it makes scripts so much easier to edit when they are in separate modules and files.

I hate those scripts where all the admin function are in one huge file.

I've done displaying information with too databases first using a simple function with 3 or 4 parameters. Its pretty easy, pass the function the limiter values twice(one for each db) and remember to close the connection at the end of the function.

BTW: There are reasons to switch to php5 besides OO.

[bonefry]

Yes, but it makes scripts so much easier to edit when they are in separate modules and files.

I hate those scripts where all the admin function are in one huge file.

I've done displaying information with too databases first using a simple function with 3 or 4 parameters. Its pretty easy, pass the function the limiter values twice(one for each db) and remember to close the connection at the end of the function.

You are wrong if you think include files and modules will make it easier to write 50000 lines of code.

[REMIYA]

I hate those scripts where all the admin function are in one huge file.

What if the user of your CMS files deletes by accident one of the module files?

Wouldn't it be better, if they are placed in one huge file, compressed and then sent to the user? While the original modules stay for documentation and eventual updating and bug-fixing by the project admin.

So one huge, compressed user file, and images

[arborint]

So, you see OOP as an extension to procedural ? That means you understood nothing.
Those language additions are nothing more that helpers. And it's not about expanding design posibilities, it's a whole paradigm shift.

I nowhere said that OOP is an extension to procedural. I said that each adds new design possiblity. I'm not sure what "extension to procedural" means, but you would have to ignore the history of the development of programming languages to say that OOP concepts were not built procedural concepts.

As for catchy phrases like "a whole paradigm shift", I'm not sure in substance what that means. To clarify, would you call the advent of procedural languages "a whole paradigm shift" from the machine and assembly language days that proceeded them?

[DougBTX]

As for catchy phrases like "a whole paradigm shift", I'm not sure in substance what that means. To clarify, would you call the advent of procedural languages "a whole paradigm shift" from the machine and assembly language days that proceeded them?

I think he was refering ideas in an article quoted a couple of days ago where the paradigm of the RAM going to the CPU being replaced with one where the CPU goes to the RAM.

Douglas

[Archbob]

What if the user of your CMS files deletes by accident one of the module files?

Wouldn't it be better, if they are placed in one huge file, compressed and then sent to the user? While the original modules stay for documentation and eventual updating and bug-fixing by the project admin.

So one huge, compressed user file, and images

Well, alot of the times, thats not the way it works. Lets say you are selling a script and the buyer wants to mod it. I'd much rather have 40 separate files that are named properly than look one huge-*** file.

[DougBTX]

What if the user of your CMS files deletes by accident one of the module files?

Wouldn't it be better, if they are placed in one huge file, compressed and then sent to the user? While the original modules stay for documentation and eventual updating and bug-fixing by the project admin.

Just include some tests to make sure all the files are there that the user can run on install, and you'll be fine

Douglas

[Dr Livingston]

Oh Dear...

Yes, but it makes scripts so much easier to edit when they are in separate modules and files.

Well, you wouldn't have to edit anything, if you had a -BEEP- abstraction and an Interface to work with, would you?

But of course... You don't have that luxury with procedural programming, do you? Tell me something, with all this editing of your files, exactly what are you doing? What are the possibilities huh?

The possibilities of introducing new bugs... Alas, you are including a lot of 'module' files, so which file has the bug... A few hours later, after looking through God knows how many files, you may find the bug at some point during your working day.

Sod that, that isn't software development

You are wrong if you think include files and modules will make it easier to write 50000 lines of code.

I would think that it would make your life a damn sight harder and even more unbearable?

[arborint]

I think he was refering ideas in an article quoted a couple of days ago where the paradigm of the RAM going to the CPU being replaced with one where the CPU goes to the RAM.

I got that. I just wanted to clarify how the phrase "whole paradigm shift" was being applied now to programming. He stated it in such a way that I might think the OOP was the only "paradigm shift" is programming. And that is assuming that OOP is a single "paradigm".

[arborint]

Well, alot of the times, thats not the way it works. Lets say you are selling a script and the buyer wants to mod it. I'd much rather have 40 separate files that are named properly than look one huge-*** file.

Modularising code into files and proper naming have little to do with either procedural or OO programming. The original point that you are twisting is that OO is one battle proven way to deal with large codebases.

[bonefry]

I nowhere said that OOP is an extension to procedural. I said that each adds new design possiblity. I'm not sure what "extension to procedural" means, but you would have to ignore the history of the development of programming languages to say that OOP concepts were not built procedural concepts.

As for catchy phrases like "a whole paradigm shift", I'm not sure in substance what that means. To clarify, would you call the advent of procedural languages "a whole paradigm shift" from the machine and assembly language days that proceeded them?

Quote from a previous post:

I think that some programmers see OO as competetive to procedural, rather than seeing it as expanding their design possiblities.

From one point of view, you are right. From another you are wrong. It takes quite some time for a programmer thinking in procedural to think OOP and when he finally makes the switch, there is no way going back. And that's what is called a paradigm shift. And IMHO it's a mistake to consider OOP as an extension to procedural for better design. That's why we have UML. But then again, maybe I haven't understood you.

And of course, procedural programming was also a paradigm shift. And OOP isn't perfect and something better will come along.