I’m confused. The article in reference is one you linked to @tony_marston404, why is it on Jeff to justify a statement to an article you believe talks about DI appropriately?
2 Likes
Funny, then, that even on the wikipedia page for encapsulaion ( http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) ) information hiding is mentioned continually. “Nothing to do with”, eh?
and where are you getting this “original definition” from? The earliest reference I can find is this: https://scholar.google.co.uk/scholar?q=“dependency+injection”+oop&hl=en&as_sdt=0%2C5&as_ylo=1980&as_yhi=1995 from 1993 which actually says it’s an implementation of “inversion of control”. If you do the same search for “Inversion of control” you get back to this document from 1981 https://scholar.google.co.uk/scholar?q=“inversion+of+control”+oop&hl=en&as_sdt=0%2C5&as_ylo=1980&as_yhi=1985 which states:
Which, funnily enough makes no mention at all of “different implementations” or “possible alternatives”, it just lists it as a method of allowing the GUI to call the methods on the worker.
edit: Not that any of this even matters. Once again tony is changing the subject so he doesn’t have to answer the question “Why is an alternative better than DI? And how are you measuring that?”
They are not separate concepts if you must use one to enforce the other. Encapsulation does not mean information hiding, and it can exist without information hiding.
Please read my posts properly. You can have encapsulation without information hiding, but you cannot guarantee encapsulation has not been broken without it. It’s like saying “Securing your house is good”, “You cannot do this without a lock on your door” “A lock and security are not separate concepts if you must use one to enforce the other”.
You cannot guarantee your house has not been entered without a lock on the door. It doesn’t mean security and a lock are the same concept.
I’m still not sure what the point you’re trying to make is. It just seems like you want to divert attention from the actual topic at hand because you cannot back up the claims you’re making about DI.
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.