Oh yeah, this thread is still going on? How surprising. If anyone actually notices, someone brought it to Reddit and it was very good read:
http://www.reddit.com/r/PHP/comments/31ulj7/dependency_injection_is_evil_another_gem_from_the/
3 Likes
LOL! I think we did a much better job here discussing the subject. 
Scott
we certainly covered it in more depth
1 Like
Though there were some nice quips in there that I found interesting. I havenât made it through the whole thing, but the first third was a bit interesting.
That whole thread on reddit looks almost like a free-for-all âWhack-a-Tonyâ. I noticed you threw in a whack yourself there Hall_of_Famer. LOL!
Iâd like to think I was (we were?) trying to help Tony, since I was/ am (we were/ are) speaking to him directly here. The fact he most likely doesnât want my (our) help is the issue I (we) might need to realize?
Maybe the public ridicule on reddit will help?
Or it might turn olâ Tony into even more of a PHP Scrooge?
Scott
Not always. An error event dispatcher has to get the root dispatcher that PHP will be calling through set_exception_handler, set_error_handler et al up and ready at all times despite the fact that, if all goes well, it will never be called. Usually a symptom of flawed design is more accurate.
lol yeah, it was kinda fun, wasnt it? I honesty think you guys were being too nice to him, if Tony would ever posted such things on Reddit he would get so much ridicule that eventually he would ragequit. The Sitepoint community is a help/support forum, while Reddit PHP is more of just an information exchange/idea forum. I guess this implies the differences. This thread was meant to educate, especially for junior developers who are still confused with the idea of Dependency. I think, theres a reason why this thread was opened again after it had been closed 3 weeks ago.
And I doubt help or ridicule would work on Tony anyway, what he would need is a business failure in which the clients were fed up. But I dont think it would happen, after all Tony was building a legacy framework designed to work for legacy applications. This pretty much dictates that his clients would not have a problem with his framework anyway. Just like if you build a software designed to work for Windows 3.1 or 3.2, the customers will complain how strange it looks on your windows 7 or 8 machine, but the rare ones who still use Windows 3.1 or 3.2 are happy. You are not a person who cant think abstractly, so I know you understand this analogy. XD
Anyway, Tony is more than satisfied with his work, so we should be glad for his accomplishment and thereâs little point in helping him, dont you think so?
Yeah. It is a fun, but futile effort.
Scott
You are making a fundamental mistake by assuming that the class deals with database access when in fact it does not. It deals with the Model in the Model-View-Controller design pattern whereas all database access is done in a separate Data Access Object (DAO) where I have a separate class for each DBMS. The Model is therefore concerned with the business rules which need to be processed when writing to or reading from a database table. If you knew anything about the Separation of Concerns you would realise that business rules do not belong in either of the Controller or the View, or even the DAO, so they are, in fact, exactly where they belong - in the Model.
I donât have complex hierarchies in my applications. Each business entity is a stand-alone class which inherits from nothing but a single abstract table class.
I find the idea of breaking up code into a number of smaller classes to make it âmore readableâ to be a ridiculous idea. I have already broken my application up into separate classes for the Model, View, Controller and DAO, and if my Model requires 100 lines of code of business rules then I would rather see them in one place than have to keep jumping from one class to another.
There is no limit on the number of methods or properties which a class may contain, nor is there a limit on the number of lines of code that a method may contain. The idea that each method should do âonly one thingâ can be taken to ridiculous extremes and result in software where each class contains only one method (if it contains more than one then itâs doing more than one thing, right?) and each method contains only one line of code (if it contains more than one then itâs doing more than one thing, right?). I have seen software written to that ridiculous level of separation, and it was infinitely less readable than as mall number of large classes.
I disagree. The golden rule of encapsulation is that ALL the methods and ALL the properties for an entity should be put into a single class. By arbitrarily splitting it into smaller classes just to satisfy a personal whim would violate the rule of encapsulation.
It is not monolithic, nor is it spaghetti code. If you bothered to look at my abstract class you would see that it contains a large number of methods, and each method is concerned with just one step in any particular operation which is activated from a Controller.
DI has nothing to do with encapsulation.
There is no limit on the number of methods that a class may contain, nor on the number of lines of code within a method. There is also one thing you seem to be forgetting - that âmonsterâ class is not a concrete class, it is an abstract class that contains every method that may be used in a concrete class depending on what that class has been requested to do.
DI, like every other design pattern, is only a good idea when used appropriately.
The fact that lots of developers implement DI at every possible opportunity does not mean that it is a good idea. Lots of people some pot, or cheat on their spouses, or fiddle their expenses, but does that make those practices a good idea?
I agree that OOP is about being modular in design, which is why my framework is a combination of the 3 Tier Architecture and the MVC design pattern. I have more reusable code in my PHP framework than I ever did in either of my previous frameworks, and probably much more than in any of the more popular frameworks.
Exactly. It will never be called if all goes well, but it is there just in case something unexpected happens.
And yet you still cannot define what makes DI âInappropriateâ in those scenarios.
HmmâŚI think otherwise.
encapsulation means that the internal representation of an object is generally hidden from view outside of the objectâs definition.
âinternal representationâ is another way to say âdetailsâ, right?
With dependency injection, the client which uses a module or service doesnât need to know all its details
sounds like DI supports encapsulation to me. Although one speaks of objects and the other speaks of modules or service, modules and services are also just objects or groups of objects too, right?
Right, there isnât a written rule and you are again avoiding the point. Your monster class ignores the Single Responsibility Principle.
In object-oriented programming, the single responsibility principle states that every class should have responsibility over a single part of the functionality provided by the software,
Your class has more than one responsibility.
So are you seriously saying, an abstract class is a reason to have 9000 lines of code in it? Because, possibly some of the methods could be used in some concrete class? If you say yes, then you will be sinking even more into your obvious quagmire of ignorance about OOP programming. Funny thing too is, not one instance of the word âabstractâ can be found in your abstract class, which means it can be instantiated on its own, which means IT IS NOT an abstract class.
What kind of argument is that? DI is a great design pattern!!! I thought we had that understood. The fact it might not be useful everywhere does not take away from its usefulness. And you compare DI to smoking pot? Could it be youâve smoked some before you wrote your answer? LOL! 
You are claiming to have more reusable code than todayâs frameworks, yet you believe in 9000 line classes as being âokâ? Right. I am not going to try and prove you wrong, but I donât believe you are right for one minute. Your stuck in a lonely world Tony. I wish youâd come out of it.
Scott
I have defined it several times in this discussion, so I suggest that you learn to read.
You defined it as:
Which as I said is utterly meaningless without something to quantify it. As I said twice itâs like saying âWhether or not the car is more appropriate than a is appropriate than a bike boils down to a simple question - how many passengers will be travelling. If the answer is âmore than oneâ then a car is appropriate.â. It, like your argument about DI falls flat because it doesnât define what appropriate is and itâs not a case for the bike when the car can be used for one or more passengers. You need to somehow define WHY DI is less appropriate (or another solution is more appropriate) to make your case. Just saying âBecause it isâ is nonsensical. You need to actually describe how youâre measuring âappropriatenessâ in order to claim that âX is more appropriate than Y when Z is trueâ, which you have not done.
Itâs a circular argument⌠and doesnât actually define why that is the case. Please learn to read.
The original definition of encapsulation was limited to implementation hiding, not information hiding. The two are entirely separate. The fact that some people choose to redefine what it means to suit their own purposes does not change the original definition, and that is the only one that I am prepared to accept.
You can think what you like, but it does not change the fact that encapsulation was defined many years before DI was even thought about, so to say that encapsulation requires DI is plainly wrong. It is as daft as saying that any design pattern which uses objects or classes is part of encapsulation.
Just because they use terminology which has some similarities does not necessarily make it right to say that they are identical, or inextricably tied together.
It depends on your definition of SRP. As a guideline as use this definition provided by Robert C. Martin in this article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html
That is why I have my GUI, business rules and database access in separate modules. This is the classic definition of the 3 Tier Architecture around which my framework is based. I have actually taken it further by splitting the Presentation Layer into two which then form the View and Controller of the MVC design pattern. All the Models then exist in the Business Layer, and all database access is done within the Data Access layer.
That âmonsterâ class of mine is an abstract class which is inherited by every Model class. It does not contain anything which belongs in either the View, the Controller, or the DAO, therefore it is perfectly valid. I am correct according to Robert C. Martinâs definition, and Iâm afraid that his definition carries more weight than yours.
Right. That is 9000 lines of reusable code which exists in an abstract class and which is inherited by every Model class in my application. I have over 300 Model classes, so it means that the code is reused over 300 times.
I also have 1 DAO which is shared by every Model in my application. Do you?
I also have 40 Controllers which are shared by every user transaction (of which there are over 2,000) in my application. Do you?
I also have 3 View components - one for HTML, one for PDF and one for CSV - which are shared by every user transaction within my application. Do you?
Unless you can match my levels of reusability you have no right to lecture me on how to write reusable code.
If you cannot understand what that means then I shall not waste any more of time in trying to educate you. You clearly have a closed mind and no amount of logical argument will have any effect on you.
We agree to disagree, so unless you have something new to bring to the discussion I shall ignore you.
If you need 2000 variants of anything you do not have reusable code. If you had reusable code you would reuse existing âuser transactionsâ rather than needing new ones each time.
Your code violates SRP and a 9000 line class is inherently a bad idea. Listen to Scott, heâs pointing you in the right direction. If you actually accepted criticism rather than trying to defend your bad decisions youâd be better off.
1 Like
What a cop out. You are wrong, you cannot back up your arguments so you choose to ignore me.
Play the âLALALA FINGERS IN EARSâ game all you want, it just prooves to me and everyone else that you are incapable of backing up your claims.
Tony your argument is this:
âI always travel by bikeâ
âItâs more appropriate than a car because I am the only passengerâ
âWhy is it more appropriate?
âBecause I am the only passengerâ
âwhy isnât a car appropriate
âBecause I am the only passengerâ
â But you can still use a car canât you?
âYes but I am the only passenger so I dontâ
âWhy canât you use a car
âI canâ
âSo why donât you
âBecause Iâm the only passengerâ
âBut thatâs not stopping you use a car
Can you honestly not see why this argument makes no sense? Of course you can but you simply canât admit when youâre wrong.
Your argument is non-existent and you know it.
Where was that ever said? I said it supports encapsulation and I even added âindirectlyâ, knowing that it is sort of bending the definition of encapsulation. Still, DI supports the concept of modularity, which encapsulation supports too and that is how I see they are in common NOT identical or inextricably tied together. You seem to read things that arenât there and get defensive or argumentative about unsaid things unnecessarily.
Iâll get to the rest of your reply later.
Scott