Dependency Injection vs. no Dependency Injection

[chrischi1989]

In order of the beginner approach of this project, I think this topic should be discussed because the way I see it: Dependecy Injection is some kind of a tipping point where things are getting more complex as a beginner could understand.

For example:

public function doSomething() {
     $myClass = new MyClass;
}

This is still easy to understand even for beginners in OOP.

But the more experienced users knows about the disadvantages of this hard coded dependency like (just to make it clear at this point) that the specific object needs to know some bits about it's environment and that such things are hard to unit test.

The next thing is when you use DI with namespaces. IMHO you can't expect that a beginner has used/heard about namespaces, so to make it more beginner (user) friendly you start defining class aliases like this:

class_alias('My\Fancy\Namespace\MyClass','MyClass');

Furthermore you can't expect that a beginner knows what a TypeHint is.

Considering that beginners (usually) don't unit test their code (and neither do I) we just having the issue left, that the object needs to know it's environment. Before I know about dependency injection, I tended to use the registry pattern to keep the needed dependencies at least at one place only.

I know this isn't the best solution but something like this

public function doSomething() {
     $myClass = Registry::get('myclass');
}

should be also easy to understand for a beginner.

Personally I'd prefer that we continue using dependecy injection and explain the principes behind this by creating beginner friendly readme files for this and other patterns we might use. But I also have no problem with not using DI.

But these are just my thoughts about this.

[Ma27]

Furthermore you can't expect that a beginner knows what a TypeHint is. Well, as I remeber, @Hippodora should write something about OOP and TypeHints are one of the most important conzepts in an OO System.

$myClass = Registry::get('myclass'); No, this is imo not a clean interface. I implement it like this: public function __construct(MyClass $myclass) {}

If we set the hint for an interface and make the class implement that interface, we have a better abstraction and if we want to extend the game later, it will be much easier

[LinuxDoku]

In this case an interface is too much abstraction. We have to focus on beginners and beginners write concrete code which solves a problem, so we should support this.

Interfaces would confuse them (I see this every day when I have to teach our trainees how to write good code ;-)). At least for the moment - maybe they learn it and refactor the code later, when they undertand why interfaces are so important.

In my opinion the DI is the right way, after understanding what the DI Framework is doing, they should be able to use it. It's very straightforward and with correct TypeHints autocompletion in any good IDE works ootb.

I dont like class aliasing, cause runtime code is very hard to debug. I would consider using speaking namespaces and class names and force the usage of them. No magic, simply logic and at least with copy and paste you can't do something wrong ;-)

[BlackScorp]

@LinuxDoku simply logic and at least with copy and paste you can't do something wrong ;-)

you made my day :D Copy&Paste is the root for all evil

[LinuxDoku]

Haha, I mean copy and past of classnames and namespaces :P

On 28 Aug 2014, at 21:27, Vitalij Mik notifications@github.com wrote:

@LinuxDoku simply logic and at least with copy and paste you can't do something wrong ;-)

you made my day :D Copy&Paste is the root fo all evil

— Reply to this email directly or view it on GitHub.