Object Oriented PHP Question

[dennis-fedco]

I currently have 3 big long PHP functions that correspond to 3 different product lines for which code is written for.

 

Each function outputs certain sections of a PDF file for each of the 3 lines.  A product line can have things like (Specs, Engine, Assembly, Job, etc).  Each secion has slightly different computation to be done, and some product lines share certain secions, but not the others.  i.e. all 3 have the need for the Specs section, but only 2 need Engine section, and so on. 

 

OO code says: 

• create a general supporting class for all 3 product lines, then extend the class for each specific product line
• separate each section generation into its own function put them into the general class.  Have extended classes take and customize what they need,
• probalby some more OO stuff, like separating each class into a separate file, doing some clean-up, maybe doing some dependency injection to initialize things, or the like.

But I am thinking:  here we have a big long function with everything for each of the product lines.  Yes, there is some code duplication, and yes it is not OO, it is procedural right now, but the benefits of procedural here vs OO in this case is that

• I can leave these functions as-is, as they are written now - no need to rewrite code
• It is all right here in one file.  I do not need to hunt for OO objects or methods spread out in different files if I need to change something with a product line, it is all right there!   I can customize that product line as as needed.  I do not see the need to often change all 3 product lines, but if I do, all the 3 functions are in the same file, I can search and modify code right there.  I get the benefit of seeing all the details and all the steps for each product line in each file.  There is no abstraction.  It is a little tedious I confess, but it is all in one place.

Why do we have OO paradigm now?  Is it that in my case I do not need OO or am I missing something?  I do not want to do OO just for the sake of it being OO.  I am concerned that me reworking this code into OO will not really create me much benefit, but create "convert this to OO" work and the code will just sit there afterwards not really gathering much direct benefit from such conversion.

[dalecosp]

First engineering maxim: if it ain't broke, don't fix it.

OO vs. procedural is not some kind of 4th-grade urinal competition.  It's a choice made in design, and, it takes some good brains to decide what the appropriate design methodology is.

If OO code makes for easier reading/maintainability or faster execution, then you might change it.  If it's procedural and fast, and well-documented and not hard to maintain (as you claim it to be), you have no need to change it.

[gristoi]

think of extensibility in this. Sure, for now it is good in one file and you can 'see' all the code in one file. If connivence is your worry then that is what IDE's are for. Using one such as PHPStorm lets you search for code in hundreds of files in a matter of seconds, Links between class method names and adds support for helping you write good clean code.

 

you need to take into consideration:

 

What happens if the lines(brand) expand? will you maintain a single file with 4,5 6.....100 different product lines?

 

What happens if you are asked to start producing the outputs in XML, or RSS? In procedural your code will end up getting messier and more fragmented.

 

But dalecosp is right. Unless you want to learn OOP, or the code is not going to grow, then stick with procedural.

 

Personally, when i moved into OOP many moons ago i have never looked back. t is very rare that i use anything but oop ( but there are occasions when i just need a procedural script)