7

I have an external dependency that provides a client library that is subject to change frequently. I'm writing a wrapper class on top of the client library so that all changes with respect to that library are contained there.

This library provides some enums that are needed to send requests to the client. I dont want to introduce dependency on these enums in my other code. Is there a way to do this without writing wrapper enums as well?

  • I have an external dependency that provides a client library that is subject to change frequently. Are you familiar with the concept anti-corruption layer? Looks like that wrapping is not hidding enough the implementation details of the dependency. Have you considered the facade design pattern? – Laiv Jan 30 '18 at 22:16
  • Isn't implementing a wrapper facade design pattern? Also facade and anti-corruption layer sound very similar to me. Read about these: Facade pattern and Anti corruption layer – ayushgp Jan 31 '18 at 6:08
  • Yes. Facade pattern is considered anti-corruption layer. If you already have this facade. Why I dont want to introduce dependency on these enums in my other code.?. nothing from the dependency goes beyond the facade. We transform our model, into the model of the library. The transformation is implementation details. Just a note. Wrapping a whole library in a single class makes you miss a lot of "abstractions". Probably you are missing some components in your model that might help you to hide these enums. Anyways, without more context and details is hard to say. – Laiv Jan 31 '18 at 7:18
  • I meant the dependency on enums from the external library in my other code. In the facade, I obviously have to include these enums. The library has a single responsibility and the class is just there for exposing one method from the library. My model is also very simple but many of its attributes are enum based which are what I wanna wrap. Anyways, I've gone ahead with the answer I've left here and put these enums inside the wrapper class. – ayushgp Jan 31 '18 at 7:39
3

As you said, you do not wish to introduce a dependency on those enums in your code (a sensible choice, especially for frequently changing 3rd party includes/libraries).

Still you need to have some kind of mapping in your "Wrapper" class to those enums to send your requests. Depending on what those enums repesent (and how many there are) you may have different options:

If there are many different enum values

// ClientLib
enum FooDevices { DEVICE_F1, DEVICE_F2, ... DEVICE_F83 };
enum BarDevices { DEVICE_B1, DEVICE_B2, ... DEVICE_F61 };

// Wrapper
enum WrappedFooDevices { WRAPPED_DEVICE_F1 ... };
enum WrappedBarDevices { WRAPPED_DEVICE_B1 ... };

void sendRequest(WrappedFooDevices fooDevice, WrappedBarDevices barDevice);

Then using some kind of enum wrapper may be the only sensible choice (Though you still have some leerway how you wrap those values - leave out those that you never use, etc.)

If the are only a few enum values you may be able to create a separate function for each instead.

// ClientLib
enum RequestType { FAST_REQUEST, SLOW_REQUEST, DATA_REQUEST };

// Wrapper
void sendFastRequest();
void sendSlowRequest();
void sendDataRequest();

In summary: As you have guessed you will to some some kind of mapping, but you might be able to do that mapping via distinct function calls (especially if the original enums have the "flag value" code smell).

1

Found a way I can define and contain these changes in one wrapper class. I created enums in the wrapper class and defined a private field with the enum it is wrapping, a constructor and a getter to get the wrapped property. Something like this:

public enum FooWrapper {
    PROP1(Foo.PROP1),
    PROP2(Foo.PROP2);

    private Foo val;
    private FooWrapper(Foo val) {
        this.val = val;
    }

    public getFoo() {
        return this.foo;
    }
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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