News Feed
Jobs Feed
Sections




News Archive
feed this:

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

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


PHPMaster.com:
The Open/Closed Principle
November 08, 2012 @ 10:09:32

On PHPMaster.com there's a new post continuing their look at the SOLID development methodologies with the "O" in the acronym - the Open/Closed Principle:

I have to admit the first time I peeked at the academic definition of the Open/Closed Principle, its predicate was surprisingly clear to me. Leaving all of the technical jargon out of the picture, of course, its dictate was pretty much the mantra that we've heard so many times before: "Don't hack the core". Well, admittedly there's a pinch of ambiguity since there are at least two common approaches to keeping the "core" neatly preserved while extending its functionality. The first one (and why I used deliberately the term "extending") would be appealing to Inheritance. [...] The second approach is Composition.

He illustrates the effective application of the principle with the creation of a HTML rendering class. The first version is non-polymorphic and just renders the example DIV and P elements that are passed into it. He changes this up by shifting these element classes into something extending an AbstractHtmlElement class (sharing an interface between them) and updating the renderer to handle these correctly.

0 comments voice your opinion now!
solid design principle openclosed tutorial


PHPMaster.com:
Constructors and the Myth of Breaking the Liskov Substitution Principle
October 08, 2012 @ 11:53:13

On PHPMaster.com there's a new post in a series looking at the SOLID design principles in PHP development. In this new tutorial they try to dispel the myth that constructors break the Liskov Substitution Principle ("L" in "SOLID").

Rants aside, the morale of the story can be boiled down to the following: "Object construction is not part of the contract honored by its implementers". It's easier to grasp concepts by example rather than reading dull theory, so in this article I'll be demonstrating from a practical standpoint how the implementation of different constructors down the same hierarchy isn't a violation of the Liskov Substitution Principle, which is a reason why you shouldn't fall into the temptation of tainting your interfaces with constructors.

He illustrates the point with a simple PDO class that implements a "DatabaseAdapterInterface" interface that defines its own constructor that follows the defaults of the PDO extension. He goes on and changes the constructor for the class a bit to take in an array of config options rather than the DSN/User/Password combo. Inside of this constructor, those values are then taken and pushed into PDO to create the connection. He also suggests one other solution - the injection of a connection object ("ConnectionDefinition") into the constructor instead of the configuration directly.

0 comments voice your opinion now!
solid development liskov substitution principle tutorial constructor


Freek Lijten:
SOLID - The L is for Liskov Substitution Principle
September 04, 2012 @ 08:37:46

In this new post to his site Freek Lijten picks back up his series on the SOLID design principles with a look at the "L" in the acronym - the Liskov Substitution Principle.

The Liskov Substitution Principle (LSP) was coined by Barbara Liskov as early as 1987. The principle is very tightly connected to the earlier discussed Open Closed Principle. A good way of adhering to the OCP is understanding and implementing code that uses the Liskov Substitution Principle. In this article we will discover why and how.

He gives a more understandable explanation of what the rule tries to suggest - a standardized interface that each of his "Bike" instances follows to ensure the contract of a consistent API. Then each of the child classes can reliably assume that there are methods they can use because they'll always inherit them.

0 comments voice your opinion now!
liskov substitution principle solid design series



Community Events











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


overview podcast symfony2 composer introduction facebook security install database package hack application language opinion framework hhvm unittest release component performance

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