On SitePoint.com today they've posted the transcript of a "Talk with the Experts" session they did with Lorna Mitchell (instructor of their recent OOP sessions). The transcript includes questions and answers to those in attendance as well as some good links and advice.

Last Thursday I broke with tradition slightly and ran a Talk with the Experts session in the evening (down under), making it a bit more time-zone friendly for our UK audience. It also meant that I was able to swap my usual coffee for a wine, which probably made the session run a bit more smoothly. The subject was PHP and our expert was Lorna Mitchell, tutor of Object-oriented PHP and co-author of PHP Master: Write Cutting-edge Code.

The transcript starts with a collection of some of the links provided during the discussion and then runs through the entire conversation. There's some good advice in there, especially if you're relatively new to the world of PHP object-oriented programming.

In this latest post to his site Rob Allen talks some about application structure and the different kinds of objects he uses in his applications.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

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.

There's lots of comments on the post talking about everything from:

• Introductory videos from KillerPHP
• Reading lots of other people's (OOP) code
• That OOP is more about code reusing and simplicity (DRY) than abstraction.
• You can learn a lot by working with one of the MVC/OO frameworks. Download one and build something.
• The suggestion of phptherightway.com

Have any other thoughts on the best ways to learn OOP in PHP? Share them here!

If you've ever played the card game "Fluxx" (or are familiar with the ever changing rules behind software development) you can release to this new article from Sebastian Bergmann. He makes a link between the "Star Fluxx" card game and how OOP and encapsulation help make changing things easier.

Star Fluxx is a science-fiction-themed version of Fluxx, "a card game [that] is different from most other card games, in that the rules and the conditions for winning are altered throughout the game, via cards played by the players." (Wikipedia) When I heard the description of the game on the aforementioned episode of TableTop it reminded me of software development projects. Changing business rules and requirements (rules and the conditions for winning), probably sounds familiar to you, too.

He talks about how the game could be implemented effectively in OOP classes and interfaces - and how this structure would make it easier to make changes. A largely procedural codebase, however, would make the task much more challenging. The analogy breaks down a bit when it gets to the competitive nature of the game and how software development should be collaborative instead, but it's still effective.

On NetTuts.com today there's a great new article about how to write code that embraces change and can be easily updated and reconfigured due to a decoupled nature and use of good OOP concepts.

Writing code, which is easy to change is the Holy Grail of programming. Welcome to programming nirvana! But things are much more difficult in reality: source code is difficult to understand, dependencies point in countless directions, coupling is annoying, and you soon feel the heat of programming hell. In this tutorial, we will discuss a few principles, techniques and ideas that will help you write code that is easy to change.

He covers some of the good OOP principles to think about when developing - like cohesion, orthogonality and coupling (via class methods, polymorphism, dependency injection or interfaces). He spends some time looking at the SOLID development principles and how you can implement each of them in some sample code. He also talks some about high level design and how the separation of concerns can help make your code easier to maintain and change.

On PHPMaster.com today there's a quick tutorial showing you how to use SSH and SFTP from inside your PHP applications (requiring the ssh2 package).

In today's world with so many third-party integrations and content-sharing, it's important to understand and make use of protocols like SCP and SFTP. PHP's SSH2 extension, a wrapper for libssh2 which implements the SSH2 protocol, provides several functions you can use to securely transfer files.

Sample code is included showing how to make a SSH request to a remote server, define the key files to use and execute a remote command (like scp). They also mention the use of wrapper functions like mkdir that also work with SSH/SFTP connections. The post finishes up with an example class or two you can use to wrap your connection handling and make it a bit more OOP-friendly.

In a recent post to his site, Brandon Savage has a few helpful hints to keep in mind when you're refactoring your applications to make them easier to maintain (and possibly perform better) in the future.

The downtime [of this week] provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there's no time to do: make the code better for better's sake. With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the "lost week" can be redeemed.

He has a few recommendations, each including their own brief summary:

• Test Everything First
• One Method, One Job (Also One Class, One Job)
• Don't Be Afraid Of More Objects And Classes
• Remove Dead, Unused, Unnecessary or Old Code
• Document Your Code

Check out the full post for the summaries and links to other useful resources.

Lorna Mitchell has a new post showing nine of the magic methods that are included in PHP by default (like __construct, __get and __set) including a few you may not have used before.

The "magic" methods are ones with special names, starting with two underscores, which denote methods which will be triggered in response to particular PHP events. That might sound slightly automagical but actually it's pretty straightforward, we already saw an example of this in the last post, where we used a constructor - so we'll use this as our first example.

She includes details (and some code samples) for these methods:

• __construct
• __destruct
• __get
• __set
• __call
• __sleep
• __wakeup
• __clone
• __toString

You can find out about these and a few others in this page of the PHP manual.

If you've been around PHP for any length of time, you know about the static functionality and keyword that the language offers. You might have used it in the past for a few things, but maybe you're not 100% sure of how to use it right. If this describes you, you should check out this article from David Zentgraf for a great summary of their use and how to not kill the testability of your application by using them,

"Class Oriented Programming" is what people do when they write classes which are all static methods and properties and are never once instantiated. I'll try to explain why this adds virtually nothing vis-a-vis procedural programming, what these people are really missing out on by ignoring objects and why, against all odds, statics don't automatically kill testability. While this article focuses on PHP, the concepts apply equally across many languages.

He talks about code coupling, expectations when using static classes/methods and how it seems a little too similar to some of the procedural PHP we all started out writing. He ponts out that most static method calls are more like function calls than true OOP methods and that their dependencies are a bit more difficult to manage. He suggests that statics are really only good for one kind of thing - dealing with already static data and "utility methods" operating on given data.

In another of his series looking "under the covers" at what actually happens in the PHP language during its use, Sharif Ramadan has posted this look at the object handling in PHP's OOP functionality.

I would love to take a good long look under the hood at just how PHP objects and classes do the work that they do, and hope that you could benefit from that knowledge. [There are] many questions that come across my desk, on a regular basis, from developers and beginner PHP enthusiasts that I've worked with over the years, and are some of the key points this article attempts to help you answer.

He talks about classes "giving birth" to objects, how they're stored internal to PHP and how they provide the "blueprints" for it to lay out the storage of the object's data. He talks about using identifiers for variable/property access, object handlers and how "$this" fits into all of it. He notes that OOP, while a major part of PHP now, wasn't in the initial versions (until around PHP4). He finishes off the post talking about lateral/vertical context switching, the lifecycle of an object and the "early binding problem" and class scope.