Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

TutsPlus.com:
Object-Oriented Autoloading in WordPress, Part 2
Nov 30, 2016 @ 09:33:08

The TutsPlus.com site has posted the next tutorial in their "Object-Oriented Autoloading in WordPress" series - part two - expanding on the basics presented in the previous part of the series.

In the previous tutorial, we covered a handful of concepts, all of which are going to be necessary to fully understand what we're doing in this tutorial. Specifically, we covered the following topics: object-oriented interfaces, the single responsibility principle, how these look in PHP [and] where we're headed with our plugin.

[...] Ultimately, we won't be writing much code in this tutorial, but we'll be writing some. It is, however, a practical tutorial in that we're performing object-oriented analysis and design. This is a necessary phase for many large-scale projects (and something that should happen for small-scale projects).

First they briefly cover the environment you'll need to follow along (already set up if you followed along with part one). They then get back into the code, evaluating the current state of the custom autoloader and investigating how it can be broken down into a class and a set of methods instead of procedural code. They work through the different functional parts of the autoloader and how to break it down into classes with only one job (the "single responsibility principle"). They end up with the autoloader that uses NamespaceValidator, FileInvestigator and FileRegistry instances to get the job done.

tagged: oop objectoriented wordpress part2 series refactor singleresponsibility principle

Link: https://code.tutsplus.com/tutorials/object-oriented-autoloading-in-wordpress-part-2--cms-27431

TutsPlus.com:
Object-Oriented Autoloading in WordPress, Part 1
Nov 18, 2016 @ 13:57:08

The TutsPlus.com site has posted the next part of their series looking at autoloading in WordPress plugins. In this latest post the most from just the namespacing and setup into the actual code - creating some simple object-oriented classes that can be easily autoloaded.

I recently wrapped up a series in which I covered namespaces and autoloading in WordPress. If you're not familiar with either of the above terms, then I recommend checking out the series. [...] While working on the series, specifically that of the autoloader, I couldn't help but recognize a number of code smells that were being introduced as I was sharing the code with you.

This isn't to say the autoloader is bad or that it doesn't work. If you've downloaded the plugin, run it, or followed along and written your own autoloader, then you know that it does in fact work. But in a series that focuses on namespaces—something that's part and parcel of object-oriented programming—I couldn't help but feel uncomfortable leaving the autoloader in its final state at the end of the series.

They move away from just autoloading and namespacing quickly and move into OOP concepts like interfaces, implementing them, the "single-responsibility principle" and a few other helpful principles. They define the goals for the work ahead and move into the code, updating the current state of the plugin to use these new ideas.

tagged: oop objectoriented wordpress part1 series interface singleresponsibility principle

Link: https://code.tutsplus.com/tutorials/object-oriented-autoloading-in-wordpress-part-1--cms-27381

Jason McCreary:
Practicing YAGNI
Aug 10, 2016 @ 10:18:33

Jason McCreary has written up a post covering a popular topic from the eXtreme programming world, a talk he presented on the subject and a bit of his own personal experiences with it: YAGNI or "You Aren’t Gonna Need It".

Last week I spoke at Laracon US 2016 about Practicing YAGNI. First, let me say it was an honor to present for such a large audience at such a premiere conference. I received a lot of feedback and interest in my talk. To that point, many people have asked me to share my slides. As the slides were mostly placeholders for discussion, I felt a blog post would better summarize the talk.

[...] YAGNI is a principle of eXtreme Programming - something I practice daily at work. YAGNI is an acronym for You Aren’t Gonna Need It. It states a programmer should not add functionality until deemed necessary. In theory, this seems straightforward, but few programmers practice it.

He talks about practicing YAGNI and why it's hard for the average developer. He starts with the overall problem it solves and the more relatable KISS (Keep it simple, stupid) and MVP (minimum viable product) realms of thought. He then gets into some of the ways that you can practice YAGNI in your own development, mostly dealing with the timing of feature development rather than complexity. He also includes some times when it doesn't make sense to practice YAGNI and, finally, what practicing it means to him personally.

tagged: yagni yaaintgonnaneedit development principle extreme programming opinion

Link: http://jason.pureconcepts.net/2016/08/practicing-yagni/

Mathias Verraes:
DRY is about Knowledge
Aug 04, 2014 @ 10:51:50

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.

tagged: dry dontrepeatyourself principle knowledge domaindriven design business goal

Link: http://verraes.net/2014/08/dry-is-about-knowledge/

Wojciech Sznapka:
Type Hinting is important
Jun 12, 2014 @ 09:41:51

In his latest post Wojciech Sznapka reminds us that type hinting is important in your PHP applications and can help provide more structure and better overall code practices.

One of my favorite PHP interview questions, is: what is Type Hinting and why it’s important? Putting definition in one sentence, Type Hinting is a way to define type of parameter in function signature and it’s a sine qua non to leverage polymorphism. [...] So given the fact, that Type Hinting is optional and we don’t need to specify types of parameters passed to the method – why bother? Answer is easy: well prepared method signatures defines your model and are part of the “contract” that your code reveals to its consumers. It also prevents many silly errors and keeps codebase clean and coherent.

He talks about the best practices on using type hinting including where to put them (in an interface or base class or child class?) and some of the pros and cons of each. He also points out that some practices around type hinting, like overriding the hint and calling the method with unexpected/variable input, should be avoided (see the L in SOLID).

