Object Oriented Programming Or Traditional Coding?

[mostafatalebi]

The exact same thing can be said about an application that is entirely done in OOP - OOP stuff can easily be as bad if not worse than procedural. The problem in your application was not the lack of objects.

Yes very practical definition you've given! But I go and try to make a test website in OOP so then jump into real process since I don't like that messing up of future months

Because all the suggestions goes either toward OOP or toward future-OOP

Edited November 20, 2012 by mostafatalebi

[akphidelt2007]

The exact same thing can be said about an application that is entirely done in OOP - OOP stuff can easily be as bad if not worse than procedural. The problem in your application was not the lack of objects.

 

I never said it was a lack of objects. I said the problems in my code made me understand how OOP could be beneficial to me. Sure I could have rewritten the code procedurally more efficient each time. But why do that when you can put all that work in to objects and reuse it for future projects. Nice try, but you fail.

[Hall of Famer]

Well why still arguing in this thread? I thought the OP already got his answer, which is to use OOP. This way he makes a much much more professional and maintenable site. Is this what hes trying to accomplish, isnt it?

Edited November 20, 2012 by Hall of Famer

[Jessica]

 

 

I never said it was a lack of objects. I said the problems in my code made me understand how OOP could be beneficial to me. Sure I could have rewritten the code procedurally more efficient each time. But why do that when you can put all that work in to objects and reuse it for future projects. Nice try, but you fail.

 

You can reuse procedural code just as easily as objects. What you're talking about is abstraction, not OOP. 

 

Explain HOW OOP was beneficial to your project. 

[akphidelt2007]

You can reuse procedural code just as easily as objects. What you're talking about is abstraction, not OOP.

 

Explain HOW OOP was beneficial to your project.

 

Creating Tables

Create Templates

Creating Hierarchies

Creating Dynamic Query Strings attached to filters and authentication

Loading up files and being able to use all the previous created variables with out passing them along

Loading and unloading templates

Form Creation/Handling

Loading AJAX files and JS Scripts on the fly

Handling project specific problems like materials, scheduling, modules, resource loading, etc.

 

I'm not saying this can't be done with procedurally... but I can say with 100% satisfaction that it is much easier with OOP and my efficiency and organization has gone up exponentially. Being able to create all the pieces to the site before outputing it makes it much easier to add and subtract the pieces you want.

 

All I'm saying is you have absolutely no basis for what my project was, what my problems were. All I was doing was giving a poster some information based on my personal experience. There is no reason to always be a little programming snob.

[Jessica]

First of all, I think you need to calm down - I'm not being a snob. You keep attacking me personally saying *I* fail or I'm a snob. I haven't said one rude thing to you. Knock it off. This is a thread where people are going to post opinions and debate the merits. If you can't handle someone asking you to defend your posts without freaking out, maybe the internet isn't the place for you. Trying to be snarky and calling people "non programming computer science elitist" is rude and uncalled for. CHILL.

 

 

Secondly - ALL of the things you listed have to do with ABSTRACTION not OOP. Do you understand what abstraction is?

 

Having worked on too many "professional" projects that use OOP which are just as gluey and cobbled together as any newbie's procedural project, I can tell you that OOP does not magically solve any problems a beginner will run into. In fact, starting out trying to do a project from scratch entirely in OOP is going to cause more problems in the long run for the OP. Now, he said he's familiar with OOP from other languages, so he'll probably be fine. The scenario you described was a beginner to programming, who didn't know the difference between an object and a hole in the ground.

 

OOP is great. It can definitely help in a lot of ways. However, it's important to realize that it is not the be-all end-all solution to BAD PROGRAMMING. You can write crappy, messy, bad code in OOP easier than in procedural. You can write great code easier than in procedural. OOP will not fix a beginner's mistakes. It will amplify them.

[akphidelt2007]

When you say comments like...

 

"The problem in your application was not the lack of objects."

"Do you understand what abstraction is?"

