Skip to main content
added 243 characters in body
Source Link
John Wu
  • 27k
  • 10
  • 69
  • 93

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    etcInternalCustomer _customer;

    internal Customer(InternalCustomer c)
    {
        _customer = c;
    }

    InternalCustomer ICustomerEx.GetOriginalCustomerObject()
    {
        return _customer;
    }
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    var c = customer as ICustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    etc.
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    var c = customer as ICustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    InternalCustomer _customer;

    internal Customer(InternalCustomer c)
    {
        _customer = c;
    }

    InternalCustomer ICustomerEx.GetOriginalCustomerObject()
    {
        return _customer;
    }
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    var c = customer as ICustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}
deleted 7 characters in body
Source Link
John Wu
  • 27k
  • 10
  • 69
  • 93

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    etc.
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    ICustomerExvar c = customer as CustomerEx;ICustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    etc.
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    ICustomerEx c = customer as CustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    etc.
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    var c = customer as ICustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}
Source Link
John Wu
  • 27k
  • 10
  • 69
  • 93

Three thoughts for you, OP.

Use an anemic class

If B is just a DTO, there is no reason to be able to mock it, and an interface is not needed (a unit test can just use new and put in mock data). For example, if B is a custom structure designed to hold a date/time stamp, and it contains only fields and properties without behavior, go ahead and expose it as class B instead of as interface IB. It's OK for the client to use new instead of getting every single instance from your library, and unit tests can do the same, as long as the class is a dumb data container.

Use an ID to reconstruct the original object

Don't worry about keeping like-for-like with every single pattern in use by the objects you are wrapping. The point of a wrapper is to expose only what is needed by your client, and in a manner that is easy to use and difficult or impossible to mis-use. It's OK if things change.

For example, it might make more sense to expose a method that accepts an object identifier than an object itself. So instead of

void Method1(ICustomer customer);

you could expose

void Method1(int customerID);

Now internally, method1 will have to use that customerID to construct an (internal) Customer object, compatible with the library you are attempting to wrap. I would suggest it can just construct it on the fly.

void Method1(int customerID)
{
    var c = internalLibrary.GetCustomer(customerID);
    c.InternalLibraryCall();
}

Use internal interfaces

You have a powerful tool at your disposal: internal interfaces. Not internal interface members (as you have discovered, these are not allowed) but the interface itself.

public interface ICustomer
{
    int CustomerID { get; }
}

internal interface ICustomerEx
{
    InternalCustomer GetOriginalCustomerObject();
}

public class Customer: ICustomer, ICustomerEx  //Client won't see ICustomerEx
{
    etc.
}

Then the method could look like this:

public void HandleCustomer(ICustomer customer)
{
    ICustomerEx c = customer as CustomerEx;
    var internalC = c.GetOriginalCustomerObject();
    c.InternalLibraryCall();
}