Dependency Injection Breaks Encapsulation

Doesn’t that alone show your 9000 line Table class breaks the SR principle? Case closed.


1 Like

You know, for three people who keep claiming that “you’re done”, there’s still an awful lot of bickering back and forth…


Indeed and usually I’d let it fly, but tony isn’t just wrong, he’s lying, avoiding the question and genuinely giving people bad advice. Someone needs to call him out on this nonsense.



The problem is you understand the difference between them but not the relationship. In PHP and other similar languages like Java the only way to guarantee encapsulation is information hiding. My second year students who have been programming a lot fewer than 10 years understand this and if you haven’t worked out your own by now I’m not going to be able to teach you here.

Anyway, I’m glad that by omission that there is no reason to not use DI.

Agreed. Though, as a side effect, I am also learning too. For instance, Tony pointed to an article, which also pointed to another article about the “Tell, don’t ask” principle (I’d actually call it a paradigm) of OOP encapsulation. It’s the single most pertinent principle that Tony constantly regurgitates in his argumentation about encapsulation and it sort of actually defends his poor 9000 line monster class, if you happen to read only the first sentence and forget about the rest. Martin succinctly describes the principle he believes in as “co-locating behavior and data”. I knew about that, but never considered it as “Tell, don’t ask” from a simple functional perspective. I know taking that “way of thinking” can actually help me do a better job at OOP programming now. So I am thankful for this “argument” and for those rare gems of learning.

Though, if you do read on in Martin Fowler’s article, he talks about “GetterEradicators”, when people take this principle too far and Martin actually says he doesn’t use (and I understand the word “use” as “propagate” or “teach”) the “Tell, don’t ask” principle himself, because of this.

I think in Tony, we’ve found another person who takes this principle way too far. He isn’t a “GetterEradicator” though. Tony is a “MonsterBuilder” and completely misinterprets both the art of encapsulation in OOP and at the same time ignores or redefines SRP, all in the name of protecting his poor OOP work. And even worse, he loudly and arrogantly tells everyone else, they are wrong too.

The fact he doesn’t want to accept he is basing all his argumentation on misconceptions or twisting of OOP principles only shows he’s missed the OOP bus at one point (actually probably from the beginning) and could use some help “getting it”. (Too bad he doesn’t ask for any). I actually want him on the right bus. But if you ask Tony, we are all on the wrong bus.

Like I said earlier, the PHP world needs passionate developers. We just need passionate devs with an open mind to always improve and not someone telling us, our own efforts to improve and our ways at looking at OOP are wrong, without substantiating those differing opinions with at least partially related facts.

If he’d release his mother hen mentality over his framework and his perspectives and just say, “Ok, I did this many years ago, I was still learning at the time and I do see where I can improve it and my outlooks on OOP too.” Then we can all go home.


Post edited by @Jasmine to remove inflammatory and inappropriate language. Be nice.

1 Like

You have, very eloquently, as has @s_molinari. One day when Tony is inclined to follow best practice, he’ll appreciate the effort you both went to help him understand. That day isn’t today or tomorrow or probably next month, so let’s talk about issues other than Tony’s personal view in this topic.


In two sentences, you’ve hit so many levels of the only issue here in this thread. Thanks for taking the more correct side. :wink:

Does DI break encapsulation? Nope. It doesn’t. (Edit: see below) Not if you look at the whole picture of SOLID. This is a great counter to the “DI is bad” argument, which is admittedly at a higher level than the “DI breaks encapsulation” argument.

Yes, using DI for every situation isn’t necessary. That isn’t an argument made by anyone I know of. Yes, DI is a good pattern, when used properly. Yes, DI helps with modularity and testing. Two core aspects, which any modern, medium to large OOP application should have, especially when there is more than one developer working on or with it, which is like ALL of the time. So, through inference, DI is used all of the time. It is fact and not an opinion or an argument. It is why some say, we shouldn’t ask “IF” we should use DI, but when and how to use it properly, because you WILL need it. When you get DI and the other abstract concepts of OOP right, that is when you can truly say, you understand the art of OOP.

