homepage Welcome to WebmasterWorld Guest from 54.205.207.53
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
Procedural or object oriented programming?
Thoughts?
cffrost2

5+ Year Member



 
Msg#: 4448208 posted 2:05 am on May 2, 2012 (gmt 0)

I learned procedural programming as a basic. But have starting wondering in the world of object oriented programming. I've knoticed a lot of great scripts are written in object programming. Is there a benefit to that over procedural or is it just a matter of taste? Seems to have a greater security strength over procedural but I'm not for sure. I figured I'd get the opinions of some pros. I've started a new detailed admin based site for a client and have found uses for both types of programming.

Thanks for any input.

 

g1smd

WebmasterWorld Senior Member g1smd us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4448208 posted 2:08 am on May 2, 2012 (gmt 0)

I've used Object PHP styled code for a couple of years. It's often a sledgehammer to crack a nut, but the simplicity of using functions and using $object->getID() style requests can make the program much easier to understand and to bug fix.

cffrost2

5+ Year Member



 
Msg#: 4448208 posted 2:17 am on May 2, 2012 (gmt 0)

Thanks for the reply g1smd. Any1 else?

jinxed

5+ Year Member



 
Msg#: 4448208 posted 6:27 am on May 2, 2012 (gmt 0)

If you have thousands of lines of code, then it would certainly make sense for maintenance reasons - plus helping anyone else who may ever edit the code on your behalf.

enigma1

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 4448208 posted 1:33 pm on May 2, 2012 (gmt 0)

It depends on the application and functionality. If you have a number of functions aimed at a specific area with common access then you could create a class and so other code utilizes its member functions and interface mechanisms.

If one on the other hand you have a sole function that's commonly used by the application I wouldn't force it to be in it's own class, I would just leave it as a global function.

Projects are dynamic in nature so new code can be added and depending on the requirements set of functions can be turned into classes later on. You don't have to push everything to be a class right upfront.

rocknbil

WebmasterWorld Senior Member rocknbil us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4448208 posted 4:00 pm on May 2, 2012 (gmt 0)

It's often a sledgehammer to crack a nut


Agreed . . . and what I've found is the class methods are often more confusing than direct methods in a procedural framework. For example, a query using a class for database connections might be like

$result = $db->query($query);

To get to this point, you have to learn all the functions in the class, learn all the parameters it expects, what format to send them in, what return values to expect . . . and have to do this for every class you use. We've already learned PHP, and now we have to learn the language of the classes we use, and it never ends. With every class you incorporate, you have to learn a whole new sub-language.

$result = mysql_query($query);

Another aspect of OOP I don't like is many classes I've worked with lack customizable function or output. Say you have a class that works perfectly for what you want but outputs tabled layout or invalid HTML (don't laugh. I've seen it.) Do you hack the class, or find another, and how much time do you spend doing that in the interest of thumping your "must be OOP" doctrine? Personally there's nothing I find more frustrating than modifying someone else's code, trying to thread through their logic, just to get the output that I want or that the project requires.

If you have thousands of lines of code . . .


This can be false (although, in many cases, it's not.) I use a method that is inherently procedural, but pares off most of it's coding in functions, which moves toward the advantages of OOP, but it's still considered procedural.

Let's say the entire program is this (which it usually is)

if (isset($_POST['function'])) {
$func = $_POST['function'];
$func();
}

else if (isset($_POST['display'])) {
output_html($_POST['display'],null);
}

else {
output_html('entry_page_html',null);
}

That's it, the entire program "controller." From this you can see we have one function (output_html) and another that may be a variable function* based on input. For output_html, the required parameter is the page state/title, an optional error parameter, and has no return value; it outputs and exits.

The variable functions can be anything, for example, "ud_db" which may map* to an update database function. When complete, this function will call output_html again, and pass a title and possible an error variable. Within this function, I may call many other functions - for example,

$input_errors = cleanse_input_data($_POST);

which is a function that can be used from almost any other area of the program.

Functions, like classes, are "black boxes." You pass a value to them, and they usually return a value. They must stand on their own, without depending on global variables to function, and must contain their own internal error handling (that is, it the parameter values are of the wrong type you need to handle that condition.)

But still, it's basically a procedural way of working. Purists would discount this method and say "it should be OOP, that's what real programmers do."

Sometimes OOP is just overhead.

* Of course, the raw post input is always cleansed and filtered, and you'd never want to reveal a function name in a public query. Generally I map these to "allowed values" in a global include.

Wittner

5+ Year Member



 
Msg#: 4448208 posted 4:06 pm on May 2, 2012 (gmt 0)

I learned my programming in the procedural style. I have tried over the last year or so to code in OO style. I found it difficult, but what really helped was using a framework. I chose CodeIgniter because it was light and didn't force me to be too strict about my code style. It allowed my to see the advantages of OOP and MVC as a pattern.

It completely changed my style of coding, made all my scripting MUCH easier to trouble shoot and allowed me to get into the OOP concepts gradually. I highly, highly recommend it if you've been procedural up to now.

There are a lot of libraries available for CodeIgniter and a very active community. I know this sounds like an ad for CodeIgniter but really I'm saying get involved in OO to make your apps tidier, smaller, more understandable and easier to maintain, and you could use CodeIgniter to help you along the way.

Mike

cffrost2

5+ Year Member



 
Msg#: 4448208 posted 1:50 am on May 3, 2012 (gmt 0)

Thanks all. Good stuff to think about and consider. I'm really not sure if I want to get too deep into this whole OOP thing but it seems to be a "new standard" now. Lots of good scripts are written this way. I even had some clients ask me if I can customize some of them to their needs. Some yes, but some "maybe". The time involved in customizing a pre-built OO style script may not be any better than to just start scratch and build it custom. I'm comfortable in the procedural style and don't see a real reason to jump on the "new bandwagon" but never say no to learning something new.

I'll take a gander at CodeIgniter. I've heard about it but have no experience with it. I'll see if it's something I can use.

I appreciate everyone's input.

eelixduppy

WebmasterWorld Senior Member eelixduppy us a WebmasterWorld Top Contributor of All Time 5+ Year Member



 
Msg#: 4448208 posted 12:43 pm on May 3, 2012 (gmt 0)


Say you have a class that works perfectly for what you want but outputs tabled layout or invalid HTML (don't laugh. I've seen it.) Do you hack the class, or find another, and how much time do you spend doing that in the interest of thumping your "must be OOP" doctrine? Personally there's nothing I find more frustrating than modifying someone else's code, trying to thread through their logic, just to get the output that I want or that the project requires.


IMO classes or functions should not be returning formatted HTML. You want to remove "presentation" from "business" logic. Additionally, one of the benefits of object-oriented programming is the concept of class extensions. It would be better to write your own class in this case that extends the original class, and you can override the methods you want to change the behavior for.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved