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? 
), 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.
Scott
2 Likes
FYI Tony was correctly told that his definition of Encapsulation (and OO concepts in general) were flawed almost a decade ago: http://bytes.com/topic/php/answers/569321-php-5-classes-public-protected-private/2 and he hasn’t budged an inch or learnt anything since then.
Off-Topic
With the recent update members now have the option in their Profile Preferences
Oh My. 
Scott
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:
http://www.tonymarston.net/php-mysql/abstraction.txt
http://web.archive.org/web/20090505194203/http://homepage.mac.com/keithray/blog/2006/02/22/#EncapsulationHiding
http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding
http://stefanoricciardi.com/2009/12/06/encapsulation-and-information-hiding/
http://nat.truemesh.com/archives/000498.html
Doesn’t that alone show your 9000 line Table class breaks the SR principle? Case closed.
Scott
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…
2 Likes
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.
Off-Topic
6 Likes
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.
Scott
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.
3 Likes
In two sentences, you’ve hit so many levels of the only issue here in this thread. Thanks for taking the more correct side.
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.
http://rossipedia.com/blog/2013/08/dependency-injection-considered-harmful/
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.
Scott
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.