Matthias Noback has posted a continuation of his previous article covering unary call sites and interfaces with this new tutorial with a way to reduce these call sites by making effective use of dependency injection and passing values with the correct context.

While reading David West's excellent book "Object Thinking", I stumbled across an interesting quote from David Parnas on the programming method that most of us use by default [about the process a machine uses to execute code]. It may seem like a very logical thing to do. And it's what I've seen myself and many other programmers do: "How do we implement this feature?"

[...] I described one situation in a previous article about read models, where I realized that we often try to answer many different questions by querying one and the same model (which is also the write model). By splitting write from read, we end up with a more flexible design.

The same goes for introducing interfaces, to achieve dependency inversion. We do a little extra work, but we thereby allow ourselves to get rid of a bit of "computer think".

He goes on to talk about singletons, service locators and registries and how dealing with them can get complex relatively quickly. He then shares a few possible solutions in the form of dependency injection and passing in the items needed for context rather than pulling them from another object. He ends the post with a summary of the combination of these two methods, showing how they can reduce the number of overall "call sites" for pieces of functionality in your application.

Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.

Federico Cargnelutti has a helpful post to his site today for the unit testing/TDD crowd about checking the retuned value from a stub of an object in your tests. He's using the built-in mocking framework here, not something like Mockery.

State verification is used to ensure that after a method is run, the returned value of the SUT is as expected. Of course, you may need to use Stubs on a test double or a real object to tell the object to return a value in response to a given message. [...] In PHP, for example, you dynamically type the return value within the body of the method. This means that PHP mocking libraries cannot check the type of the return value and provide guarantees about what is being verified. This leads to the awkward situation where a refactoring may change the SUT behaviour and leave a stub broken but with passing tests.

He gives an example of a few classes - a Presenter and Collaborator - and a test that mocks out the Collaborator instance, calling a "getStories" method on it. He shows a situation where all tests pass in the initial version, but after some changes to the return type, a test that should fail doesn't. His solution for the issue revolves around DocBlock annotations and the Return Value instead of the built-in mock object return method.

On the Shadow Fox Network, there's a new tutorial that shows how to combine the Apache mod_rewrite functionality with some PHP functions to make passing variables over your rewritten URL easy.

You can't pass variables well without adding more commands to mod_rewrite. So here you'll learn to add unlimited parameters to your links with only one simple PHP function.

He starts with a mini-refresher course on the contents of the previous article and moves to the simple rewrite example that makes it possible - a two line statement. Then, it's on to the PHP - again, a simple function that does things simply, grabs all of the parameters from the URL and splits them out into a global parameters array. He even includes a simple example as a tutorial you can try out with the demo.

On the Shadow Fox Network, there's a new tutorial that shows how to combine the Apache mod_rewrite functionality with some PHP functions to make passing variables over your rewritten URL easy.

You can't pass variables well without adding more commands to mod_rewrite. So here you'll learn to add unlimited parameters to your links with only one simple PHP function.

He starts with a mini-refresher course on the contents of the previous article and moves to the simple rewrite example that makes it possible - a two line statement. Then, it's on to the PHP - again, a simple function that does things simply, grabs all of the parameters from the URL and splits them out into a global parameters array. He even includes a simple example as a tutorial you can try out with the demo.