Have I missed the point of object oriented programming?

Question

Recently, I took it upon myself to try and learn OO programming. It has been about 3 months since I started, but I think I might be missing the point because I seem to prefer static methods (which seem 'easier' to me).

Example

Here is what a typical DB query looks like in my code.

$bindings = array(':name'=>$articleName);

Db::query('SELECT id, name, title, image, content FROM ' . CONFIG_MYSQL_TABLE_PREFIX . 'articles WHERE name = :name LIMIT 1', $bindings);

And here is how I resize/crop/cache images

$image = Img::thumbnail($imagePath, 200);

$imgHtml = '<img alt="' . $this->getTitle() . '" src="' . '' . $image['src'] . '" width="' . $image['width'] . '" height="' . $image['height'] . '" />';

Both of the static methods utilise a singleton pattern.. the first one creates one PDO object and the second one creates one ImageResize class I found on Google code.

Should these be 2 objects if I really wanted to call it object oriented programming? i.e.

$db = new Db();

$image = new Image($src, $width, $height);

For everytime I use them? I've read singletons are also a bad idea unless they're being used for logging to a file. But isn't a singleton good for one DB connection being opened when needed and closed only after it's been used and finished with?

My question is, am I still stuck in the procedural mindset, and if so, is what I'm doing considered bad practise? How can I immerse myself in the correct OO thought patterns?

Update

Thanks for the answers. I do find the original methods I'm doing are easier as I have to type less code and let the static methods worry about little implementation things.

I will look into another language to get a solid grasp of OO, which language though will be another question itself.

Answer 1

the best way to grasp object oriented programming is to think of objects passing messages to each other, not objects calling functions. i had this "eureka" moment when I learned Smalltalk.

there are principles that apply to OOP such as the "tell don't ask" principle and others. use your favourite search engine to look for those principles.

an abundance of static methods are, in my opinion, a sign of being stuck in a procedural mindset. sure there are scenarios where they really make sense but if your code has more static methods than instance methods i'd say you're not doing things the OO way.

Answer 2

you might find it easier to grasp the ideas more firmly in a language that supports OOP as the main paradigm... not that you can't do it in php or perl or whatever, it's just not as easy because there are few guardrails and encouragements

languages aside, it may also be the case that the kinds of things you are doing right now don't really require OOP; if so, don't sweat it, play with OOP on other things.

Answer 3

I don't use OO for the sake of using it. If I have to write a small program I prefer procedural approach. Using OO in smaller things can only complicate the problem or even if it doesn't it won't count for an advantage over procedural approach anyway.

But, if we are looking at a bigger problem involving many entities sure thing make a good class diagram and design to make realise and use the real power of OO. Use OO whenever wherever necessary; just don't apply OO in smaller problems for the sake of it.

Answer 4

Well, imho PHP is a bad example for this because PHP is not object-oriented. Yes it has objects. Yes they support inheritance and all those OO principles. It supports objects. There's a difference.

I say this because PHP doesn't by default exist in a state between requests. Every single HTTP request will completely recreate a PHP environment from scratch (which is reasonably cheap), meaning there is no static data persisted between requests. You might say "what about session data?" (and maybe append an "a ha!') but that isn't persistent data in a PHP sense either. It's (typically) stored in the filesystem and keyed by a cookie the client sends.

Why do I mention these two things?

Because the "global" scope in not like the global scope in C, Java, C++ or these other languages because they tend to persist between requests. PHP is more like the CGI programming model from the 90s (which is no coincidence because that's where it originated).

So your objects aren't truly global: they are simply visible to all parts of the code servicing the current request.

To me, that's nowhere near as bad. In fact, I often find it quite acceptable. Sometimes it's every necessary (eg in a callback to preg_replace_callback if you want to send information back to the caller or pass state to the callback without doing eval()/create_function() hacks).

And the point about PHP not being object-oriented is because even in PHP 5 OO features are still somewhat "tacked on", meaning you could quite happily code away and code well in PHP without ever using them. This is different to, say, Java where you have to create a class even if all you do is write a bunch of static methods in it.

So if you want to learn OO, honestly I wouldn't do it in PHP. PHP is good for a lot of things but it's designed to have an HTTP request lifecycle (yes I know you can run it from the command line but that's not what the vast majority of users do) and it's quite good at the job it's designed for.

Answer 5

What OO helps with is managing state in an imperative environment.

To take the two examples you give, firstly Db::query, behind this I'm guessing is some database connection with it being a static method this means that everywhere in the software you're developing it's either:

• Contending locks
• Has mutli-threading issues
• Reconnecing to the database for every transaction

You then might want to consider - what if I want to connect to two different databases?

By having Db as an object you're giving yourself more control over how the system may evolve.

Similarly with the thumbnail generation, should you want the system to cache thumbnails etc. by having an object deal with them it affords you better control over their life cycle and how they're shared.

By working with objects like this you can separate the concerns of your software and by doing so end up with pieces that you can re-use in different contexts.

As with anything it's a balance really only the context within which you work dictates the value of this kind of thing since you're new to OO I'd try for a bit (year or two) and see what actually seems to win you advantages when experience tells you that following such principles in your context is of little use then maybe stop following them just be wary when your context changes.

Answer 6

I struggle to imagine a worse way to learn about OO than Relational Databases in PHP. A few others have mentioned the problems with PHP. I'll point you to an article by our esteemed founder discussing why Objects and Relations don't mix:

Object-Relational Mapping is the Vietnam of Computer Science

You would do better to try something like GUI programming in Python. I recommend Python because it has good support for, but does not mandate OO, so you are less likely to see OO used in circumstances when it is inappropriate. I recommend GUI programming because GUI programming is almost impossible without OO techniques.