0

It's a easy question.

I have there some database-framework, which gives me a few methods working with them.

So now i want to extend that behavior. I write a wrapper-class and add a few more methods with that functionality i wanted to extend it.

Now the client get the wrapper-Object, but there I want to have access on my extended functionality and on the functionality the framework directly expose. So I have there an getter getting the the framework-object/objects.

Is that allowed? Or should i inject into the client the wrapper-object and the framework-objects separately? (so that the client must not fetch it out the wrapper-object) Are there any other solutions?

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
Robin Kreuzer
  • 162
  • 1
  • 10

1 Answers1

0

That very much depends on the use case. That is, it depends on WHY you're giving some consumer an object in the first place.

If the goal is to provide some extra functionality to a consumer that already uses that framework, then the consumer should already be assuming its using that framework, and you shouldn't try to hide it: provide an object that accepts the framework's original object.
Some languages have facilities to make this more convenient for the consumer, e.g. C#'s extension methods.

On the other hand, if your goal is to provide a database API to your consumer, then you need to be explicit about the assumptions that your consumer can make.
You might end up swapping out the framework's implementation with another implementation.
You might only support a subset of the framework's actual functionality or API. That is, your extensions may not work if the consumer uses method XYZ in combination with config ABC. So you want to only let the consumer use what you support.
In that case, you need to define the methods yourself, even if they are just pass-through to the framework's object. That's where Law of Demeter applies.

root
  • 5,528
  • 1
  • 7
  • 15