dependency injection - A controller that might violate Single Responsibility Principle? -

Refers to this comment,

When a class had a very long list of arguments It may be a "code odor" that is trying to do a lot of your class and is probably not following the single responsibility principle. If your class is trying to do too much, then its code Consider re-implementing in many small classes which consume one another .

What should I do about this controller class below - what is it trying to do "too much"?

  class controller {public $ template; Public $ translation; Public $ auth; Public $ article; Public $ nav; Public function __ composition (database $ connection, $ template) {$ this- & gt; Template = $ template; $ This- & gt; Translation = New Translator ($ connection); $ This- & gt; Navy = new navy ($ connection); $ This- & gt; Article = new paragraph ($ connection); $ This- & gt; Auth = new Auth ($ connection); } Public function getHtml (if (isset ($ _ request ['url'])) {$ item = $ this-> article- getRow (['url' = & gt; 'home', 'Is_admin' = & gt; $ this-> auth-> i_admin]); $ this-> template- & gt; path;}}}  

< P> How can I break it into smaller sections - if it is a controller that keeps these basic classes that I need to output to a page?

And what should I do It follows the principle of principle?

_{Note: This short version will be because I'm at work. I will expand the evening}

So ... the violation has been followed in your code:

• SRP (more detail - SOC): Your administrator Input, authorization, data collection, preparation of template with data, and verification of rendering is accounted for. Also, your article db abstract and domain arguments both Is responsible for.

• LoD : You are passing $ connection only because you have given it to other structures Will have to be given on.

• Encapsulation : All of your class attributes have public visibility and can change at any point.

• Dependency injection : While your "controller" has many direct dependencies, you only have template (which is not actually managed by the controllers in the appropriate MVC Should go).

• Global Status : Your code depends on $ _ request superglobal.

• Loose coupling : Your code is tied directly to the names of sections and the footprint of the consultants for those sections, which you start in the constructor .