Just curious who here thinks a site should be 100% built in all classes, or who here thinks it should be built more using just functions ect.. i think classes are good for alot of things but not really to build an entire site out of them what does everyone else here thinks

ok

Classes are good for structure in applications built on an MVC architecture, but other than that, if it's a small scale site its not worth the original hassle of setting all that up for a few pages

we're using this thread now?

 

As an avid MVC practitioner, I always use OO PHP. I wouldn't like to tackle an enterprise level application using procedural code. At the same time, I wouldn't like to work on something some beginner has made using classes for the sake of using objects which don't follow any standard design pattern.

As a beginner to PHP what is the difference? What would you use OOP for? They have a good deal about it on lynda.com on an advanced tutorial but I'm just going through the basics first. Am I right in saying they don't cover it on w3schools or is it under a different section to PHP?

OOP vs Procedural....the difference is that OOP code is easier to reuse,maintain and extend and if you want to use a framework with your php project you will be forced to use OOP. But..and this is a big but...that doesn't mean that sites build with OOP are better than does build with Procedural code and it all depends on a particular situation. For example for a project I would trust more someone who is advanced programmer with procedural than a beginner in oop. It all depends on the project,sometimes it is better to use oop,sometimes it is better to use procedural..Wordpress is made using procedural php for example and there you go another myth busted that procedural is not good for large projects

OOP vs Procedural....the difference is that OOP code is easier to reuse,maintain and extend and if you want to use a framework with your php project you will be forced to use OOP. But..and this is a big but...that doesn't mean that sites build with OOP are better than does build with Procedural code and it all depends on a particular situation. For example for a project I would trust more someone who is advanced programmer with procedural than a beginner in oop. It all depends on the project,sometimes it is better to use oop,sometimes it is better to use procedural..Wordpress is made using procedural php for example and there you go another myth busted that procedural is not good for large projects

Well said also someone else that uses procedural is also the creators of phpmotion which is kinda like a youtube clone software.

phpMyAdmin is also written procedural if I am not mistaking ...this is the beauty of php that it doesn't force us to use oop like java or just procedural

I found procedural really easy to grasp but OOP is a wall for me. Maybe it's because I can usually achieve what I want with procedural so don't have the drive to learn OOP, but I drastically want to learn Objective-C (and now Objective-J!) but struggle to grasp more than the basics.

 

It's frustrating because everything else I've learned I picked up so fast.

I found procedural really easy to grasp but OOP is a wall for me. Maybe it's because I can usually achieve what I want with procedural so don't have the drive to learn OOP, but I drastically want to learn Objective-C (and now Objective-J!) but struggle to grasp more than the basics.

 

It's frustrating because everything else I've learned I picked up so fast.

 

Well Objective-C or C++ was hard for me too to learn, but in PHP things are a little easier with not having to kill your brains with the pointers...anyway you should really start with the absolut basics and do alot of examples. 1 way to learn is make something procedural and after try to write it OOP,it really helps alot training your OOP thinking.

Well Objective-C or C++ was hard for me too to learn, but in PHP things are a little easier with not having to kill your brains with the pointers...anyway you should really start with the absolut basics and do alot of examples. 1 way to learn is make something procedural and after try to write it OOP,it really helps alot training your OOP thinking.

 

Thanks. Retain counts also suck lol.

 

I've actually been spending my time reading back through the basics of php OOP, I think that on top of making my work more productive it will help with learning Obj-C. The syntax for php is much simpler and I think I've found a useful site.

 

My older projects could definitely do with a refresher!

OOP is really not difficult - in fact it's arguably a lot easier to use than procedural. It's not so much a technique as an approach to the task in hand.

 

unless a site is completely flat html - then I generally end up using classes for something. Sure, there's no need for a full fat MVC on a 5 page show and tell, but even something simple like implementing a contact form is made so much nicer by using OOP. Here's a really simple page controller.

 

the layout file

 

