News Feed
Sections




News Archive
feed this:

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

Mathias Verraes:
DRY is about Knowledge
August 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.

0 comments voice your opinion now!
dry dontrepeatyourself principle knowledge domaindriven design business goal

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

Wojciech Sznapka:
Type Hinting is important
June 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).

0 comments voice your opinion now!
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.

0 comments voice your opinion now!
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
February 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.

0 comments voice your opinion now!
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
December 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).

0 comments voice your opinion now!
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
September 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.

0 comments voice your opinion now!
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
August 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.

0 comments voice your opinion now!
solid oop development dependency inversion principle injection

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

Freek Lijten:
SOLID - The D is for Dependency Inversion Principle
January 02, 2013 @ 10:25:46

Freek Lijten has posted the last article in his series looking at the SOLID development principles, this time looking at "D", the Dependency Inversion Principle.

The DIP deals with avoiding mixing different levels of abstraction in your code. In this article we will explore the last of these principles in depth. [...] I want to show you how depending on abstractions makes our lives easier in a larger example. Since we're going to be loading, updating and storing bikes a lot in our application I would like an Api for that. It would not be such a good idea to write the same queries or perform the same validation over and over.

He includes two examples - one a bit simplistic involving bike storage and another more complex that uses interfaces to define structure and object injection rather than passing data around. He also tries to help clear up some of the confusion that might happen around dependency inversion and dependency injection.

0 comments voice your opinion now!
solid development principle dependency inversion introduction


PHPMaster.com:
Inversion of Control - The Hollywood Principle
December 10, 2012 @ 09:43:50

In this new tutorial on PHPMaster.com, Alejandro Gervasio looks at the Inversion of Control methodology and how it's more than just an abstract reference to dependency injection.

Traditionally, application components have been designed to operate on and control the execution environment, an approach that delivers well to some extent. [...] Instead of making the module completely responsible for logging data to multiple endpoints, we can transfer the responsibility straight to the external environment. [...] Not surprisingly, the process of inverting these responsibilities between components and the environment is formally known as Inversion of Control (or in a more relaxed jargon, The Hollywood Principle), and its implementation can be a real boost when it comes to developing extensible, highly-decoupled program modules.

He uses a set of domain objects (Posts and Comments in a typical blog structure) and the Observer pattern to show how mixed up things might get if the application isn't carefully coded. He takes this and updates it to include a "comment notification service" that implements the SplObserver and is attached to the post to be executed on an event (in this case, the setting of a new comment).

0 comments voice your opinion now!
inversionofcontrol hollywood principle introduction listener observer tutorial


PHPMaster.com:
The Single Responsibility Principle
November 22, 2012 @ 11:58:06

On PHPMaster.com today Alejandro Gervasio has a new tutorial posted about the Single Responsibility Principle - a guideline that states that each class should only have one "area of concern" and not try to do to much.

One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. The so-called "God class" is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. [...] What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else.

He starts off with a typical violation of the principle, showing a class that not only handles user data but also includes the functions to work with the database directly as well (insert/update/delete). He refactors this into a few much more manageable classes - a mapping class to handle the database interaction and a "User" class representative of a true user object.

0 comments voice your opinion now!
single responsibility principle srp class tutorial refactor



Community Events





Don't see your event here?
Let us know!


library deployment series interview release package framework language opinion introduction bugfix install symfony laravel voicesoftheelephpant community list podcast tips api

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework