What is a good design model for my new class?

Question

I am a beginning programmer who, after trying to manage over 2000 lines of procedural php code, now has discovered the value of OOP. I have read a few books to get me up to speed on the beginning theory, but would like some advice on practical application.

So,for example, let's say there are two types of content objects - an ad and a calendar event. what my application does is scan different websites (a predefined list), and, when it finds an ad or an event, it extracts the data and saves it to a database. All of my objects will share a $title and $description. However, the Ad object will have a $price and the Event object will have $startDate. Should I have two separate classes, one for each object? Should I have a 'superclass' with the $title and $description with two other Ad and Event classes with their own properties? The latter is at least the direction I am on now.

My second question about this design is how to handle the logic that extracts the data for $title, $description, $price, and $date. For each website in my predefined list, there is a specific regex that returns the desired value for each property. Currently, I have an extremely large switch statement in my constructor which determines what website I am own, sets the regex variables accordingly, and continues on. Not only that, but now I have to repeat the logic to determine what site I am on in the constructor of each class. This doesn't feel right. Should I create another class Algorithms and store the logic there for each site? Should the functions of to handle that logic be in this class? or specific to the classes whos properties they set?

I want to take into account in my design two things: 1) I will add different content objects in the future that share $title and $description, but will have their own properties, so, I want to be able to easily grow these as needed. 2) I will add more websites constantly (each with their own algorithms for data extraction) so I would like to plan efficienty managing and working with these now. I thought about extending the Ad or Event class with 'websiteX' class and store its functions there. But, this didn't feel right either as now I have to manage 100s of little website specific class files.

Note, I didn't know if this was the correct site or stackoverflow was the better choice. If so, let me know and I'll post there.

Answer 1

caveat: any design suggestions are based on what i thought you wrote, and a bag of unfounded assumptions. Code something that works, and refactor it until a 'good' model emerges - you'll end up doing that regardless of where you start, so pick something that makes sense on paper or in your mind, and start with that.

caveats aside, it sounds like you have the following classes:

• Ad
• Website
• Event
• Scanner

The Scanner scans a list of web sites, looking for ads and events. The extraction regex/logic is specific to a particular web site (thus eliminating your switch statement), but if extraction is always a regex then you can pull that from a database table to instantiate web site objects as needed (or just pull the regex from a db or in-memory table).

in other words, soft-code the web site regexes if possible, so you don't have to have a subclass for each web site

don't worry about efficiency until it works and you're happy with the underlying model, then use a profiler to see where the implementation needs to be tweaked, if at all

i suspect that a 'good' model will also naturally be efficient

good luck!

Answer 2

I would also take your latter approach to Ads and Events, where they're both separate classes with a superclass that has title and description. Then add additional subclasses as needed.

If I understood the rest of your post, it sounds like you have multiple regexes for each website that extract the necessary info. In this case, as much as it might be painful, I'd create an individual class for each website that's responsible for parsing each site. I can easily see you having to modify your regex when a site changes, or finding that a regex is inadequate and you need additional custom logic to extract the information you need. Whenever you have to make changes to any parsing logic you'll know exactly which file to go to since it relates directly to that site. However, I'd define an interface that these websites implement that contain common properties/methods you'll need, so that the part of the program that uses these websites can deal with a generic "Website" type to get the Ads and Events (and future objects) instead of needing to know every specific type of site in your application.

As for creating the specific type of site you need, this is where the factory pattern comes in. Pass in a URL, get back a generic "Website" type. Internally, your factory does the work of mapping a URL to a specific type. It sounds like this is sort of what you're doing in your giant constructor, so I'd move that out and retool it into a factory class.

I understand it may be horrible to maintain hundreds of class files for individual sites, but if all these sites are unique I don't know what to say. One way or another you're going to have to have unique code for each one. Unless a bunch of ads or events all share something in common, like there's a bunch of DoubleClick ads and they all have the exact same parsing code, then you can reduce the number of classes by taking advantage of that.

Answer 3

Quick Answer: Use your approach if it makes your software work. However, look after repeating blocks of code, because you may want to move them to common class (or business layer) later on. Thus will ensure that you are constantly refactoring and refining your code.

In this situation, i try to stick with principles of KISS and YAGNI - meaning, "Keep It Simple Stupid" and "You Ain't Gonna Need It".

KISS - would refers to keeping your code with simple constructs and easy to understand, more simpler your code, easier to maintain it is in long run. YAGNI - refers to principle in keeping your code out off over-engineering with unnecessary chunk of codes, that you think will be used in future development.