This question is really based on PHP, but could be valid for other dynamically typed, interpreted languages and specifically the methods of generating code insight and object browsing in development environments.
We use PHPStorm, and find intellisense invaluable, but it is provided by some limited static analysis and parsing of doc comments.
Obviously this does not lend well to obtaining dependencies through a container, as the IDE has no idea of the type returned, so the developer loses out on a plethora of (in the case of our framework anyway) rich documentation provided through the doc comments.
So we start to see stuff like this:
$widget = $dic->YieldInstance('WidgetA', $arg1, $arg2, $arg3, $arg4...));
/**
* @var $widget WidgetA
*/
So that code insight works.
In effect the comments are tightly bound, but worse they come out of sync when code is modified but not the comments:
$widget = $dic->YieldInstance('WidgetB', $arg1, $arg2, $arg3, $arg4...));
/**
* @var $widget WidgetA
*/
Obviously the comment could be improved by referencing a Widget interface, but then we might as well use a factory and avoid the requirement for the extra typing hints in the comments, and dic complexity / boiler plating.
Which is more important to the average developer, code insight / intellisense or ‘nirvana’ decouplement?
First of all, complete decoupling is not necessarily an ideal condition. There will always be some coupling between classes, methods and properties, otherwise it would be impossible to communicate any meaningful information. Taken to its logical extreme, complete decoupling resolves to passing a pure object (i.e. a pointer/reference) with no shape whatsoever, which must be cast to the correct type before any meaningful information transfer can take place, and the only way that can occur is by transferring information about the type to cast to.
The same tradeoff occurs with statically typed and dynamically typed languages. Consider the dynamic keyword in C#. The dynamic keyword allows late binding of method calls, deferring resolution of those calls from compile time to runtime. Intellisense stops working. Why? Because there’s no way to predict what method signatures are going to be available on the dynamic object until runtime. But lack of Intellisense doesn’t mean that the dynamic keyword is useless; it just means that you have to accept the absence of Intellisense as a tradeoff for the benefits of using dynamic.
In the C# world, the way one would solve this problem is to inject an object that conforms to a specific interface. This allows enough shape to draw meaningful information from the object, while still allowing different implementations of that interface to have different underlying behavior. The interface still benefits from intellisense, while providing the flexibility to change the behavior by swapping the implementation.
1
This is exactly what PHP interfaces are for: presumably there is some functionality (methods) that are shared by both WidgetA and WidgetB, otherwise you could not substitute them. So those methods go into an interface and are documented there, and you can declare the $widget variable to have that interface as its type.
Of course this basically means that you’re doing the same work as you’d do with a statically typed language like Java, so you might as well use one since you’ve already found that you’re missing the benefits of static typing…
1