// mylayout.php
<!-- html header stuff -->
<?php 
// this variable will be generated in the controller, 
// and populated with the content from the output buffer
echo $content; 
?>
<!-- html footer stuff-->

 

a template file - this will get rendered into the $content variable of mylayout.php

 

//myFooTemplate.php
<div id="content">
<?php 
echo $content; 
?>
</div>
<div id="sidebar">
<?php echo $sidebar; ?>
</div>

 

 

define some base functionality for all the controllers to use

 

class Base_PageController{
   public function __construct(){
       ob_start();
   }

   public function render(){
       $content = ob_get_clean();
       include 'mylayout.php';
   }
}

 

extend the controller and write some custom code to reflect the various states of a page (i.e the various states of sending a contact form)

 

class Index_PageController extends Base_PageController{

public function route($request){
  switch($request){
       case 'foo':
         $this->doFoo($request);
         break;
       case 'bar':
         $this->doBar($request);
         break;
       default:
         $this->doFoo($request);
  }

   protected function doFoo($request){
       //whole bunch of calculating - i.e. if(isset($_POST['myForm'])...
       $content = 'lorem ipsum';
       $sidebar= 'You did something with Foo';
       include 'myFooTemplate.php';
   }

   protected function doBar($request){
       //whole bunch of calculating
       $content = 'lorem ipsum';
       $sidebar= 'You did something with Bar';
       include 'myBarTemplate.php';
   }
}

 

 

Finally, invoke the relevant classes and load your page

 

//index.php - just rinse and repeat for each of the pages on your site
include Base_PageController.php
include Index_PageController.php
$controller = new Index_PageController();
$controller->route($SERVER['REQUEST_URI'];
$controller->render();

 

Even for a single page this is a much cleaner way of writing your code - notice that you can re-use the $content variable because it is not present in the global scope...

 

*N.B: the output buffering in this example is untested, so it might not quite work out as intended, but you get the idea...

 

______________________________________________________________________

This email has been scanned by the MessageLabs Email Security System.

For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

At my current level most of my sites are procedurally based. I can see the advantage of the OO approach for reusability and extendibility though and probably will start to use that approach more as I advance my PHP skills. I'm not entirely comfortable with PHP's implementation of objects/classes being used to how Java works in that area.

I have only ever programmed using procedural php. I bought 'PHP Objects, Patterns & Practise' in order to learn Object oriented PHP, but I have not found time to learn it yet maybe in the next week!

...maybe in the next week!

 

...or in the next year...

...or in the next year...

 

...but most probably never

I'll explain OOP in a different way, as I think it puts OOP into context and its benefits and how it works into a meaninful way. It might get a bit long, but it should help getting the OO concepts to make sense and how they are meant to be used.

 

Edit: Wow that got long...

 

I learned the basics of OO in the 90's using C++ for simple applications. Later I created a few basic Java Applets which were also OO.

 

Where I came to fully understand OO and where it all truly "clicked" was with a game engine called Unity 3D. I've used Unity since version 1 a fair few years ago, its a 3D game engine for desktop, browser based and now iPhone and Android based games.

 

 

In that environment OOP becomes essential as the applications are complex, they are real time and there is a hell of a lot going on; even in a simple game. So I'll explain OO in that environment and then PHP.

 

 

Consider a simple 3D game set across 10 levels with a playable character that has to navigate around a 3D area that contains monsters. I think monsters in games explain OO really well.

 

 

Each level will have many monsters, there will be multiple versions of the same monster that have different attacks, different strength, different defence and different AI behaviours.

 

 

Like say an Orc, some use an Axe and are physically strong, some use a bow and arrow, like to attack from range and will hunt you down.

 

 

They will have things in common as well; they both use the same mesh, maybe different textures, they will move the same way, they share some common skills, they detect you in the same way.

 

 

Here we have how OOP works and comes into its own...

 

 

You have a real time, 3D environment. You have two types of Orc (Axe Orc and Bow Orc). They are both orcs and if you created them as unique objects they'd share the same code (repitition) so you'd create an Orc Object (class) and have two child classes (Axe Orc and Bow Orc) inherited classes.

 

 

In OOP you can create parent classes and child classes that inherit everything from its parent. Like so:

 

 

Class Orc
{
  ... Behaviours that are common to all orcs regardless of type, i.e. the mesh, animation details, how they detect the player, base HP and defence ...
}


Class AxeOrc extends Orc
{
  ... Behaviours that are specific to Axe Orcs such as "Axe Blast" attack, additional strength modifier ...
}

Class BowOrc extends Orc
{
  ... Behaviours that are specific to Bow Orcs such as "Ranged Attack", additional agility modifier ...
}

 

In this example, using OO allows you to create an Orc class and then child classes for every type of Orc. This allows you to cut the size of the code down, have global behaviours contained in the parent and behaviours that are specific to a certain type of Orc in child classes.

 

This simplifies the code and reduces code repitition.

 

 

 

Using functional decomposition, this scenario would be more complex and you'd have code repitition:

 

 

function AxeOrc
{
  ... Behaviours that are common to all orcs, i.e. the mesh, animation details, how they detect the player, base HP and defence ...
  ... Behaviours that are specific to Axe Orcs such as "Axe Blast" attack, ...
}

function BowOrc
{
  ... Behaviours that are common to all orcs, i.e. the mesh, animation details, how they detect the player, base HP and defence ...
  ... Behaviours that are specific to Bow Orcs such as "Ranged Attack" ...
}

 

In this example the two functions are almost identical with subtle differences. You have a lot of code repition.

 

 

Now lets say you wanted to add a new skill to ALL types of Orc. In the OO example you'd add the new skill to the Orc class and all child classes would automatically gain that skill.

 

In the functional decomposition example you'd need to add the skill to ALL of the Orc type functions.

 

 

Also in OOP the functions for Orc's are contained within the class which nests them together in a tidy little package.

 

 

So class Orc would have a bunch of functions for Orc that only Orc objects can use.

The child classes would contain a bunch of functions that only say AxeOrc can use.

 

 

Now consider this, you have "grunts", some of them have an Axe and have an attack called "Axe Blast", but its totally different from the Orcs.

 

In OO you'd have:

 

class Orc
{
}

class AxeOrc extends Orc
{
  function AxeBlast()
  {
  }
}

class Grunt
{
}

class AxeGrunt extends Grunt
{
  function AxeBlast()
  {
  }
}

 

 

There you have two functions of the same name in two different classes, in functional decomposition you'd have:

 

function OrcAxeBlast()
{
}

function GruntAxeBlast()
{
}

 

This is messier.

 

 

 

Now for another concept, instantiation. In OO you can create unique instances of an object (class). So you can create say 10 instances of AxeOrc, they are all unique, independant instances. This is a major concept especially in a real time application where you have have multiple instances of the same object appearing, disapearing and reapearing in different places.

 

Then different instances can have slightly different behaviours themselves, say different route finding etc.

 

 

I think the benefits of OO speak for themselves here, although its a simple "application" it is quite complex and performing these operations using functional decomposition would be very, very messy.

 

It's this kind of scenario that OOP was devised to tackle. Scenarios where you have multiple instances of the same object, behaving in different ways and being independant of one and other in a real time or semi-realtime environment where stuff is changing a lot.

 

 

Even in a game using Unity you're not ALWAYS using OOP, you have functional decomposition too. Some things lend themselves to OOP and others to Functional Decomposition.

 

Also consider a full game, how much is going on, the massive amount of variables and data thats being passed around, how many objects are appearing, how many different types of object appear and how you have "variants" of the same object or objects that share common functions.

 

OO lends itself to this scenario.

 

 

PHP is different, for one it is by design procedural (hence why I used the term functional decomposition). Even an OO application in PHP is procedural, its not that fluid and is not ever changing, its all pre-processed and ran through procedurally.

 

 

It's also rarely having to deal with incredibly complex problems, at least not in the same way as a game or big desktop application like Adobe Photoshop.

 

In things like games or big desktop applications there are lots of scenarios where functional decomposition either doesn't work or doesn't work well. There is almost always a way to do it, but that way is going to be a hell of a lot more complicated and repetative. The code will also not flow as well.

 

 

Also some myths...

 

1. OO does not make cleaner code, Functional Decomposition does not make messy or spaghetti code. You can have clean, easy to read, well formed code using both methods. You can also have messy, spaghetti code using both methods. Thats all down to the programmers, how they structure the application and how well designed the application is.

 

 

2. OO does not make code read better, Functional Decomposition does not make code read poorly. This is entirely down to how the programmers name their classes or functions. Both OO and Functional Decomposition can be virtually unreadable, they can also be very readable and self explanitory.

 

 

3. OO does not remove code repitition, Functional Decomposition does not create repitition. This too is down to the programmer. Using both OO or Functional Decomposition you can have repitition or reusable classes/functions.

 

 

4. OO does not make code extendable, Functional Decomposition does not make code difficult to extend. Again its down to design and how the programmers create their classes and functions.

 

 

However in certain environments such as games and complex desktop applications using OO lends itself to making code cleaner, more readable, less repetative and more extendable provided the application is well designed. Functional Decomposition in certain environments (such as the Orc example) would lead to repitition and poor naming convention, extension would require changes in many placed by default.

 

 

If we consider a PHP application, even a complex one like a forum, if your application is designed well and you consider readability and code structure then you're not really going to gain all that much from OOP over Functional Decomposition. Not in any real, quantifiable terms anyway.

 

 

There are no technological benefits with PHP applications, code can be very readable either way (or unreadable), code can be reused and extended easilly either way (or un reusable and unextendable).

 

 

This is because, quite frankly most PHP applications just are not that complex, not in comparison to say Adobe Photoshop or Grand Theft Auto IV. There is a lot less going on, things are way more linear, things are not ever changing, you don't have that many variations of the same thing with broad behaviour differences, functions just aren't ever that big (a complete monster controller in Unity with full AI & pathfinding would make wordpress look like "hello world").

 

 

Take a blog, you dont NEED OOP to make it work well, be structured well, flow well, be meaningful, be extendable etc. etc.

 

 

i.e.

Users, quite simple, even with user groups.

Categories, again quite simple, little variation.

Blog Posts, again very simple things with little variation.

Comments, again very simple with little variation.

 

You don't have many types of blog post or category or comment or user with many different behaviours, things don't suddenly appear as the application is preprocessed. In this environment OOP does not really give you anything.

 

 

That said, I use OOP, but not in a pre sense. Our internal framework for example uses OO for the folloing things:

 

1. The bootstrap that ties everything together

2. Database connectivity (as that supports multiple types of database)

3. The template engine

4. Users and usergroups & permissions

 

 

These don't even need to be in OO though, the functional version is just as readable, just as extendable and performs much the same way. In fact the code looks and is structured very similarly (mainly due to how the functional decomp version is structured deliberately to be reusable and extendable).

 

We use then create new classes for complex datasets, but not for functionality all the time. Its just needed nor beneficial.

 

Having an OO platform doesn't give us anything over functional decomposition.

 

So bottom line, your choice. Its PHP, a procedural, preprocessed scripting language used for what are in effect simple web based applications. Go with what you will do a better job with.

 

Sometimes however the application will have specific features that lend themselves to OO, that does not mean the whole thing must always be OO. It also does not make you a bad or amateur programmer if you don't use OO.

 

It would if you were making a game in Unity or a complex desktop app, but not in this environment as its not required and you don't gain anything from it.

Edited December 20, 201015 yr by FizixRichard