In a post to his site Kevin Smith wonders "what's so great about OOP?". In it, he goes back to the basics of OOP (object-oriented programming) and keeps it simple, avoiding more advanced OOP-related topics.

One of my core responsibilities as a senior software engineer is mentoring the junior engineers and interns at work. [...] Recently a question came up with our new interns while talking through the design of a feature: What is object-oriented programming? How is it different from what we're doing now, and why should we write code that way?

I wanted to find a fundamental explanation to send them for later, but nearly everything I came across immediately jumped into SOLID or design patterns or advanced concepts of some kind.

He starts from the beginning, where most PHP developers cut their teeth with the language: procedural programming. He provides some (non-OOP) examples of this, making use of simpler functions rather than objects and methods. He then moves on to compare this with OOP. He talks about how it's more than just a different syntax (a shift in thinking really). He refactors his previous example to use objects and methods. He finishes up the post answering one of his original questions: what's the real benefit of OOP over procedural programming.

Last time, I began telling you the story of how I wanted to make a game. I described how I set up the async PHP server, the Laravel Mix build chain, the ReactJS front-end, and the Web Sockets connecting all this together. Now, let me tell you about what happened when I starting building the game mechanics with this mix of ReactJS, PHP, and Websockets…

He started with the idea of a simple "farm" in the game represented by a set of "patches" in the game (pixels, basically). He includes the code he use to create it and allow for new ones to be created on request (including both the PHP side and the React.js code). He then shows how to modify it to make each farm requested come in with a bit of randomness as far as what kind of terrain (dirt/grass/wheat) it came in with. The post wraps up with the code required to render the farm in the UI and style it based on what kind of terrain it contained.

Is there anything wrong with using an include file of functions instead of using full code in a file? [...] Obviously you wouldn't write functions for one off tiny things, but I think it would help to read files altogether especially if the functions file was alphabetically listed.

There's several suggestions in the comments including things like:

You should also look into using a templating engine, so you can separate your html from your php code.

One thing you could always ask yourself is "Do I will ever need to write that part a second time somewhere else ?" If "yes", that means you should put that part in a function.

Before you go writing a load of functions and putting them all in a file, which can get quite unmanageable, consider grouping them logically and placing them in classes.

Function names should start with a verb though (except for trivial getters whose meaning is clear by context, which can be named after the thing they get).

Do group them logically, but it's not necessary to place them in a class unless they share data or state.

In this new tutorial from NetTuts.com, they want to help you make the move from procedural PHP to the world of Object-Oriented PHP. They opt for the mini-project approach and show you how to make a simple Google API client.

This tutorial was inspired by a speech given by Robert C. Martin that I watched a year or so ago. The main subject of his talk is about the possibility of picking The Last Programming Language. He addresses topics such as why should such a language exist? And what it should look like? However, if you read between the lines, there was another interesting idea that caught my attention: the limitations that each programming paradigm imposes upon on us programmers. So before we get into how we could go about converting a procedural based PHP app into an object oriented one, I want to cover a little bit of theory beforehand.

They start their example with a procedural approach, showing how to make the client and make a request for calendar information. They then work through the refactoring of the example, breaking it up into logical chunks (objects) and separating out some of the logic (like view versus logic). They talk about everything from basic OOP terms out to more complex ideas like SOLID.

On Reddit.com there's a conversation kicked off by user swiftpants about making the move from procedural PHP programming to the world of object-oriented programming. They ask for advice from the community for the next steps to take to make the jump.

One thing I always have in the back of my head is that all my code is procedural and I should be making use of classes and ?? more. I have a very basic understanding of OO programming but I rarely implement it. Is there a good book or online guide that can get me on my way to OO programming in php. I am especially looking for feed back from self taught programmers.

<p.
Anthony Ferrara has posted about his first video in a series he's creating about programming and related topics. In this first one he talks about "Paradigm Soup".

So, for the past few days I've been talking about a secret project that I've been working on. Well, today I'm pleased to announce the project. I've been working on starting a series of YouTube videos about programming. The first of these videos is about Paradigms (Procedural, OOP, Functional). Plenty of future ones are planned, but the topics, order and even if they happen is completely up to you!

He goes through some common practices in things like OOP, functional and procedural programming as well as how they relate to each other. You can view the video in the post or you can watch it over on Youtube. If you want to keep up with the series, you can follow this playlist.

Slawek Lukasiewicz has a new post today about working with dates and times in PHP on a more object-oriented fashion than in the more traditionally procedural way of just calling PHP date/time functions on the string values.

Date and time manipulation in PHP is mostly connected with functions like: date, time or strtotime. They can be sufficient, but if we want to deal with dates like with objects - we can use DateTime class. DateTime class is not only straightforward wrapper for standard functions, it has a lot of additional features - for example timezones.

He shows how to use the DateTime functionality to return an object you can call several different methods on. He gives examples of the formatting call, comparing one DateTime object to another, how to update the date after the object's created, calculating the difference between two dates and iterating through a certain time period.

Aleksey Martynov has submitted a new tutorial showing you how to (create a) "blog in 15 minutes" with the help of the lexa-tools framework, a set of utilities that gives you a procedural API to some handy tools.

James Cohen has a new post to his blog today looking at some of the built-in functionality that PHP has to work with dates and times including simple things like strtotime and the DateTime feature.

A lot of people ask questions relating to date and time in PHP. Here are some answers to the most commonly asked questions and common mistakes.

He covers the differences between working with dates in strtotime, worrying about timezone settings and compares the strtotime/DateTime methods for formatting and returning dates, modifying dates, converting between timezones as well as finding the difference between two timezones.

According to this new post on the Web Builder Zone, the results of a poll taken about the best programming method for PHP these days is - by far - object-oriented programming.

After two weeks of gathering votes, the PHP paradigms poll is now closed. With 216 votes (73%), the winner paradigm in popularity is Object-Oriented Programming. The old procedural approach to PHP, which has given fame to Wordpress and Drupal, is coming to an end. Even Drupal 7 has an object-oriented database layer as a primary component, and this paradigm is by far the most diffused in the world for web sites and applications written in high level languages (different from C).

While the overwhelming amount of votes went to OOP, there were still a few for some of the other options including the second place winner - procedural programming. He also talks a bit about OOP's current place in the PHP ecosystem and how it has allowed for certain great tools to be developed, but how it also has a good ways to go in functionality.