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 3 - Liskov Substitution & Interface Segregation Principles
January 27, 2014 @ 11:51:30

On NetTuts.com today they've continued their series covering the SOLID development principles with the next letter in the acronym - "L". It stands for the Liskov Substitution & Interface Segregation Principles. The tutorial also talks some about the "Interface Segregation Principle" as they go hand-in-hand.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows: "Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T." [or more simply] "Subtypes must be substitutable for their base types."

They include some example PHP code showing a base "Vehicle" class and first an example of doing it correctly (with the Template design pattern) and an example of an incorrect method, complete with tests. They then get into the Interface Segregation Principle, an interface that can be depended on to use the module, with the same car-related examples.

0 comments voice your opinion now!
solid design principles liskov substitution interface segregation

Link: http://net.tutsplus.com/tutorials/php/solid-part-3-liskov-substitution-interface-segregation-principles/

NetTuts.com:
SOLID Part 2 - The Open/Closed Principle
January 21, 2014 @ 12:45:29

On NetTuts.com today they continue their look at the SOLID development principles with the next letter in the sequence - O for Open/Closed Principle. The first part of the series, covering "S" (the Single Responsibility Principle) can be found here.

The Open/Closed Principle, OCP in short, is credited to Bertrand Mayer, a French programmer, who first published it in his book Object-Oriented Software Construction in 1988. The principle rose in popularity in the early 2000s when it became one of the SOLID principles defined by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and later republished in the C# version of the book Agile Principles, Patterns, and Practices in C#. What we are basically talking about here is to design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code.

They start with a look at OCP in the overall SOLID context and an example of an obvious violation of the principle. Some example code is provided showing a "Progress" class that's bound to at "File" implementation, not abstracted. They offer three different options for solving the issue:

  • Take Advantage of the Dynamic Nature of PHP
  • Use the Strategy Design Pattern
  • Use the Template Method Design Pattern

Each of the above comes with example code and some with illustrations of the structure they create.

0 comments voice your opinion now!
solid design principles open closed tutorial introduction

Link: http://net.tutsplus.com/tutorials/php/solid-part-2-the-openclosed-principle

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/

Anthony Ferrara:
Beyond Object Oriented Programming
November 12, 2013 @ 11:56:36

Following up on his previous post talking about going "beyond inheritance" in object-oriented development in PHP, Anthony Ferrara has a new post extends the subject, focusing more on types of classes and how his thoughts would apply.

In the last post Beyond Inheritance, we talked about looking past "types" and reasoning about objects differently. The conclusion was that inheritance wasn't necessary for OOP, and often results in more problems than it solves. Well, let's go beyond that and explore more of what will come from treating objects as containers of behavior. Let's look at what this means for various kinds of classes.

He looks at five different class types and gives a brief summary of the concepts they represent - Representers, Doers, Plumbers, Translators and Makers. He then shifts over to investigating how this all applies to the SOLID development principles. He follows this pattern of thought through and looks at how it breaks things down into decomposable behaviors and, ultimately, functional programming/code structures (including the suggestions that creating ValueObjects is directly related).

0 comments voice your opinion now!
beyond oop types solid development functional valueobject

Link: http://blog.ircmaxell.com/2013/11/beyond-object-oriented-programming.html

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/

Ben Youngblood:
MVC Is Not Enough
September 04, 2013 @ 09:12:25

Ben Youngblood has a new post to his site suggesting that MVC is not enough to build good, robust applications (PHP or not) just because a good portion of the frameworks implement it.

With few exceptions, any software engineer worth his/her salt have at least heard of the model-view-controller pattern. It's been around since it was introduced to Smalltalk in the late 1970s and has been a staple pattern in object-oriented languages for as many years. Nearly all the leading PHP frameworks include some form of MVC implementation. With so many frameworks and developers espousing its use, you would think it's the best pattern for building your application. And you would be wrong.

He's not suggesting abandoning MVC altogether for something else. He just wants a reexamination of how it's being used and how to improve the structure of the applications using it. One option is to adhere more to the SOLID principles, avoiding things like domain logic in controllers and "fat" models with too much logic.

Chiefly, MVC is one part of your application, not your application. If you find that you are building your domain logic inside models, views, or controllers, then you are abusing MVC. No substantive application can, or should, be made to fit inside MVC.
0 comments voice your opinion now!
mvc opinion solid principles improvement

Link: http://blog.bjyoungblood.com/2013/08/21/mvc-is-not-enough

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

William Durand:
From STUPID to SOLID Code!
August 01, 2013 @ 12:45:11

William Durand has a new post to his site sharing not only the slides from his recent presentation on SOLID vs STUPID code but the same content written out. It provides a great overview of the two concepts and some examples of what to avoid. There's also a recording of the session you can listen to via the in-page player.

Last week I gave a talk about Object-Oriented Programming at Michelin, the company I am working for. I talked about writing better code, from STUPID to SOLID code! STUPID as well as SOLID are two acronyms, and have been covered quite a lot for a long time. However, these mnemonics are not always well-known, so it is worth spreading the word.

In the following, I will introduce both STUPID and SOLID principles. Keep in mind that these are principles, not laws. However, considering them as laws would be good for those who want to improve themselves.

He starts with the STUPID concepts first - Singleton, Tight Coupling, Untestability, Premature Optimization, Indescriptive Naming and Duplication. He goes through each of these and explains why they're bad things to have in your code. He then gets into the SOLID ideals - Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle. These are a bit more complex to understand but he does a good job (complete with code snippets) of each. The slides for his presentation are also included but they're just a high level look at the same concepts from the article.

0 comments voice your opinion now!
presentation solid stupid code concepts slides recording overview

Link: http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code

Community News:
"Laravel From Apprentice To Artisan" Book Release
July 17, 2013 @ 10:31:41

As is mentioned on Reddit.com, Taylor Otwell (author of the Laravel framework) has released his latest book about the architecture of Laravel applications.

Written by the creator of Laravel, this is the definitive guide to advanced application development with Laravel 4. Learn about dependency injection, interfaces, service providers, SOLID design, and more while exploring practical, real-world code examples. Whether you're building a robust, large application with the Laravel framework, or just want to sharpen your software design chops, this book will be of great value to you and your team.

The book covers a lot of common architecture concepts too, not just things specific to Laravel like:

  • Interfaces as contracts
  • Working with service providers
  • the Single Responsibility Principle
  • the Interface Segregation Principle
  • the Dependency Inversion Principle

You might notice that those last few chapters are actually covering the SOLID design principles. You can pick up the book over on Leanpub.

0 comments voice your opinion now!
book release laravel framework taylorotwell architecture solid principles

Link: http://www.reddit.com/r/PHP/comments/1ifd09/laravel_4_from_apprentice_to_artisan_book_released


Community Events











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


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

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