PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 31 Mar 2015 17:04:13 -050030http://www.phpdeveloper.org/news/21759http://www.phpdeveloper.org/news/21759
Mathias Verraes has a new post to his site today with an interesting idea when it comes to handling the architecture of an application: using objects as the contracts for behavior. He suggests that the objects themselves define how other pieces of code should interact with them, not necessarily external services. He illustrates with an invoice and appointment example.

Of course invoices do not pay themselves, but that's not what an object model is trying to do. An invoice exposes the behaviour of being able to be paid. That ability is in fact essential to what it means to be an invoice. The behaviour is an inherent property of an invoice. If an invoice doesn't have the ability of being paid, there's no point in issuing invoices at all. In other words, the contract of an invoice object declares that its interface includes payment as a feature. Its promise to the outside world is that it allows an outsider to pay for it. Encapsulation of state and behaviour is the core idea behind objects.

He wonders why, if this is more true to the "object-oriented programming" ideals, the idea of encapsulating procedural code as objects is so widespread. He suggests a lack of education on the subject or maybe even confusion from spoken languages themselves.

Link: http://verraes.net/2014/09/objects-as-contracts-for-behaviour/]]>Mon, 29 Sep 2014 11:10:33 -0500http://www.phpdeveloper.org/news/21693http://www.phpdeveloper.org/news/21693
On the Inviqua techPortal today Marcello Duarte lists out his top ten favorite limitations with the PhpSpec testing tool. PhpSpec is a tool where the tests are driven by specifications, focusing on the "how".

PhpSpec is enjoying a growth in popularity lately, probably related to the recent release of 2.0. Lots of people have been playing with it and trying to get to grips with what it can do. Naturally they try to do the same things they would with other testing tools. Soon they find out they can't. "Oh! This PhpSpec has some many limitations… I can't do this… I can't do that…". Ironically, other people make positive comments about the same "limitations". So I decided to publish a list of my top ten favourite limitations of PhpSpec, and why I love them so much.

His limitations list includes things like:

I can't test private methods

You can't have code coverage

I can't use a data provider

My tests can't follow a code standard

Check out the full article for more of his list and some code examples ot help clarify each topic.

Link: http://techportal.inviqa.com/2014/09/11/my-top-ten-favourite-phpspec-limitations/]]>Thu, 11 Sep 2014 11:15:31 -0500http://www.phpdeveloper.org/news/21107http://www.phpdeveloper.org/news/21107
Paul Jones has a new post to his site today talking about the importance of naming when it comes to the use of different patterns in development. He also makes some recommendations to help clear up some of the confusion around different names for the same things.

[Thoughts in a] Grumpy Programmer mailing-list essay got me thinking. [...] I completely agree with the emphasis on using a common vocabulary. One issue here is that naming things properly is very, very hard. It is one of the only two hard problems in programming. Are there any rules (even rules-of-thumb) that can we use to make it easier to pick good names for the classes and concepts in our projects?

He reminds readers that code is no place for a "novel context", that is that it's not meant to be instructions for humans, but instructions for computers. He points out that patterns are more about behavior than the name you give them and that picking a name that's "close enough" isn't a good idea. He also recommends that you avoid picking a name for a special context the code might be involved in.

Link: http://paul-m-jones.com/archives/5952]]>Wed, 30 Apr 2014 09:29:42 -0500http://www.phpdeveloper.org/news/20549http://www.phpdeveloper.org/news/20549
In this new post to his site Cal Evans shares an interesting and seldom mentioned part of the SPL in PHP, the CachingIterator, and an interesting behavior he found with its use.

In the course of writing my next book, "Iterating PHP Iterators", I found something very interesting. I have a short chapter on the CachingIterator. One of the flags in the CachingIterator is FULL_CACHE. It was during my experiments with that, that I found…an anomaly.

He includes a snippet of code showing the behavior that does work, just not exactly as expected. He found that to have the values correctly cached, he had to loop through the entire iterator before trying to use it. He also answers the "just rewind() the iterator" comments with another code snippet showing it with the same behavior as before. His final example is one that does work as expected, unsetting the correct index and replacing the value as requested.

So today I learned, don't use the FULL_CACHE flag on the CachingIterator. I am not sure what the FULL_CACHE flag is supposed to do, but it doesn't seem to do anything useful at the moment. Also, it can screw things up for you.

Link: http://blog.calevans.com/2013/12/19/the-php-cachingiterator/]]>Fri, 20 Dec 2013 10:19:29 -0600http://www.phpdeveloper.org/news/20348http://www.phpdeveloper.org/news/20348
In a previous post Anthony Ferrara looked at design patterns and their use (and usefulness) in modern applications. in this new post he continues the series but focuses more on a strategy to move past them related to inheritance.

In my last post, I talked about revisiting the concept of Design Patterns and questioned how useful it is to "learn" them. The conclusion that I came to was that you are better served by focusing on how objects communicate rather than traditional patterns. Well, that's not the only "traditional concept" that I think we should move beyond. So, let's talk about inheritance...

