Dependency Injection Breaks Encapsulation

My statement in post #430 was in response to a statement made by Jeff_Mott in post #423 in which he said

No. My agreeing with you in that one post shows that I can admit I am wrong, when I am wrong. And I am not agreeing with you in your views, but in your indirect correction of my post.

Just to prove my point, while we are agreeing that an application should be loosely coupled, modular and testable, would you also agree when I say, your framework is none of the above?

Scott

Those statements are contradictory. On the one hand you are saying “You can have encapsulation without information hiding” but on the other hand you are saying that “without information hiding encapsulation is broken”. Which is it?

No they’re not.

My house can be burglar free without a lock on the door however, without a lock on the door I cannot guarantee I won’t be burgled (ok practically that’s not true but as an example imagine the lock was unbreakable)

Definitely not. There are plenty of articles on my website which document the modular structure of my framework, and which talk in detail about the levels of coupling, cohesion and reusability which I have achieved, so until you can develop your own framework which has comparable levels then I shall ignore all your petty and groundless accusations.

This is unfortunately Tony’s basic problem. He only sees a part of a concept or twists even the meaning of a concept, in order to fit his own needs. He doesn’t learn what is actually being said/ taught/ communicated. His reasoning for his 9000 line monster class being within the definition of SRP is another perfect example.

Scott

And that part is easy. He based it on the article you provided and all the comments you’ve made thus far in this topic… so again, I sit here confused.

The articles on your website don’t tell even half the story of the truth your code speaks Tony.

How about explaining how you unit test your code? Or does unit testing also solve a problem you don’t have?

Scott

I think Tony already explained in one of the older posts he made, that he never did Unit Testing and doesnt plan on doing it anyway. Apparently he doesnt see this as a problem, and hes proud of the fact that he does no Unit Testing.

To set a good example. To not fall to their level. Because you don’t need everyone to agree with you. Because you don’t have to justify every single opinion you have or action you take.

Pick any one of these, really.

3 Likes

I’d be so bold to also say this is another sign of the Dunning Kruger effect. You know I am getting at something, which you can’t properly answer, so you call my arguments petty and groundless accusations, as if it would take me having written a framework to be able to tell Tony the Great he is doing something wrong. It is you considering yourself an expert, because you have built a framework, which is unfortunately further from the truth than you’d like to realize. You are an expert of your own framework, which I gather very few people have the want to master. The reason nobody wants to master it or use it is because you are NOT an expert at OOP.

I don’t have a beef with you or your framework Tony. I have a beef that you come to forums like this one or LinkedIn, where I got to know you first, and you make arguments nobody really wants to hear and you make arguments, which might lead the unwitting to think wrongly about OOP methodologies. And you write blog posts that are arrogantly wrong and insulting. It is the “in the land of the blind, the one-eyed man (thinks he) is king” issue.

In some ways, I get the feeling you actually know you are wrong in your actions and thinking, deep down inside, but the big hairy monster called Radicore Framework causes you to be like you are. Although, I don’t know how an inanimate object can control ones own opinion, viewpoints and actions, you seem to be in that terrible position.

In other words, if you said yesterday, today I am throwing away everything I had done in the past (and you can make that decision), you’d know that today, you’d have to do your OOP differently…do OOP properly. You’d have to actually learn and use the better methods and practices 99% of the devs use today (and used in the past too) and stop looking at the other 1% for validation for doing things wrong, as being right.

The other thing you’ll be able to do, if the above ever happened is, you’ll be able to ask questions and instead of have it be a lead in to argue your incorrect view points and defending your framework. It will be a way to learn and constantly expand your knowledge, which is what a community is for.

Scott

2 Likes

This is a very good point. Tony, this is a serious question: If you were starting a new project that wasn’t based on RADICORE, maybe a e-commerce website or something else that’s not suited to it, would you use things like autoloaders, visibility modifiers, unit testing, php5 constructors, namespaces, DI and all that other stuff you call “optional”?

I 100% agree with this. I’ve always come to the conclusion that the reason tony is so argumentative is because he thinks if he can justify his bad practices to us (or others) and people agree with him, he doesn’t have to admit his code is awful by any standard.

What’s more worrying, though is Tony’s unwillingness to listen or learn. I look back at code I wrote 5 years ago and realise how much I’ve improved and can identify what I’d do differently now, and most importantly why. In 5 years I’ll probably do the same looking at code I wrote today. To me that’s a good thing as it allows me to grow as a developer. Tony, however, looks back at his 10 year old code and says “Ahh still perfect” which demonstrates an inability to grow as a programmer or learn new techniques.

Some of the code I wrote 10 years ago is as bad as Tony’s (No 9000 line classes, mind, but all the other stuff with mixed responsibilities, procedural code shoe-horned in to classes, global state, etc… however, I was 18 with no real formal training or experience!), the difference is I am happy to admit it was bad and can highlight how I’ve improved as a developer and you know what, if I hadn’t written it, I wouldn’t have learnt from it. Tony, on the other hand, once he’s written something it seems the ideas within it are then set it stone and can never be changed or even questioned.

1 Like

Incorrect. I still do unit testing, integration testing, system testing and user acceptance testing, but it is not automated.

It says quite specifically that Dependency Injection can be applied wherever one class sends a message to another. This implies that I still have a choice as to whether I use DI or not, and I choose not to in those circumstances which are outside the original design parameters.

Just because some people have (incorrectly) assumed that information hiding is the same as implementation hiding does not make it so.

Haha wow that’s some good post-rationalisation there. Again we’re back to this nonsense about “original design parameters” Stop trying to weasel your way out of actually making a valid point. Given any two methods you can, by some metric argue that one is better than another. You have yet to show a situation where a singleton is measurably better than DI (And remember you need to tell us the metric you’re using!)

This statement is also true, of course:

A singleton can be applied wherever one class sends a message to another. This implies that I still have a choice as to whether I use a singleton or not, and I choose not to in those circumstances which are outside the original design parameters.

Your argument is dead in the water here, tony and you know it.

And for the hundredth time: Stop changing this subject and answer this question:

Why is a singleton more appropriate than DI when there is only one possible implementation of the dependency? And how are you measuring that “appropriateness”?

I disagree. Robert C. Martin’s article clearly demonstrates a situation where DI has distinct benefits. Just because the same technique can be used in other circumstances for other purposes is no justification for saying that DI should be used for every single dependency regardless of the circumstances.

Don’t you see how nonsensical this argument is? The inverse is also true: It’s also no justification for not using DI in other circumstances. The very paper you’re quoting simply shows one benefit.

Once again I point you to:

and

This is the argument you are making here. It’s a fallacy so stop making it, it’s not a valid argument.

Information hiding is not important. Changing class properties from “public” to “private” maes absolutely no difference to the code which is executed. All it does is impose restrictions on developers.

…and if you cannot see why imposing restrictions on developers is important then there really is no point continuing. I’m not going to explain it to you again but there’s plenty of information (not hidden!) easily accessible via google.

I keep asking you this and you keep ignoring it: What is the point you are trying to make? Or are you just diverting attention away from the question you cannot answer about DI?