In large PHP OOP application is it bad practice to have procedural code outside of class definitions i mean that works independently from objects? e.g. intertwine OOP and Procedural code in same application.
Should i try generally to keep all code inside Class'es as much as possible? I mean of course i got to have code outside class to instantiate an object but then i should not have much more logics outside of objects right?
So if number 2 is true i should try to have as little static properties and methods inside my classes as possible because their only purpose is to be manipulated from outside of the object?
-
2It would maybe be helpful to ask the same question the other way round: You could as well ask "Is it bad programming practice to squeeze everything into objects?" - And the answer would probably be "yes", because at times that's trying to fit square pegs into round holes.– tofroCommented Oct 30, 2016 at 14:24
2 Answers
Well it is bad OOP-practice, because having procedural code outside of classes does not conform to OOP-design principles. Whether it is a bad practice in general to mix paradigms (OOP and procedural) in the same code base is a different question, and not objectively answerable.
Some believe having the whole code base conform to the same paradigm is the best practice, and some OOP languages have been deliberately designed to discourage writing non-OOP code. Other languages are deliberate designed as multi-paradigm, and allow you to deliberately choose when to program in an OOP manner, and when to use procedural or functional code. Personally I prefer the last approach and consider OOP more as a tool to be used only when needed.
You are specifically asking about PHP. So I would ask: are you using a framework? Which one? I think with PHP most frameworks for large scale web-based systems it is common to write mainly OO code.
Apart from file that bootstraps the framework, I haven't seen much procedural PHP code in years.