Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

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.

share|improve this answer
    
an interface might be helpful here too, then he could make it a bit more flexible –  hanzolo Sep 21 '12 at 17:46

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:

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.