Do you REALLY need to use oo


I would like to create a simple blog in PHP but am new to OOP so could I get away with using procdedural PHP.

Am I right to think that OO is only useful if it is really understood.


If you want to learn OOP then this could be the right time to do it - starting on something simple will make the learning more bearable.

Obviously the more you learn about OOP (much like anything), the more you understand and can accomplish with it, but you gotta start somewhere right?

Of course not. You never NEED to use OOP, but it does make some things a whole lot easier if you use it right and and put your code together well.

That said, OOP is definitely worth learning. After using OO code, I would never go back to all procedural, because I would miss out on all the great benefits I depend on every day now.

Sure it is optional, but it is awesome. You should learn it. You won’t regret.

OOP is one of those things that seems a lot harder than it is. It’s not a new language, it’s a different way of structuring a language you (may) already know…

OOP, if done well, is pretty damn helpful. It makes difficult problems fairly easy to solve. That being said, it is only one aspect of programming methodologies and it happens to suit applications very well.

Alot of people will advocate that a huge benefit of using OO is the ability to reuse. Although this should not be your initial intention, it is merely a side-effect of proper abstraction layers and a good clean design.

Object-oriented representations do not appear to be universally more usable or less usable.

“It is not enough to simply adopt OO methods and require developers to use such methods, because that might have a negative impact on developer productivity, as well as the quality of systems developed.”

Which is from “On the Usability of OO Representations” from Communications of the ACM Oct. 2000. The articles mainly compares OO against the procedural approach. There’s lots of study of how people who work with the OO method “think” (Int. J. of Human-Computer Studies 2001, issue 54, or Human-Computer Interaction 1995, vol. 10 has a whole theme on OO studies), and from what I read, there’s nothing to indicate some kind of naturaless to the OO approach that makes it better suited then a more traditional procedural approach.

I agree that OOP is not a new language, however writing well designed OO applications makes the difference between a script kiddie and a programmer.
The design choices and principles that you implement in your code make the difference between code that is reusable and flexible. The biggest factor that you need to account when creating any application in OO-PHP is change. This means making the right choices and coding to interfaces or abstract classes rather then implementations of the code. It also means grasping concepts like encapsulatioin properly and realising that it goes beyond the scope of simply having member properties of your classes set to private or public.

OOP is a great concept to get into, however it takes a lot of practice to write good reusable and flexible applications.

Anyway, that is my 5 cents.


If you are new to OO, I’d say give it a go first. Then read the book “Refactoring” (Martin Fowler) as early as you can.

OO has the shortest distance from stakeholder to keyboard. You can usually identify some candidate objects straight away, and if you get them wrong, it’s easier than most other paradigms to jiggle stuff about until you get it right.

It lacks the rigour of say a relational database model or functional programming. This can make it easy to get into a tangle if you are inexperienced, or don’t learn good conventions.

yours, Marcus


OOP has nothing in particular to do with C.

yours, Marcus

The first thing to realize is that good programming is good programming. You may know this already, but OOP is simply an extenstion of the procedural programming which came before it. “OOP languages” are simply programming language (like Java, C#, and PHP) which provide features and tools that allow you to maximize the value of the OOP technique. So OOP is simply what the procedural programmers developed to make their lives easier, and the result is that I absolutely recommend it. I can tell you that “I” certainly enjoy making my life easier. :slight_smile:

There are two ways to approach OOP. One is to design an OOP application, and this is the way that “OOP programmers” do it, because it actually helps you plan and get things right. That’s the beauty of it; it actually helps you program. That said, there is a simpler way. It may be easier for you when you’re getting started, so let’s start simple.

OOP programmers tend to throw around a lot of intimidating vocabulary (inheritance, polymorphism, interfaces, classes, objects, instantiation, etc.) However, like most things half the value of OOP comes out of the really big guns; you can write some real sanity saving code just by following the concept of abstraction and then encapsulate, encapsulate, encapsulate.

If you’re not familiar Abstraction - it rocks. It’s the ultra powerful concept of tying your low level programming code (if-else conditionals, loops, variable assignements, ie things that live inside computer world) to real world concepts you have more experience with (users, databases, sessions, passwords, etc.) Encapsulation means taking a set of instructions out of a chunk of code, and separating it out on its own, and then adding a call in the chunk of code to the newly separated (encapsulated) instructions.

The lowest level of encapsulation is when you see a reusable set of instructions. Maybe it’s something you know you’re going to have to write again. Maybe it’s lines of code you’ve already written one or more times. When you realize this you’ve found an opportunity to encapsulate a function. Create your new function and insert the lines of code inside the function. Then remove those lines of code from anywhere you’ve written them and replace them with a call to the new function.

Functions tend to be pretty low level, and usually deal with some integers and/or some strings, and/or making variable assignments and/or running a loop, low-level computer kinds of things. You will find that as you continue writing, you’ll find opportunities for a whole new level of encapsulation. You’ll find a particular task that you need to do multiple times, not a low level thing, a high level real world task (but just one) sending a username to the database and retrieving the hashed password. This is something you may need to do in a number of places. So instead of writing that code in all those places you create a new function like retrieveHashedPassword(string inputUsername). This will have a series of low level functions inside it which take care of the implementation. The trick to good application design is to make sure that these tasks are highly cohesive, ie they should only do ONE thing. Otherwise you introduce too much confusion.

Everything we’ve touched on so far is simply good programming. You do this in procedural programming, you do this in OOP. You don’t do these things because you follow a particular methodology, you do these things because it helps you write programs that make sense so you can keep your sanity as you build it (and especially as you try to improve it and maintain it later!). What makes OOP languages different is that they introduce the idea of the “class”. In the same sense that a high level function encapsulates a lot of stuff that goes one inside, you use a class to encapsulate a group of high level functions.

A class handles one, and only one, responsibility. Responsibilities are real world abstractions; you may have a class that handles “Security”, and another class that handles “Data Access”, etc. All of the high level functions related to security go into the security class, all the high level functions related to data access go into the data access class, etc. For simplicity, you’ll find that classes are frequently named things like SecurityManager, SessionHandler, or DataAccessLayer. Names are a critical way to write your abstractions into your code and make it more understandable. Basically, this is a bottom up approach where you write code to do something (which may be more familiar to your procedural style) and start encapsulating your way up.

As you get familiar with the kinds of structures you need to build your application, you can start working from the top down, by designing your class structure, then figuring out what high level functions you need to execute, and finally executing the low-level functions which actually get the job done. This is the reverse of what we just did; you can start at the top and work your way down. This is usually MUCH easier because it lets you deal with real world things and in a small project like this, those will probably be your classes (in bigger applications they’ll probably be layers and/or modules which encapsulate classes). Then you can start breaking each one down into component parts. Those are the kinds of things you might try now, but at the very least, its something to be thinking about as you’re encapsulating your heart out. :wink: