# Different implementation of an Interface along with additional parameters

I am designing an interface for 2 distinct implementations as follows:

1. Perform operations without client credentials ( for my local applications)
2. Perform operations using security token. (for web applications)

Interfaces are as follows :

interface IContactService
{
void Add(Contact c);
void Update(Contact c);
}

interface IProxy
{
string Token { get; set; }
void SetToken(string token);
}


and below are the implementations :

public class ContactBusinessImpl : IContactService
{

private IContactService _contactService;

public ContactBusinessImpl(IContactService contactService) {
_contactService = contactService;
}

public void Add(Contact c)
{
_contactService.Add(c);
}

public void Update(Contact c)
{
_contactService.Update(c);
}
}

public class ContactBusinessProxyImpl : IContactService , IProxy
{
public string Token { get; set; }

public void SetToken(string token)
{
Token = token;
}
public void Add(Contact c)
{
var client = new HttpClient();
client.SetBearerToken(Token);
var stringContent = new StringContent(JsonConvert.SerializeObject(c), Encoding.UTF8, "application/json");
client.PostAsync("api/add", stringContent);
}

public void Update(Contact c)
{
var client = new HttpClient();
client.SetBearerToken(Token);
var stringContent = new StringContent(JsonConvert.SerializeObject(c), Encoding.UTF8, "application/json");
client.PostAsync("api/update", stringContent);
}
}


Earlier I was using token as a parameter for each method (Add(Contact c,string token)) which was not acceptable.

Now I am okay with above approach, but it seems like without SetToken I cant do anything in proxy implementation.

Since I am using DI to instantiate classes for can't go for Adapter pattern like ContactBusinessProxyImpl(string token).

Is there any better approach or pattern can be used here?

• hi there - if I undestand your problem correctly, then you NEED a token in order to make ContactBusinessImpl actually work - and you don't want to pass in the token as a parameter in the void Add() and void Update() methods - am i understanding you correctly here? – BKSpurgeon Nov 2 '17 at 13:11
• @BKSpurgeon yes you are right. – Anupam Singh Nov 2 '17 at 13:32
• few more questions: (i) you are injecting the token into the concrete classes - via a property or method etc? (ii) do you have the token available upon instantiation of the concrete classes? – BKSpurgeon Nov 2 '17 at 22:50
• (i) yes i am injecting token at run time so i neee to use property, or a variable with setter method. (ii) no – Anupam Singh Nov 3 '17 at 1:53
• Finally - can you provide more detail on the class and method which actually obtains the token? – BKSpurgeon Nov 3 '17 at 9:41

## 1 Answer

Since I am using DI to instantiate classes

I have to disappoint you... there is no DI in your code. The only service you are using is instantiated inside the class using it:

private ContactService _contactService = new ContactService();


DI would be if you passed it to ContactBusinessImpl via constructor.

public string Token { get; set; }

public void SetToken(string token)
{
Token = token;
}


We don't usually do that. A value is either a mandatory one, then we use a constructor so the user must provide it or it's optional so we create a get/set property for it and don't enforce it via constructor. Having a method that sets a property that has a setter is pointless.

public void Add(Contact c)
{
var client = new HttpClient();
client.SetBearerToken(Token);
var stringContent = new StringContent(JsonConvert.SerializeObject(c), Encoding.UTF8,"application/json");
client.PostAsync("api/add", stringContent);
}


Creating HttpClient on each call is a bad idea. At some point you'll run out of sockets.

• You are correct about the Dependency injection and Http Client instantiation. Thanks for pointing out. Also Agree with "A value is either a mandatory one, then we use a constructor". But my concern is how to use 'ContactBusinessProxyImpl ' and 'ContactBusinessImpl ' for 'IContactService' effectively. – Anupam Singh Nov 1 '17 at 13:21