"What you're talking about is abstraction, not OOP."

 

You have absolutely no clue what my project even was or my understanding of programming and you are already throwing out your snobby little comments.

 

What I'm talking about is not only abstraction. And abstraction is part of OOP. I have no clue what magical OOP you do.

Edited November 20, 2012 by akphidelt2007

[Jessica]

Whatever dude. Sorry someone pissed in your wheaties or whatever. 

[akphidelt2007]

Whatever dude. Sorry someone pissed in your wheaties or whatever.

 

It's all good. The programming elite get on my nerves sometimes. Not everyone is an expert programmer and it seems they forget that.

[Jessica]

It's all good. The programming elite get on my nerves sometimes. Not everyone is an expert programmer and it seems they forget that.

And being called an "elitist" and a "snob" gets on my nerves, oh, every time. "Expert" programmers have been there done that and MADE those mistakes, and it seems you forgot that. 

 

Drop the name calling and the attitude, and maybe you'll stop thinking of people with more experience as snobs and elitists, and realize that just like you, they're giving their opinion based on experience. 

[jcbones]

I shoulda grabbed a bag of popcorn before reading all these replies!

[bunnyali2013]

I am not a programmer, I am more on design side. I know PHP procedural and it will be in some weeks I will learn a bit about classes stuffs. One thing is sure, we have more people who code OO badly. Using classes in your codes does not mean they are OO, this is what a programmer with 15 years of experiences told me. He gave me an example!

 

Moreover, PHP was created in Procedural, this damn OO came in 2004. In fact it is not 100% true OO like other REAL OO based languages. As usual, there are more big-headed so called "programmers" as well. They are defining some classes, and voila, they think they have coded in OO. Most of them are poor in object design and pattern! I think this aspect to differentiate OO and Procedural is LAME. I asked this question earlier here on this forum.

 

In all these OO websites in PHP which exist, how many are TRULY OO? How many are good OO coded websites? I bet not more than 20%. Facebook was procedural in 2004 and small part OO. In 2006, they started making all the codes OO. In 2008 I think, they started using C++ to compress the PHP codes. We had good advanced websites in PHP procedural before OO took place. Nobody gave a s*** at that time! So why now? The web changes? Yes, only front-end, back-end remains the same!

 

OO can have advantages, but also drawbacks. It is damn difficult to start. Procedural also has advantages and drawbacks. I really hope Ruby, Python grow more even they will not. PHP is decreasing in number of use. Believe me or not, if major CMS were not in PHP, perhaps Ruby would beat it. I am sad of Coldfusion, another powerful and easy language which has died!

 

Personally, I think you should work what you think is good. Yes, learn OO if you don't know, but it depends on you and also it depends on the project.. As I am not a programmer, I don't care OO too much but I will learn it. I don't know what you are, but if you are planning to have a career as PHP developer (which I do not recommend you as back-end is really boring), then you have to learn OO.

 

 

Bear in mind, you don't find too much tutorials on OO than procedural even today. Procedural will continue to live like a BOSS. If procedural dies tomorrow, which is the origin of PHP, then I will leave PHP forever and may will do the same. Learning the same language which is based on two different styles is more difficult than learning one language as a whole!

Edited November 21, 2012 by bunnyali2013

[mostafatalebi]

Good points, thanks you! but just one thing!

 

When an application is spreading across and it beats off all those other adversaries, it must have been powerful. No one like God has vouchsafed it such degree of popularity. This is also true about PHP, if it has wider use than ColdFusion for instance, it is the very goodness of PHP that has made it to. There is neither lucky grading nor accidental success...

[Hall of Famer]

Come on you people just confused the OP. He already found his answer a while ago, the direction is to use a fully object oriented approach. Thats the way of future, dont you agree?

[Muddy_Funster]

Come on you people just confused the OP. He already found his answer a while ago, the direction is to use a fully object oriented approach. Thats the way of future, dont you agree?

You, sir, are pushing verry hard for me to get more warning points!

