Procedural coder... trouble understanding where to use OOP

[pkbarbiedoll]

Great tutorials, working through the OOP lesson now. I've coded procedurally for over 7 years and am fairly proficient at the style. Includes contain functions, with separate include files for different tasks/sections (functions_security.php, functions_news.php, functions_calendar.php, ect). I reuse as much code as possible, sometimes taking a slight hit on performance to achieve reusability.

 

The sites I work on now are of course, written procedurally. I am interested in starting to implement OOP methods, but every time I look at OOP tutorials, I shy away.. I can write "hello world" in far fewer lines of code procedurally, than with the complexity of classes, properties and methods.

 

What am I failing to see? I think the Killersites OOP tutorial is great, no complaints about the way the material is covered. But where is the incentive to turn a 300 line app into 600 lines with extra complexity? Is it just for the sake of being abstract and using the latest buzznology?

 

Really hoping someone can steer me in the right direction.

[pkbarbiedoll]

Anyone want to take a shot at the post above?

 

Put into a different context.. say I have a news page written procedurally. Several actions are available:

 

view news list

view news article

add news article

edit existing news article

 

In this theoretical page, I have a single news.php script set up with a switch statement controlling each action.

 

switch($action)
{
  case 'submit_article':
    // sql to update / insert article
    break;
  case 'edit_article':
    // show form to edit article
    break;
  case 'view_article':
    // show single article
    break;
  case 'view_article_list':
    // show list of all articles
    break;
}

 

So how would this example best be done in OOP style? I'm so used to writing procedurally, I'm having trouble seeing the benefits of using objects. hoping someone can explain in a way I can hook into..

[LSW]

When to use it? Always.

 

So, web design forum so I assume you are doing web design. Procedurally speaking, it is like writing a full HTML page including everything. OOP is more like modern web design, Look & Feel is separated from structure, do it right and you can completely change the look of the web site any time by switching style sheets. So we have two objects and one object can be modified without touching the other.

 

Includes are another example. Create single pages for a 5000 page web site, then change the navigation... and you have to change it on 5000 pages! So you use includes, now the navigation is separate from the page, so add a link & you change one file and 5000 pages show the change.

 

That is what OOP is all about.

 

For programmers in the real world OOP translates into:

• If I build an application in objects, I can reuse objects in other programs, just add it to the mix. This is good for navigation, logins, search capabilities etc. Programming for the Stater of Alaska, every application I create in Flex will need certain objects required by the state or my Department.
• Large applications may require team development, I may work on an object that will do this while someone else works on another object.
• Procedurally, you write a script that is 1000 lines long. Much like web design, there is an error showing for line 523, but the actual error is on 47. You have to back track through most of the script to find the error. When using objects, you can figure out easily which object has the error and have less code to sort.
• Inherit an application, I have and your left trying to figure out the idea behind things. Objects are smaller, so less code to try to undo and search through. Also as common ones would be re-used. Ooops, the login is corrupted. Delete it and replace it with one that does work. (Documentation is awesome too! I am trying to recreate Paradox and Access applications with no documentation so I have to guess what is happening.)

These are just a few reasons why and how to use OOP. For the non programmers, is is really just making applications modular.

 

The other good idea is a 3 teer system. Data base, business logic, interface. Database is the database itself and the scripts needed to interface directly. Business logic is the logic behind what the application really does, so calculations and sorting etc. Interface is the structure and Look & Feel, the actual GUI - User Interface. Keeping these things separate makes for better programming. NO business logic in the interface.

 

This last peace I added for those new to it all.

[LSW]

Just read your first post. In my view you are already using OOP in the fact that you are using includes as an example. OOP just carries it out further. I guess my above post is not quite helpful. I learned it and used it but that was quite a while ago. In my programming now I guess I am still using it, just no one here uses the term. I think it is more for PHP users etc.

 

