Should I design my software according to a paradigm or according to the tools the language supplies?

Question

I will explain the question by example: In zend framework, when you want to add a functionality to the view class, you can use what is called a Helper class.
A helper class is a class that has one method (Same as name of class) that becomes available in each of the views (by reflection the helper method is wrapped by a view method)
It is very organized and clean, BUT, it means an extra include for each such helper and some playing with reflection. Both things takes their tole on performance.

My thought was instead of developing a Helper per method I want to add to the view (Each in a different file), I will write one helper with a list of C style functions (i.e. not class static methods, real functions) which can be used only in the View class (as View helpers are include only in the View).

So, this is mixing some procedural with OO, but the performance benefits are visible, and anyway, helpers are single methods which usually don't need to maintain state...

Some will say: "So go with procedural, it is better performance wise", No, I am very well aware of the benefits of OO, except in this small matter,
So, should I stick to a single paradigm or mix them?

Answer 1

first: OOP is a subset of structured programming, which is a subset of procedural, so you're not going so far 'paradigm-wise' as you imply. ("paradigm", what an ugly and overused word)

second: OOP, is a design style, not a language feature. using functions instead of methods doesn't make your program any less OOP, as long as you maintain the (conceptual) encapsulations.

third: even the most OOP code in PHP has to use the built-in functions at some level. so, almost by definition, using functions can't be "anti-OOP".

fourth: yeah, OOP is one of the best design styles out there, but there's no virtue on 'staying true to a vision'. after all, they're all tools in your toolchest. if the OOP constructs of your language of choice can't deliver what you need for this specific instance, then use other tricks to make it work. if you're worried about code maintainability (and who isn't?), then encapsulate the 'hacky' parts inside the interface presented by your objects, so it doesn't leak.

Answer 2

You should design according to your non-functional requirements. For example, if the throughput is your goal, you should go for the performance path. But if the maintainability is your goal, maybe you should make your code more readable than putting all unreadable performance optimized code in.

Frameworks leave you spaces to decide things. OOP itself is just a concept. So it is not a sin to use C-style functions in OO program, IMHO. If it is appropriate than go for it.

Answer 3

The only way to answer your question is to give pros and cons for each design decision.

Generally going for procedural design is best when there is minimal state-control involvement, for stateless processing, one-shot data transformation. Examples for procedural processing would be: all kinds of mathematical functions, string transformations, array transformations, direct memory access and the like.

While OOP is great for state control. It is great to use OOP for things like UI elements (millions of textbook examples), socket programming (open, listening, closed, other states), protocol implementations also benefit. Anything that involves multiple instances and state machines implements itself wonderfully.

It is a common practice then, to mix one-shot functions for simple processing with complex state controls in classes. Methods in classes would be using functions for their internal data processing.

Hacking something together might work for the short-lived, non-production code. But after multiple upgrades you might end up looking for spaghetti sauce for your code. It is always good to have a deliberate design for the code as opposed to ad-hoc coding.

Another aspect is the common practice in the framework. If it is a common practice in zend framework to have mixed implementations (OOP and functional for simple transformations), there is little reason not to. If it is not, better stick with one approach, otherwise you will face maintainability issues and other people will have to spend hours and days understanding your code.

It is also necessary to explore every bit of technical limitations of doing whatever you do:

• If compiler (as opposed to interpreter) and linking is involved, make sure there are no problems there
• If your code is split into modules (libraries), be sure to check that mixing things will not break compatibilities
• If there are performance concerns, quantify them; once you do, decision might become easier
• Do many test applications to verify your choices - unexpected crashes, slow start / stop, data corruption, jumping over hoops to get things done all indicate that the choice is not optimal. Knowing why is as important as knowing what.