The concept of Aspect-Oriented Programming (AOP) is fairly new to PHP. There's currently no official AOP support in PHP, but there are some extensions and libraries which implement this feature. In this lesson, we'll use the Go! PHP library to learn AOP in PHP, and review when it can be helpful.

They start with a brief history of AOP in general and a basic vocabulary of some of the common terms like "point-cut", "aspect" and "cross-concern." They briefly look at some of the other PHP tools for AOP, but then help you get Go! up and running. Sample code is included showing how to integrate it into your project and, more practically, create a logging system that can be used as an aspect.

Object oriented programming (OOP) was first introduced in php4. Area for oop in php version 4 was not very vast. There were only few features available in php4. Major concept of the object oriented programming in PHP is introduced from version 5(we commonly known as php5). [...] But still in php5 object model is designed nicely. If you have good understanding of OOP then you can create very good architecture of your php application. You only need to know some of the basic principles of object oriented programming and how to implement that concept of oop in php.

While the wording is slightly odd in some spots (English doesn't seem to be the author's first language), it's' a great introduction to the major OOP-related topics including:

• Classes and Objects
• Visibility in PHP
• Abstract classes and interfaces
• Object cloning
• Method chaining

Each section also has downloadable code to go along with the examples, making it easier to follow and test out the actual scripts.

In the last tutorial in this beginners series we discussed using PDO to connect to a MySQL database. Following on from that tutorial we are going to improve the Guitar class we made by adding some basic CRUD methods so that our class can interact with our database using PDO.

He brings back the same class structure and shows how to take a "Guitar" object, create a connection via a "conn()" method and use the getters/setters to assign values for saving, selecting, deleting and updating the database's records.

All modern frameworks (including FLOW3) push a lot of patterns into the software stack that do a great job at separating the concerns of your business logic; among them the famous MVC that is separating your logic into different layers. However, an application is not only built on business logic alone. As it grows, you may want to implement additional services, features, plugins or plugins of plugins. You surely don't want this stuff in your business logic! But what are your options?

For their example, they show how to implement a logger across your classes, taking it out of the actual code and implementing it in an aspect (at the "pointcut") by "weaving" it into a DocBlock comment with special annotations. They help you get the FLOW3 framework set up and show you how to "kickstart" a new project and work with its controllers and resources. They show you how to implement the Logging aspect and how to define it in your code (and where it caches the requests).

It's tentatively called "PHP Object Oriented Programming Reinvented". Although it turns out the acronym is kind of unfortunate. I'm still working on that... The main idea is that classes aren't really very special at all, they're just objects like everything else. They don't even have names.. you give your class a name by giving the variable it's assigned to a name.

He includes a code snippet that shows the creation of a sample class (the "class" class) and extend it with a new class of "animal"....and then extend that with a class for a "dog". You can take a look at the full code for the method here.

However, the ubiquity of governments around the world also gives us a unique opportunity to learn some lessons from them as developers, particularly about principles of object oriented programming. Governments serve as perfet object lessons (pun intended), demonstrating some of the good, the bad, and the ugly object-oriented practices we see.

He looks at five topics - abstraction, encapsulation, implementation of dumb objects, decoupling and the concept of "one class, one responsibility".

• "Often times when a developer gives each object only one responsibility, they tightly couple objects together." Can you explain?
• I do not know about dependency injection '" do you have any links that do not require subscription?
• Can you please explain 'one object '" one job' concept?

Each question is answered, sometimes with code included, to help resolve any confusion about how to correct use object oriented practices in your applications.

Being a trainer for Ibuildings, I noticed that the main topic of almost every course plan for customers is object oriented programming. So OO is popular and demand for it is rising. However, while PHP support for OO has been present for a couple of years still many companies that I visit are maintaining and developing procedural applications.

He talks some about how he tries to promote the OOP way of doing things and defines one of the major hindrances for companies to try to move their development towards it - time. The next part of his series will look at ways to help with this.

What is object-oriented programming? The acronym OOP has become a bit of a buzzword in the current age of programming, to the point where the waters of its definition have become rather murky. [...] PHP may not be object-oriented, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an object or a message being passed between objects (where message parameters are also objects).

He mentions one of the first languages to support objects (Simula) and the four fundamental concepts that would make a language truly OOP - abstraction, inheritance, encapsulation, polymorphism. Its his opinion, though, that while its good for languages to adhere to these four principles as much as they can, discussions about how well they adhere to them is usually just "spinning your wheels" and don't have much use.

Goodness. I like PHP. I use it a lot. I've been using it since early 1996. I'm Zend Certified, have done billion dollar ecommerce projects in PHP, and like to think I know a little bit about PHP. It is *NOT* "object oriented". I wish people would quit saying it. Perhaps there's a need to impress non PHP people, or to try to get across the idea that PHP supports objects. Maybe that's fair, but I don't think so.

His reasoning is that, despite the phrase "object oriented" being applied to PHP, its functionality does not hinge on objects. He suggests a "more correct" term to replace it - "object capable". This shows that PHP can use objects but, because of its procedural roots, doesn't have to.