Basically, I’m in the process of writing a website that interfaces with many popular websites (Facebook, Twitter, Youtube etc). My principal objective will be the same, however the way I accomplish my objective will be different for every site I support, because their layout is different and because I’ll have to script my requests based off the workings of their website.
The user chooses which particular website they want to use the service I offer for (i.e. do they want to use it for facebook, or for twitter, etc). And they can only choose 1 of these websites per request of my service.
I’m wondering what a good design principal/practice is when it comes to Rails modularization (this is my first Rails project, I’ve had lots of exposure to other languages though). Basically, the way I see it is, a user will submit their request to my controller, which will check what site they chose. My controller will then “load” a particular module (i.e. if they chose facebook, it would load the facebook module), which will contain all of the code for dealing with Facebook requests. It will then call this code in whatever way necessary, and serve results to the user.
So basically, my question is really coming down to best practice and design principles in regards to Rails. How do you think a good way to separate my code is in this instance? Should I have a class for every site I support (facebook, twitter, etc)? This is the only real option I can think of (because I’m not very familiar with Rails), however I’m sure there would be a better option, so I can limit the amount of code redundancy, as the goal of each class will be the same, it’ll just be a different technique to obtaining the goal (i.e. the method names will be the same for every class, etc).
Thanks!
Looks like the strategy pattern to me. You could do it like this (not sure where to put it in Rails).