[mostafatalebi]

Come on you people just confused the OP. He already found his answer a while ago, the direction is to use a fully object oriented approach. Thats the way of future, dont you agree?

Yes I have found it! thanks...no more dispute

[Zane]

These seem to be the dumbest arguments since the Obama/Romney campaigns.  Either side claims that their way will change the future and that that of the other side will destroy everything as we know it.  I have yet to read an intelligent opinion on this case.  Furthermore, this argument has came up several times in the past here.  

 

If no one can come up with a decent "argument" for the pros and cons of OOP, the thread will eventually and inevitably end up in a flame war at which point it will be locked.

 

Someone put some effort into their arguments, provide some benchmarks, create some graphs, anotate a bibliography.  Do anything other than just sling insults back and forth.

----------------------------------------------------------------------------------

Just for the record and to add my input, I have never used OOP in a professional setting, only in the classroom.  I must say, OOP does have its advantages.  It keeps you from rewriting code, it allows you to use it over and over again, and given the proper nomenclature... Objects serve as a simple way to accomplish something that would normally be rather difficult.

 

What I do not like about OOP is that it advocates copy and pasting.  When I was in my C# class, the teacher would give us the code to connect to a database.  All of the students heavily relied on Copying and Pasting because throughout the semester we migrated from procedural code in the beginning and converted it into OOP in the end.  I will bet you anything though that none of those students actually know how to connect to a database today without looking through their old flash drives.  We were taught the use of Objects and that the ConnectionObject allowed us to create a connection to the database.  Several other Objects allowed us to retrieve and store that information.  We never had to write this code manually though.  It was provided for us and 99% of the class, including me, could care less how those Connection and Fetching Objects worked since we had them in our own classes and methods.  It wasn't until I started having to debug errors that I realized the fallacy of OOP.  If you simply copy and paste a bunch of code snippets you find out in wherever into a method named something like..  findNearestByZip, then when the code within that method fails you have no idea why.  You are left with the options of tackling it yourself, googling the error, posting in a forum or searching for a new algorithm altogether because you have no idea what you have copied and pasted.

[trq]

It wasn't until I started having to debug errors that I realized the fallacy of OOP. If you simply copy and paste a bunch of code snippets you find out in wherever into a method named something like.. findNearestByZip, then when the code within that method fails you have no idea why. You are left with the options of tackling it yourself, googling the error, posting in a forum or searching for a new algorithm altogether because you have no idea what you have copied and pasted.

 

None of that is OOP's fault. The same story could be told using simple functions.

 

One very powerful feature of OOP that tends to get left out of these arguments is inheritance. Without inheritance you tend to have to repeat a lot of code in larger systems. Thus making them even larger and harder to maintain.

 

For instance, where I work, we currently have about 2.5M lines of code (not all PHP) spanning around a dozen apps. We have a base framework and data layer that defines interfaces and implements a lot of the lower level functionality. Now, while each app has the concept of a *user*, and each app has very specific *things* these users need to *do*, they don't all get written from scratch for each application. They typically inherit functionality and properties from further up the tree.

 

This is just a small example of a *part* of our data layer. *Users* make up only a tiny part of our applications. I'm not even touching on stuff like routing or input validation or utilities such as those we use to keep track of changes to our development databases. We have an entire in house framework that handles producing documents in a reliable format fir printing. This framework alone has probably 60 - 80 *elements* that all extend off of a *base* element type. This sort of thing is much harder to do well using procedural code.

 

We have all sorts of functionality spanning multiple applications and classes. Without OOP we would have to duplicate a lot of code and have a lot more trouble maintaining such a massive code base.

 

Now, having said all that. OOP is *NOT* the be all and end all. A lot of projects / programs don't require this level of complexity. When they do OOP can often play a *part* in the solution. Procedural code however always has a role to play.

[Zane]

None of that is OOP's fault. The same story could be told using simple functions.

You are right.  It is the fault of the teacher and the ignorance of the average American student.