Class Decomposition Overkill?

[dennis-fedco]

So I've been writing code trying to apply the separation principles -- MVC, and aside from MVC SRP (Single Responsibility Principle), and so on.

 

I now end up with classes that do this kind of type of function (one class per line)

*  connector class that redirect to the real Controller

*  read GET state, validate GET and direct to proper Action,

*  class that preps SQL, runs SQL and cleans any data it receives

*  class that sends data to be combined, receives results, and forwards the results to View

*  class that combines data and produces results

*  view is by itself in a template file ..

 

I am looking at this class soup and thinking ...  oh my ... I go 4 classes deep just to get some data here.  Am I overdoing it?

 

In the past I would have had a single file for controller and a single file for view.  No classes.  Maybe some helper functions from function library loaded by require()

 

Alternatively, I could tweak OOP that I will have a single Controller class that does everything and forwards things to View.  But now my Controller only tries to route things and do business function, and business function is in another "business" class, and if business class needs data, it calls model class, and if model or business class need a helper function, they call the "helper function" class. 

So through all the class calling I am doing passing of vars to keep the execution thread going...

 

What are your thoughts on the SRP/separation movement?  

I think it creates a lot of classes and it makes things a tad complicated.   Looking at Zend Framework library code I have experienced the same type of "what the heck is this class for" and trying to chase execution thread through 10 or so classes when it is just a simple "submit a form, process data, return results" type event.  I want things to be simpler.

[dennis-fedco]

what I mean is  ... in "simple" procedural PHP coding days when something was wrong on a page of the website, I knew the files I was to look at, where the error was likely to hide. 

 

Now, in frameworks, you need to check routes, aliases, classes, usually dialing into proper directory and diving deep into the inter-connected class collection, to find the culprit bug in a class or class collection.

 

It sometimes feels like digging through garbage to find the proper line(s) of code.  Not talking about bad code, but reasonably well separated one.

In procedural coding, most stuff was on single page.  In OOP/separation of stuff, most stuff is scattered between view, model, controller, storage, multiple folders, and such.

Not entirely convinced that OOP with SRP is better.  It's conceptually more separated, but practically, it seems convoluted to maintain.  Maybe it depends on one's workflow and how they work with code and maybe it works best for some people.

[hansford]

Just my opinion, others may feel different, but yes. I've went down the same road and it takes a lot to accomplish anything.

Maintenance was suppose to be easier yadi yadi - but because the code is so deep - it's not easier. The more time you think about writing perfectly uncoupled code the less time you spend being productive and actually writing code. Maybe the guru's have this all figured out and one day we may too, but for now - we need to write the best code we can without losing productivity.

[KevinM1]

OOP definitely incurs the cost of overhead. Not only do objects themselves have overhead, but your conceptual structure can get more complicated.

 

OOP is a different way of thinking. The currency of OOP is objects. There's no way around that. The whole idea is that, outside of initialization, you have a potential network of objects that are passing messages back and forth to each other. That's why documentation, project structure, and meaningful errors/exceptions are paramount.

 

That said, I understand your pain. I've been using Symfony 2 for all my projects for the last year+, and the online documentation is woefully bare and incomplete beyond the basics. So I've often had to dive deeper than I've ever wanted to figure out why certain errors have popped up. But that's been an issue of poor documentation and bad naming practices (why is the symfony bundle buried so deep?), and not of OOP in and of itself.

 

So, if you're going to go full OOP, be sure to document as you go. Document not only the classes themselves, but the app's workflow so you and other people can follow the chain.