Abstract class or not?

[JMWhittaker]

I'm working on a project that uses the YouTube data api. On creating a useful API for my application I'm trying to see what approach would be best practice.

The YouTube data api is REST based and has a specific URL for an action. There are many common elements to each action call, like sending headers with authentication credentials then obviously handling success, error etc on URLLoader calls.

So my question on best practice is this. Would I be better off creating an YouTube service class as a singleton. This service class would then call other classes to do particular actions like login, getUserVideos etc. For these action classes I would have an abstract base class. In this base class I could handle the creation of a URLLoader and handle the events like errors, complete etc.

So if I created a new action class called LoginAction.as that extends my abstract class and overrides the URL and possibly the handleComplete method to do specific things.

Does this sound like a good approach or not? Looking around at other AS3 API's there are many approaches.

Opinions?

[flexy]

Would you really want your service class as a Singleton? I can understand why you might want to enforce a single instance, but I would still say that a client class would want to be able to create an instance of the object, rather than referencing the static instance property. As a Singleton, you'll be able to get a reference to it from anywhere in your app, which on a large app serviced by multiple developers will inevitably cause code smell - Do you actually need to enforce a single instance? What's the worst that could happen if two or more are created? Might be worth evaluating
If you do decide a single instance must be enforced, create it in a way that still requires an instance to be created by the client class, then set an internal static property that prevents the constructor from running a second time. That way, you have a single instance, and it'll also sit correctly in the rest of your application framework as a proxy.

As for your actions, I think you're definitely going down the right route by creating some kind of abstraction of the base funtionality that each will perform, then subclassing this to add the bit and pieces for each action. I'd probably say that it's worth typing your action objects to an interface though, just in case the implementation in the base class changes, or you want to add another API.

Good luck