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

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:
Using objects doesn't make an application object oriented
July 16, 2013 @ 12:22:34

In this recent post Brandon Savage suggests that just using objects in your application doesn't mean that it's truly "object oriented development." There's other criteria that need to be met to really fit this description.

Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they've done. After all, if they're using objects, their code must be object oriented, right? Well, not exactly.

He breaks it down into three main points that developers should consider when working with OOP in their apps: splitting responsibilities between classes, being polymorphic and using dependency injection. There's no code samples to back up the concepts here, but it's a decent list to think about. There's plenty of tutorials out there about SOLID development and dependency injection in PHP apps, so you might check some of those out to help with these concepts.

0 comments voice your opinion now!
oop objectoriented development responsibility polymorphic dependencyinjection

Link: http://www.brandonsavage.net/using-objects-doesnt-make-an-application-object-oriented

Phil Sturgeon:
Pick PHP Requirements for Packages Responsibly
March 25, 2013 @ 11:22:11

In this recent post to his site Phil Sturgeon has a reminder that you should select the dependencies for your packages wisely, and not just because they're "cool."

When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. [...] Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

He notes that, by requiring users that are currently only at 3.1% of PHP installs to upgrade to 5.4 just to use your library is a quick way to not have your library used. He points out that PHP 5.4 is "more than just []" for arrays and includes a reminder that several projects are still in PHP 5.3-compatibility mode just because that's the widest audience. He also briefly touches on the "push it forward" comments that people have used to justify 5.4-only packages, but notes that it's still not as much up to the developer as it is the web host.

0 comments voice your opinion now!
requirements responsibility features version webhosting upgrade composer


Brandon Savage:
Effective Refactoring Strategies
December 24, 2012 @ 11:24:57

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.

0 comments voice your opinion now!
refactoring tips test single responsibility oop documentation


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


Pádraic Brady:
PHP Security Default Vulnerabilities, Security Omissions & Framing Programmer
August 27, 2012 @ 10:05:13

In this new post (and this related article) Pádraic Brady shares some of his opinions about default security languages should provide and the Secure by Design principles.

Odd though it may seem, this principle explains some of PHP's greatest security weaknesses. PHP does not explicitly use Secure By Design as a guiding principle when executing features. I'm sure its in the back of developers' minds just as I'm sure it has influenced many if their design decisions, however there are issues when you consider how PHP has influenced the security practices of PHP programmers. The result of not following Secure By Design is that all applications and libraries written in PHP can inherit a number of security vulnerabilities, hereafter referred to as "By-Default Vulnerabilities".

He focuses on what he sees as a responsibility of those creating the language to either default to a more secure architecture or provide information as to why their choices could cause problems. In the extended version of the post, he talks about some specific issues that the language has including SSL/TLS misconfiguration, openings for XML entity injection attacks and limited native filtering for cross-site scripting.

0 comments voice your opinion now!
security default vulnerabilities responsibility developer securebydesign


Freek Lijten's Blog:
SOLID - The S is for Single responsibility
March 23, 2012 @ 11:23:59

Freek Lijten has written up a new post to his blog about a set of development principles that have been getting more press in the PHP community lately - SOLID. In his post he starts with a look at the "S" in the set - "Single Responsibility".

The single responsibility principle isn't all that hard to explain. It states that an object should do one thing, and one thing only. [...] A responsibility is a reason to change, and a class should only have one of those. Now all of this may sound abstract and since the objective of this series is to avoid just that we'll just dive into the why now.

He includes some sample code to illustrate, going with an active record implementation, some of the problems that come with a typical setup including issues with unit testing, bad practice of using the data store directly, etc. He shows a refactored code example that splits out the functionality previously all in the one class ("Bike") into three different ones - one is the normal Bike object, another compares the Bikes and the third works with the data store to handle the CRUD for the objects.

0 comments voice your opinion now!
solid development principles single responsibility


Cal Evans' Blog:
Man up! (A developer's responsibility to their team)
September 17, 2010 @ 10:05:11

Cal Evans has a suggestion for all of the developers out there not happy with decisions being made at their workplace (or in the contracts they work with) - man up!

Look, it's easy. As developers, we see people we don't respect making decisions we don't agree with. I know how difficult this position is because like every other developer in the world, I've been in this position. However, unlike a lot of developers I've talked to in recent years, I don't see "digging my heals in" or whining as alternatives.

He suggests one of two alternatives to the situation - either deal with things head-on and get onboard with the decision or jump ship and find something else that suits you better. Sometimes this is a bit easier than others (terminating contracts versus leaving a full-time job), but if you're really that upset with it, it's probably not going to get any better.

talk to a lot of people about how to build teams and the cornerstone of any good team is respect. Management has to respect developers and I firmly believe that. However, you as a developers, have to respect management as well. It is a two way street.
0 comments voice your opinion now!
developer responsibility opinion decision


DevShed:
Introducing the Chain of Responsibility Between PHP Objects
October 30, 2006 @ 12:18:00

DevShed is starting off a new series today with this first article talking about how to introduce the "chain of responsibility" method in how you use your objects.

In this three-part series, I'll show you how to create a chain of responsibility across different classes, which hopefully will give you a better understanding of how this schema can be implemented with PHP.

Since it's just the first part in the esries, they start with the whys and hows of the chain of command process before getting on with the actual code. For the foundation, they create some subclasses that will make the parts of the chain. Next up is combining them and, finally, making the "master class" to combine the links of the chain together. They use a "DataServer" example to work with local files.

0 comments voice your opinion now!
tutorial chain responsibility object process pattern subclass tutorial chain responsibility object process pattern subclass



Community Events





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


voicesoftheelephpant update release package podcast tool interview series install laravel introduction library community composer language framework version symfony security opinion

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