tagged: typehint importance bestpractice liskov substitution principle solid

Link: http://blog.sznapka.pl/type-hinting-is-important

Mathias Verraes:
Final Classes
May 13, 2014 @ 09:48:43

Mathias Verraes has posted some of his thoughts about using "final" in classes and what kind of impression it gives about your code.

I make all my classes final by default. I even configured the templates in my IDE prefix new classes with ‘final’. I’ve often explained my reasoning to people. A blog post is in order! A guiding principle here is Clarity of Intent. [...] The reason we need clean code, is not for the compiler. It’s to help our fellow developers, third parties, and even ourselves in six months time, understand the purpose and the design of our system.

He relates this concept of clean code and clarity back to the SOLID development principles, specifically the "Open/Closed Principle". This principle states that software should be open for extension but not for modification. It suggests that providing a stable, known API is a responsibility of the developer and using things like callbacks and listeners is a better way to extend. He gets into a bit more PHP-specific issues around using "final", including the difficulties that it can cause during testing.

tagged: final class inheritance extension solid openclosed principle

Link: http://verraes.net/2014/05/final-classes-in-php/

NetTuts.com:
SOLID: Part 4 - The Dependency Inversion Principle
Feb 14, 2014 @ 11:53:22

NetTuts.com has posted the next part in their series (the looking at the SOLID development principles discussing the Dependency Inversion Principle, the final letter in the "SOLID" acronym.

It would be unjust to tell you that any one of the SOLID principles is more important than another. However, probably none of the others have such an immediate and profound effect on your code than the Dependency Inversion Principle, or DIP in short. If you find the other principles hard to grasp or apply, start with this one and apply the rest on code that already respects DIP.

They start off with a basic definition of the dependency inversion principle and an example of it in a more real world situation. They use it to separate out the handling of reading and rendering PDFs and eBooks. It's just some basic code, no real functionality, but it gives you an idea of how to architect the application.

tagged: dependency inversion principle solid development part4 series

Link: http://code.tutsplus.com/tutorials/solid-part-4-the-dependency-inversion-principle--net-36872

NetTuts.com:
SOLID: Part 1 - The Single Responsibility Principle
Dec 16, 2013 @ 13:10:55

NetTuts.com kicks off a new series of posts today with this first article covering the SOLID development practices. SOLID is a set of principles that can help make your code more robust and well structured in the long run. In this first post they jump right in with the first letter - "S" for Single Responsibility Principle.

[The Single Responsibility Principle] is one of the five SOLID agile principles. What it states is very simple, however achieving that simplicity can be very tricky. A class should have only one reason to change. But why? Why is it so important to have only one reason for change? [...] Even though you may not use a compiled language, you may need to retest the same class or module for different reasons. This means more QA work, time, and effort.

They go on to talk about how to figure out the "audience" for your class and how that effects what it should contain. A few "class examples" are shared in the post including objects that can print or save themselves. There's a bit of talk about software design ideas to consider and a less obvious example that might be breaking the principle (and how to fix it).

tagged: solid design principles single responsibility principle

Link: http://net.tutsplus.com/tutorials/php/solid-part-1-the-single-responsibility-principle/

Brandon Savage:
The Cardinal Sin Of Object Inheritance
Sep 09, 2013 @ 12:38:04

Brandon Savage talks about the "cardinal sin" of working with object inheritance in PHP applications - adding public methods to a class that extends/implements another.

I know I’ve committed this sin, and you probably have too. The sin of which I speak is a grave one, and it violates several well known and established principles of object oriented application development. What is this sin of which I speak? It is none other than the addition of new public methods to an object that extends or implements abstract class or application interface, in violation of both the Liskov Substitution Principle and the Dependency Inversion Principle.

He talks some about the Liskov Substitution Principle first, pointing out that adding those new methods makes the new object non-replaceable as the Liskov principle requires. As far as the Dependency Inversion Principle, the practice breaks it because you'd be depending on those new methods as concrete, not abstracted from the parent. He makes a few recommendations as far as ways to prevent violating these principles including using multiple interfaces or creating multiple abstract classes for different public APIs.

tagged: object inheritance sin solid principle public method violation

Link: http://www.brandonsavage.net/the-cardinal-sin-of-object-inheritance/

Brandon Savage:
The "D" Doesn’t Stand For Dependency Injection
Aug 13, 2013 @ 11:03:55

Brandon Savage has a new post to his site that tries to clear up a misconception about the SOLID set of principles for software development. He points out that, despite some comments to the contrary, the "D" doesn't stand for "Dependency Injection".

You’ve probably heard of the acronym SOLID by now, which is an object oriented programming paradigm consisting of five basic (but interrelated principles) of object oriented development. And you’ve probably heard once or twice that the D in SOLID stands for Dependency Injection. Actually, if you’re lucky you’ve also heard what it really stands for, which is the Dependency Inversion Principle. But, in PHP, this is often conflated with dependency injection. I’m here to tell you today that dependency injection is only one piece of the overall puzzle in understanding this crucial principle.

He talks about the actual definition of the "D", dependency inversion, and how it relates to the concept of "dependency on abstractions." He includes some sample code to help make his point - one showing classes with dependencies on one type of object, another showing a dependency on an interface instead.

tagged: solid oop development dependency inversion principle injection

Link: http://www.brandonsavage.net/the-d-doesnt-stand-for-dependency-injection