Pretty sure that you’ve already familiar with Dependency Injection (DI) design pattern and with types of dependency injections: constructor, setter, interface. Also in some sources, you can find parameter dependency injection type.In this topic you’ll find yet another type of DI — namespace! Prerequisites I expect you already familiar with idea behind DI and you have clear understanding why do you need this. If not — please read basic information about DI first. Let’s assume that our application is Ukrainian 🇺🇦 VISA center which can provide, approve or decline VISA to any country in the world, for simplicity will consider only the European Union here. First of all, we need interface,file : src/Domain/Interfaces/VISA/EuropeanUnion.php Now we have implementation for non-visa-free case (let’s call this case “review”), file : src/Infrastructure/VISA/Review/EuropeanUnion.php And another one implementation for VISA-FREE case,file : src/Infrastructure/VISA/Free/EuropeanUnion.php Target The main aim — is to have somewhere (for example in file )super simple code like this: index.php Solution Use namespace Dependency Injection and configure your file: composer.json and run: (it’s important, please don’t forget run this command). php composer dump-autoload Test Now just run command: and you’ll see: php index.php 'You have to provide documents for review.' Now please update with next content: composer.json and run: and run: you’ll see: php composer dump-autoload php index.php 'Your request is approved!' That’s it! Congrats! Comparison with other approaches Alternatives: Factory Method (or even Abstract Factory), constructor or setter Dependency Injection or Strategy designs patterns. Yes, these patterns can be considered as an alternative, but all of them require you to write technical code like: class Factory{public static function create($name){if (class_exists($name)) {return new $name();}}} or public static function getInstance(string $name){if (!isset(self::$instances[$name])) {$className = "App\\Infrastructure\\" . ucfirst($name);if (!class_exists($className)) {throw new RuntimeException("Unknown class: $className");}self::$instances[$name] = new $className();}return self::$instances[$name];} also in the real-world project, it’ll look more sophisticated, maybe . Also you’ll mix your declarative style code with something like: like this $name = ($parameter === 'free') ? 'VISA/Free' : 'VISA/Review';$visa = Factory::create($name);// and only now$visa->approve(); And also in case of using these patterns you have to have all code in one place (one repo), but imagine that and may be huge subsystems with own factories, strategies, microservices, internal business logic implementations etc — it may turn out to be nightmare. VISA/Review VISA/Free With Namespace Dependency Injection you can create dedicated packages (repos) for interfaces, , etc. Every package only has to know about interfaces, no more. So it’s more flexible, easier to maintain, extend and re-use!You can even have separated development teams for every package, if you have really huge project. VISA/Review VISA/Free And most important — on application level you‘ll have super simple code in and all internal details won’t confuse you. Your project will be more predictable because behavior won’t vary at runtime depending on different circumstances, it’ll work strictly accordingly to your configuration.And also as a bonus, IDE (like PHPStorm) will help you more, because it won’t scream on code like: . declarative style new $className(); Performance comparison Namespace DI is that all other types of dependency injections!!! Because this approach has no configs or infrastructural stuff mentioned earlier or or something else…, hence in this way PHP won’t waste time executing redundant code during each http request! faster yaml DI Container Why this approach not popular Because this type of dependency injection possible only in PHP due to the way how autoloading works. It’s impossible to do the same event in JavaScript, no use to speak about other languages. As result — this technic not wide spread. With other types of dependency injections it’s possible to change application behavior at runtime, but with Namespace DI — it’s impossible. Conclusion In case you don’t need to change behavior (or internal implementation) of your application at runtime but need to have opportunity to change it from config file (even ), plus reduce execution time— you can consider as an option Namespace Dependency Injection! composer.json
