Yes I have found it! thanks...no more dispute
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?
Object Oriented Programming Or Traditional Coding?
Posted 22 November 2012 - 09:41 AM
Autodesk Maya, Autodesk Mudbox, Nvidia Mental Images Mental Ray, Adobe Photoshop, Adobe Illustrator, Adobe After Effects, CorelDraw
Posted 22 November 2012 - 09:48 AM
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.
Posted 22 November 2012 - 10:51 AM
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users