Is there a better way to handle data abstraction in this example?

Question

I'm building an application that retrieves Sharepoint list data via a web service SPlists.Lists. To create an instance of the web service, I have the following class:

   class SharepointServiceCreator
   {

        public SPlists.Lists createService()
        {
            listsService.Url = "http://wss/sites/SPLists/_vti_bin/lists.asmx";
            listsService.Credentials = System.Net.CredentialCache.DefaultCredentials;
            SPlists.Lists listsService=new SPlists.Lists();
        }

   }

I'm concerned that this isn't good OOP abstraction, though, because in order to create this service elsewhere in my application, I would need the following code:

class someClass
{
 public void someMethod()
 {
  SharepointServiceCreator s=new SharepointServiceCreator()
  SPlists.Lists listService=s.createService()
 }
}

Having to use declare the instance of listService in someMethod as type SPlists.Lists seems wrong, because it means that someClass needs to know about how SharepointServiceCreator is implemented. Or is this ok?

Answer 1

This is an example of the factory pattern. To adhere to existing conventions, rename SharepointServiceCreator to SharepointServiceFactory and perhaps make it static so that you don't need to create an instance every time to need a reference to the service.

Answer 2

To take it as step further, you could create an interface, and then pass in your implementation. This kind of takes it to the next level of flexible, and you can do this later down the line when you discover the functions you're actually going to need. A factory could be used at a higher level to determine which implementation you pass "someClass" in the constructor argument, Or you can use the factory all over the place (probably not my 1st choice)

Create the interface:

Interface ICreateService {
   CreateService();    
}

and get some fancy-pants Dependency Injection going, which could be automated with some kind of "Container" to go even further

class someClass
{
     ICreateService SharePointServices;

     //constructor injection
     public someClass(ICreateService SharepointCreateServiceImplemented)
     {
          SharePointServices = SharepointCreateServiceImplemented;
     }
     public void someMethod()
     { 
          SPlists.Lists listService=SharePointServices.createService()
     }

 }

Now you can use this class for any object which implements ICreateService.

You could definitely do this with a factory to, it will depend on where you want to locate your implementation:

class someClass
{    

     public void someMethod()
     { 
         SPlists.Lists listService= (ICreateService)GetServiceFactory("SharePointServiceCreateor").createService()
     }

 }

Where the factory would look like this:

ICreateService GetServiceFactory(string ImplentationStringOrEnum)
{
    switch(ImplentationStringOrEnum)
    {
        case "SharePointServiceCreator":
            return (ICreateService) new SharePointServiceCreateor();
    }
}

The whole principle is to define your implementations outside of the classes which are using them, that way you can switch in and out easily: