Dependency Injection Breaks Encapsulation

[s_molinari]

@tony_marston404

DI has nothing to do with encapsulation.

Hmm…I think otherwise.

encapsulation means that the internal representation of an object is generally hidden from view outside of the object’s definition.

“internal representation” is another way to say “details”, right?

With dependency injection, the client which uses a module or service doesn’t need to know all its details

sounds like DI supports encapsulation to me. Although one speaks of objects and the other speaks of modules or service, modules and services are also just objects or groups of objects too, right?

@tony_marston404

There is no limit on the number of methods that a class may contain

Right, there isn’t a written rule and you are again avoiding the point. Your monster class ignores the Single Responsibility Principle.

In object-oriented programming, the single responsibility principle states that every class should have responsibility over a single part of the functionality provided by the software,

Your class has more than one responsibility.

@tony_marston404

There is also one thing you seem to be forgetting - that “monster” class is not a concrete class, it is an abstract class that contains every method that may be used in a concrete class depending on what that class has been requested to do.

So are you seriously saying, an abstract class is a reason to have 9000 lines of code in it? Because, possibly some of the methods could be used in some concrete class? If you say yes, then you will be sinking even more into your obvious quagmire of ignorance about OOP programming. Funny thing too is, not one instance of the word “abstract” can be found in your abstract class, which means it can be instantiated on its own, which means IT IS NOT an abstract class.

@tony_marston404

The fact that lots of developers implement DI at every possible opportunity does not mean that it is a good idea.

What kind of argument is that? DI is a great design pattern!!! I thought we had that understood. The fact it might not be useful everywhere does not take away from its usefulness. And you compare DI to smoking pot? Could it be you’ve smoked some before you wrote your answer? LOL!

@tony_marston404

I agree that OOP is about being modular in design, which is why my framework is a combination of the 3 Tier Architecture and the MVC design pattern. I have more reusable code in my PHP framework than I ever did in either of my previous frameworks, and probably much more than in any of the more popular frameworks.

You are claiming to have more reusable code than today’s frameworks, yet you believe in 9000 line classes as being “ok”? Right. I am not going to try and prove you wrong, but I don’t believe you are right for one minute. Your stuck in a lonely world Tony. I wish you’d come out of it.

Scott