He starts with a bit of definition about what inheritance actually is (for a little context) related to classes, not traits or interfaces. He compares two ideas around this inheritance - the actual implementation of it in the code and the specification of it, the planning a "promise" the structure defines. He discusses the separation of these two ideas and that what matters is that the specification is implemented - how doesn't matter as much. He gets down to the most basic concept behind the idea of inheritance, the idea of a "contract", that defines the "agreement" the implementation puts into practice.

Finally, he gets down to what he calls "the key" behind inheritance and encapsulation of functionality into desecrate parts - behaviors. These allow you to know what kind of functionality comes from which class/object without having to guess. Methods have behaviors and objects are collections of these, combining to make a larger object-centric behavior.

Object Oriented Programming is all about abstraction. Each layer is an abstraction of code below it. Using "types" makes this difficult, because often we don't have real-world analogs to represent each layer. After all, an abstraction is specifically not a type. It's the concept behind it. With behaviors, this comes naturally.

Link: http://blog.ircmaxell.com/2013/11/beyond-inheritance.html]]>Tue, 05 Nov 2013 13:08:24 -0600http://www.phpdeveloper.org/news/18012http://www.phpdeveloper.org/news/18012
In his recent postGonzalo Ayuso shares some "strange behavior" he found with method visibility in his recent development:

Normally I feel very comfortable with PHP, but not all is good. There's some things I don't like. One is the lack of real annotations and another one is this rare behaviour with visibility within the OO. Let me explain this a little bit.

The problem came up as a part of a recent refactor where a protected method, when called from an object injected into another class, threw an "access" error that it was called from the wrong context. He reported it as a bug but was reminded of how PHP handles exposure - on the class level, not the instance of a class level.

]]>Mon, 28 May 2012 18:09:08 -0500http://www.phpdeveloper.org/news/17677http://www.phpdeveloper.org/news/17677
Volker Dusch has a new post reminding us about what the "unit" part of "unit testing" means - small chunks of testable parts in an application.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say "A method! Because we test methods!"? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class "still works" and you need to "fix the tests" the your tests are worth a lot less as they don't really give you that cozy safety net that they should provide you with.

]]>Thu, 15 Mar 2012 08:24:03 -0500http://www.phpdeveloper.org/news/17544http://www.phpdeveloper.org/news/17544
The Boston PHP User Group will be having their next meeting tonight (the 15th) at 7pm at the Microsoft N.E.R.D Center in Cambridge. The featured speaker for the evening is Chris Shiflett, a well-known member of the PHP community. He'll be speaking on "Security-Centered Design: Exploring the Impact of Human Behavior".

Join Boston PHP and O'Reilly Author Chris Shiflett as we take you through a fascinating talk on the human behavior and social aspect of security. We'll explore topics such as change blindness and ambient signifiers, and we'll show some real-world examples that demonstrate the profound impact human behavior can have on security. If your a designer, developer, human interaction designer, you won't want to miss this talk.

]]>Wed, 15 Feb 2012 07:11:37 -0600http://www.phpdeveloper.org/news/17537http://www.phpdeveloper.org/news/17537
PHPMaster.com is back with the third part of their series looking at the internals of the Yii framework (specifically, its components). In this latest article Steven O'Brien focuses on how the framework uses behaviors.

A behavior, as it is called in Yii, is a manner of combining objects at runtime to extend an object's functionality. Behaviors are an excellent way to decouple code and keep ever expanding systems maintainable. [...] We can not reuse our code effectively because PHP doesn't support multiple inheritance. The Yii behavior system is a way of achieving multiple inheritance by implementing mixins.

He gives an example of working with a user that's connecting to your application just to get to a third-party billing system. They show how to take this functionality our of your generic "User" class and make a behavior out of it. This functionality can then be attached to the User object (via an attachBehavior call) and used directly. He gets into how Yii does this magic, showing how it appends it to a special value in the class and the __call method checks the method call to see if it exists in one of these special classes.

]]>Tue, 14 Feb 2012 09:28:34 -0600http://www.phpdeveloper.org/news/15608http://www.phpdeveloper.org/news/15608
In this recent post to his blog Michael Kimsal asked about the usefulness of the __get and __set magic methods and the sort of code he usually sees along with it.

For a long time I've held that __get and __set in PHP were not all that hot - mostly because it's solely error handling. There's no way to deal invoke __get or __set behaviour for properties that are defined on a class. [...] For those who insist on using __get/__set, I *typically* see this [messyy] sort of style code. The effect is to cram a bunch of unrelated code in to the __get/__set overloading methods.

He suggests an alternative to the "cram it all in __get" approach - callbacks to other methods in the class to handle the different variable possibilities. In the comments there's other suggestions on how to get the same job done differently - mapping property values with __call, valid uses for getters/setters and a pointer to an internals discussion RFC about this same thing.