Home/ Questions/Q 162329
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T11:22:17+00:00

I will explain the question by example: In zend framework, when you want to

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 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.

    • 0