Dependency Injection Breaks Encapsulation

[s_molinari]

@tony_marston404

That is why I have my GUI, business rules and database access in separate modules. This is the classic definition of the 3 Tier Architecture around which my framework is based. I have actually taken it further by splitting the Presentation Layer into two which then form the View and Controller of the MVC design pattern. All the Models then exist in the Business Layer, and all database access is done within the Data Access layer.

That “monster” class of mine is an abstract class which is inherited by every Model class. It does not contain anything which belongs in either the View, the Controller, or the DAO, therefore it is perfectly valid. I am correct according to Robert C. Martin’s definition, and I’m afraid that his definition carries more weight than yours.

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