Edit: While taking a shower right after writing this post, I thought about it and then decided I’d like to change my answer to the question “Does DI break encapsulation?” from “Nope. It doesn’t” to “It doesn’t matter.” Why? Because the benefits I mentioned above with fitting into SOLID outweigh any possible lower level “issues” DI might have. In other words, they become irrelevant.


Those are not variations of the same thing, they are entirely separate units of work (or user transactions) as far as the user is concerned. Tasks such as “Create Customer”, “Create Product”, “Create Sales Order”, “Create Invoice”, “Create Shipment”, “Create Inventory Item”, “Create Purchase Order” and “Create Timesheet” are examples of such transactions. Web sites typically have a small number of user transactions whereas enterprise applications can have thousands.

For your information all 2000 user transactions share one of my 40 reusable Controllers.

Not according to my interpretation of SRP.

To say that “DI supports encapsulation” implies that there is a relationship between the two. There is no such relationship.

Then I suggest you look at the comments made by TomB who says repeatedly that because I COULD use DI for every dependency that if I do not then I am not following “best practice”. I have said time and time again that DI was created to deal with a particular set of circumstances, and when those circumstances DO NOT EXIST in my application then I ABSOLUTELY REFUSE to use DI. If that makes me a heretic in the eyes of the “paradigm police” then so be it.

This “best practice” of yours is not defined in a single document, or in a single place. It is scattered all over the internet or in various books and has different information depending on which articles or books you read.

There is no single thing known as “best practice” which is universally accepted by all developers. Each group is entitled to follow practices which are best for them, in their circumstances, and for the types of applications which they write. I follow “best practices” that have stood the test of time, and I refuse to change what works for me on the say-so of a few individuals who clearly spout nothing but unadulterated dogma. I am a pragmatist, not a dogmatist, so my aim is to build software that my customers are willing to pay for, and not to look “kewl” in the eyes of some unknown developers.

Wrong. Each Model class holds the business rules for each business object (which in my application is the same as a database table) while all database access is handled by a separate DAO. This allows me to switch the DBMS between MySQL, Oracle or SQL Server without having change any Model class.

Wrong. Encapsulation was NEVER meant to mean information hiding, which is a view that every one of those articles supports.

As I said, if you haven’t managed to figure it out on your own by now you never will but you can’t say “WRONG” and then demonstrate that you didn’t even read what I said.

Again you’re using straw man arguments and misrepresenting other peoples position. Where did I say that encapsulation meant information hiding? I said that information hiding is the only way to guarantee encapsulation in PHP and Java.

Nobody has said you MUST use DI either.

Would you agree, when I say that any decent middle to large application or framework, which multiple developers work on, should aim to have decoupled, modular components and be testable?


To be fair I have said you should use DI unless you’ve got a better alternative and can explain how you’re defining "better"and nobody has managed this. DI cannot be used when you don’t know the class name you’re using but that is often better delegated to a factory anyway.

Hmm…I don’t know. You should do DI or you must do DI? There is a difference. :wink:

“Should” to me means, you are saying it makes more sense, if you do do it. “Must” means to me, you are saying you have no other choice than to do it. I don’t think you are saying that. Are you?

That is Tony’s whole argument. He says, he has a choice. You say Tony should use DI, which I agree with. Tony then twists that around to say, he mustn’t, because he does DI “his own way” and only when he sees fit to use it.

And, as you mentioned, he doesn’t prove his way is a better one. He only says, it functions in his framework, so it must be at least as good and that is the fallacy he is stuck in.

Oh, but I am just a dogmatic noname developer, so what do I know?


1 Like

EDIT: I posted in the wrong thread - moved to: Are today's major frameworks capable of enterprise capable applications? - #139 by fretburner

What is the issue, exactly, if you acknowledge that while you prefer your way of doing things, others are entitled to their own way?

Tony, as much as you can, please consolidate your replies into one reply - you can quote multiple people in a reply. It makes it easier to view the thread :slight_smile: