In this post to his site Adam Wathan shares a screencast talking about changing APIs (the structure of your code, not like REST/SOAP APIs) and how "API drift" could cause problems in your testing.

One of the risks of writing your own test doubles is that the API of the double can fall out of sync with the API of the real implementation.

In this screencast I walk through an example that explains: how interfaces can provide a false sense of security, why tests make better contracts than interfaces and how to run multiple implementations against a shared set of contract tests.

You can watch the screencast either through the in-page video player or over on Vimeo directly. It's about 10 minutes long but it covers an interesting topic that could throw you if you're not careful in your testing/code changes.

Kristopher Wilson has a quick post talking about how he thinks you can use interfaces effectively in PHP applications.

Yesterday, a question appeared on Reddit about the purpose of interfaces in PHP. While I was too late to the party to provide an answer to that thread (at least that would get noticed by anybody), I thought it was a great topic of conversation. So let's take a look at interfaces in PHP.

He introduces some of the basics around interfaces and provides some sample code showing how they're created and used (and extended). He talks about some good practices for implementing them in your classes and how this fits into the world of dependency injection. He also includes a bit about type hinting based on the interface implemented and how they can be seen as "contracts" in your code.

The SitePoint PHP blog has a new tutorial posted showing you how to integrate Twig into a Laravel application with the help of the recently added "contracts" feature of the framework. Twig is a templating library that aims to be fast, secure and flexible for data output in multiple contexts.

Laravel 5 is finally out, and with all the awesome features it brings. One of the new architectural changes is the new Contracts Package. In this article we are going to understand the reasoning behind this change and try to build a practical use case using the new Contracts.

He starts with a brief look at what Contracts are and what it means to use them in a Laravel application. He then shows how to define the package installation (via Composer) to pull Twig in and register it with the application for future use. He creates a simple service provider to register Twig and return a new "TwigFactory" instance. This instance extends the "FactoryConnect" implementing the "ViewFactory" and, along with a custom "TwigView" object can be used just like you would normally output information via Blade.

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.

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.

Larry Garfield has posted some of his thoughts on return values and reminds you about consistent return types, regardless of the result.

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

He proposes a new rule of thumb: "If your function returns a collection, its null value return must also be a collection." A more broad version of this might be: "make your return types consistent." It's all about predictability and the contracts you have between different parts of your code. If a user calls your method expecting to be able to loop over the results, they'll be disappointed with a "false". He talks some about using and throwing exceptions more effectively for error handling and answers several "but wait..." arguments for his return strategy.

James Fuller has a new post to his blog today about a way you can enforce contracts in your PHP using a combination of type hinting and value checking.

Design by contract is an important concept for controlling what type of input your methods or functions can receive. One of the most dangerous features of PHP is that functions will still execute even when they are missing required arguments, by emitting a warning instead of an error. In this post, I am going to walk through some of the solutions available to deal with this problem.

He shows how to alter a basic function to first use type hinting to catch when a variable is the wrong type (in this case checking for an array and stdClass) which causes a Fatal error and makes the function not execute. He includes sample code for the type/value checking option and also includes a suggestion of using PHPUnit's assertions as another option.

Finally, he introduces the ContractLib tool (from Stuart Herbert) that makes use of closures to enforce checks - his example checks to see if something is a string and that it's not empty.

Stuart Herbert has two new posts to his blog showing how to use the ContractLib tool he's created to define programming "contracts". In the first he shows some sample usage of the tool and in the second he compares the functionality of ContractLib's features and PHP's own "assert" method.

ContractLib is a simple-to-use PHP component for easily enforcing programming contracts throughout your PHP components. These programming contracts can go a long way to helping you, and the users of your components, develop more robust code.

In his example tests he shows how to set a pre-condition on a method's input ensuring that it will always be the correct datatype (array). In his comparison with PHP's "assert", he lists out some of the features that either one has and notes that ContractLib allows you to be much more flexible with your checking than just simple statements.

In this recent post to his blog Stuart Herbert introduces a system he's created to handle "contracts" in PHP development - ContractLib.

Programming contracts are tests around functions and methods, and they are normally used: to catch any 'bad' data that has been passed into the function or method from the caller, and to catch any 'bad' data generated by the function or method before it can be returned to the caller. These are pre-condition and post-condition tests, and they are tests that either pass or fail.

He points out that by having contracts you not only increase the robustness of your code but you also save time not trying to hunt down data-related issues. Using pre-conditions, you can can check data to ensure things like correct formatting, data that's out of range and data that might be missing. His ContractLib comes with a set of tests that provide good examples of how to use the functionality. Installation instructions are included.

Cal Evans has posted the final point in his "Six Ways to be a Better Client for your Developer" series seeking to make the client/developer relationship more stable and enjoyable for both sides. This latest tip involves the paperwork part of the relationship.

Good fences make good neighbors just as good contracts make for good developer/client relations. At the very least your agreement with your developer should contain a complete description - in non-vague terms - of each feature to be built as well as a paragraph description of the overall project.

He emphasizes that, if the feature or change is not included in the documentation from the start, it's not a part of the project. Making assumptions on vague definitions will only cause problems down the road, so be specific in what you want.

If negotiating the contract with your developer is a hassle, consider it your last opportunity to walk away and find another developer.