In the end when I create a Flex app, I still use classes and teers. I will use Java classes along with Action Script classes. But at this level, working in a solid programming environment with actual trained programmers (I'm a web guy), it is simply how programming applications and the like are done by smart people and professionals. OOP is just taking the base programming concept and adapting it to newer uses like web sites and languages like PHP etc.

 

To put it bluntly mate, ignore everything I have written before this last line. I don't think I explained it well to you... just other readers with positively no idea. Sorry

[falkencreative]

Here's my view on it... And, as a brief disclaimer, I'm primarily a front end coder/designer, but I have been doing a lot more back-end PHP work recently.

 

I don't think OOP is the solution to every PHP programming problem. If you can do something procedurally in 10 lines, whereas using OOP would require 20 lines and wouldn't have any significant benefits, definitely go with the procedural solution. I think the difficulty with many beginner OOP lessons is that they start with a "hello world" example of some sort, which while important for a beginner to understand the syntax and such, doesn't really show the power of OOP. In my experience, OOP is best suited to medium/large PHP applications. If you have a simple problem to solve, pick the simple solution.

 

The way I see it, OOP has a couple of key advantages:

 

-- Abstraction/Encapsulation: It provides a clean, efficient way to sort and organize your code, making it easier to maintain, and for others to work with. Like LSW said above, it helps reduce dependencies between components, makes things more modular, and makes it significantly easier to refactor your code if necessary. This is especially useful on large, complicated projects and/or projects that have several different people contributing to the project. Using procedural programming, a programmer may need to understand the full/significant portions of the application in order to make changes. With OOP, their work may be more modularized and they can work on specific pieces of the functionality without needing to understand everything. Plus, they can use the code used by others without having to fully understand the implementation details.

 

-- It helps make code more reusable, allowing you to reuse your objects in other PHP applications (though you could probably say the same thing about cleanly structured functions though.)

 

-- Using OOP (at least in my experience) seems to encouraging good coding practices, like separating PHP logic from presentational HTML, the DRY (Don't Repeat Yourself) principle, etc.

 

-- Use of inheritance to create objects based on parent objects (plus polymorphism/overriding functions - though, to be honest, I don't really use inheritance much, but it can come in handy in certain situations.)

 

This might be a useful topic to look at (though it devolves a bit at the end into a argument, but it may help you just the same): http://forums.devnetwork.net/viewtopic.php?f=19&t=94603

 

also: http://stackoverflow.com/questions/2035449/why-is-oop-hard-for-me

[kraxzy]

Anyone want to take a shot at the post above?

 

Put into a different context.. say I have a news page written procedurally. Several actions are available:

 

view news list

view news article

add news article

edit existing news article

 

In this theoretical page, I have a single news.php script set up with a switch statement controlling each action.

 

switch($action)
{
  case 'submit_article':
    // sql to update / insert article
    break;
  case 'edit_article':
    // show form to edit article
    break;
  case 'view_article':
    // show single article
    break;
  case 'view_article_list':
    // show list of all articles
    break;
}

 

So how would this example best be done in OOP style? I'm so used to writing procedurally, I'm having trouble seeing the benefits of using objects. hoping someone can explain in a way I can hook into..

 

 

Actually the code would be very similar, but the way about how you go around coding it would differ. As it's another mindset really.

 

Here you would for example solve it in a oop way of thinking, what kind of objects would I need to fulfill this task?

Well I need a page, so maybe a page object would be needed.. Then I need an object that keeps track of my different pages maybe so a page-controll, maybe a specific object that acts as an interface dealing with user input, maybe I want more generic page objects thus I make an special interface that the database interacts with.... and so on.

Then maybe some helper objects and some task-specific objects that utlize the generic objects into solving your task.

 

So you might ask but that's a lot more memory and resource consuming concept.. the answer is yes it is.

However in larger projects it really works well, as you encapsulate most code into classes and create packages wich only work to solve special task. And if you code well you will have a lot of generic classes and packages that you then can reuse in other projects.

 

In your example you have project specific code, you got code that only works in your project, you wouldn't be able to pull that example code and use it in another site without having to recode at least the sql part. In a good OOP solutions you would be able to just copy every non project depended class and just write the ones missing saving you time.

 

Now this is a small example and you can't really see the benefit as you can justify just switching the small ammount of SQL depended code, but think of thousands of lines of code and hundreds of files of function libraries etc, and in some degree you always get nested code that go back and forth which would mean a lot of changes and pretty horrifying to move and readapt on a completely new project.

 

I've been involved in such projects, they were a nightmare and at the end of the day you had to recode most of it as it many times was faster to just code it again than having to go around looking and collecting the dependencies in different files.

Now all of a sudden the OOP solution would have been a gift from god, as you would just pull the packages needed for the core and behavior and any other task specific class. Then instantly proceed with coding the project specific classes and you are done.

 

And at that time you would also have a good knowledge of the object functionality in house, or at least a good documentation a long with code that has already been proven to do it's job well in previous projects.

[SteveWasiura]

i think pkbarbiedoll has been scared away. overwhemled.

[administrator]

Hi,

 

One article on why you'd want to use OOP.

 

... I've done videos on it too - just can't find them.

 

 

Stef

[LSW]

I just went through training on creating Use Cases, especially in an OOP environment. We discussed what OOP is as many in the class were not programmers but Program Managers. Maybe his explanation will help someone.

 

He used our class as an example. It was made up of people. So you would have a people class with all the defaults each of us has, say we are all state employees, we are all human. Each of us is an object however, we are a single instance of the class.

 

By using classes you can specialize objects. I am male, I am employed by the retirement division where many others were from Dept of labor. I am a student rather than a instructor. So you can have sub- classes to further specialize other general descriptions of the class.

 

However in the end I am LSW, My name is Kyle, I have dark hair, I speak German and I live on >>> street. So as an Object I am a different instance of the class people than the person next to me.

 

With OOP I can now be replaced. My object, my instance of the class people can be removed and the class would still carry on. The instructor instance could be removed, it would make things difficult, but the class would still function.

 

So with OOP you are modularized, you work with general classes and Objects which can be modified as they are a singular instance of the class. However when you change an object, you change that object alone, not the class it belongs to, so by changing the object Kyle, you do not change the object instance called Jeremy.

 

Thus you can create, edit and delete objects with no complications for other code.