Dependency Injection Breaks Encapsulation

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.


Tony’s argument is so futile at this point he’s resorting to misrepresenting everyone else’s points.

So you pull out two sentences out of a blog post that says MVC is a good design, because it separates concerns and then you say, well, because old Uncle Bob says that is a good design, then my 9000 line class is also a good design? Am I understanding you correctly? Because, it is totally bogus logic.

The blog post by Uncle Bob was about a design that was way too coupled to the Rails framework. It had nothing to do with what good separation of responsibility is all about and what it means to code structure. It is speaking at the architectural level of design. It’s the difference between a strategy and tactic. Strategy is MVC. Tactic is splitting code into smaller chunks with a clear and singular “reason for change” (which is also from Uncle Bob). Your 9000 line class has a good number of reasons to change.

If the functionality of the “custom button” changes, your 9000 line class would need changes. What the heck does a custom button have to do with a “Table” object anyway?
If you decided to change the form data to add xml, your 9000 line Table class would need changes.
If something changed in the internationalization (language system), your 9000 Table line class would need changes.
If something changes in the scrolling thingamajiggybopper, then your 9000 line Table class would need changes.
If task initialization needs changing, your 9000 line Table class would need changes.
If your file system tasks need changing, your 9000 line Table class would need changes.
If your “popups” need changing (popups? WTF? :flushed:), your 9000 line Table class needs changing.
If your search needs changing, your 9000 line Table class needs changing.
If your validation requirements change, your 9000 line Table class needs changing.
If anything with your _cm customizable what-ever-it-is needs changing, your 9000 line Table class needs changing.
If something in the DDL logic changes, then your 9000 line Table class needs changing.
If something with the DML logic needs to be changed, your 9000 line Table class needs changing.
Oh, and of course, if something with your Table logic changes, then you need to change your monster class.



FYI Tony was correctly told that his definition of Encapsulation (and OO concepts in general) were flawed almost a decade ago: and he hasn’t budged an inch or learnt anything since then.


With the recent update members now have the option in their Profile Preferences

Oh My. :open_mouth:



1 Like

I disagree. Uncle Bob’s article clearly identifies that the GUI, business rules and database access should be separate, and that is exactly what I have done.

Just because you think that does not make it true. That abstract class contains code that may be needed in any Model class, and none of that code belongs in an alternative class such as the View, Controller or DAO.

Incorrect The custom button code in the abstract class is just an empty wrapper for application-specific code which goes in the concrete class.

Each of my Model classes represents both a business object and a database table, and an operation on one of my Model classes may have a custom button on the screen. If such a button is pressed in activates the customButton() method in the Model class in order to execute whatever business rules have been defined.

No it wouldn’t. All XML generation and SL transformation is performed in a separate View object.

Wrong on every count. If you bothered to look at my code with an unbiased eye you would see that most of the methods in the abstract class are empty. This means that at runtime nothing happens unless the concrete class contains code for that method.

That opinion is not universally accepted. Encapsulation was NEVER meant to mean information hiding, as explained in the following articles:

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.