So I’ve taken on a project at work that I’m having a hard time attacking, and I’d love some feedback and suggestions.
I work for an online retail store where we have an old, +7k-line script that we use to create various product feeds (mostly for CSEs like Google Products, Pricegrabber, etc). It’s become a complete mess, mostly because each feed is slightly different and because there is almost no separation of concerns.
I’ve been tasked with refactoring it, a task I volunteered for with gusto, and pretty soon I need to come up with a design. My main goal is to have a system that’s easy to maintain, and easy to add new feeds as needed. If performance suffers a bit that’s not a huge concern, though increasing performance would be great if it doesn’t interfere with the first two goals.
Until now, most of what I’ve worked on has been fairly linear and imperative; data comes in at the top and goes out at the bottom. But because of the various feeds with various needs, I wonder if an object-oriented approach would be beneficial. OO programming is still a bit of a mystery to me, so this problem has been a bit difficult to attack.
My basic idea is as follows; objects exist for each main concern (images, product descriptions, file handling, etc). Then, each feed has an object (perhaps implementing an abstract class) that talks to the other objects, asking for the information it needs. For instance, the Pricegrabber object feeds the Image object a list of products along with some parameters (maximum image size, etc) and the Image object returns a list of products with corresponding image urls. This way, the Pricegrabber object doesn’t know or care how the Image object finds its urls, or what mysql tables the Image object used or created; it just enters a list of products and gets a list of image urls. Pricegrabber does this with every main object until the feed file is created.
Main questions:
- Does this design pattern make sense? Is there a better pattern I could use?
- Does OO seem like overkill for what I’m trying to accomplish?
- While we normally use Perl for our reports, would it be worth it to use PHP instead? If so, why? (I’d love to use Python or Ruby but IT has put the kabosh on that).
Does this design pattern make sense?
What you’ve described is not a pattern, but rather kind of informal description of application architecture. You better don’t think of it right now.
Try to create a domain vocabulary which describes all the things your application deals with:
- feed (which has defferent fields),
- product (which consists of photo, description, price, etc.),
- customer/user,
- order,
- …
This would help you understand which classes/interfaces you’ll probably need. Patterns would come next, as (and if) you need them.
If you’re new to OOP, you shouldn’t start using patterns right away. Just learn the basics and try to write the most simple code that does the job. Don’t write the code that you don’t understand (see Cargo cult programming).
Does OO seem like overkill for what I’m trying to accomplish?
Totally not an overkill. OOP is just a way of solving problems, not a technology. Of course, it can be used in a wrong way, but what you have now (solid piece of bare structural code) is much more wrong.
While we normally use Perl for our reports, would it be worth it to use PHP instead?
I don’t have any experience with Perl, but I think it doesn’t matter that much. Pick what you like more, just remember that PHP is simpler (IMO) and has larger community (which isn’t necessarily better).