0

I have an instance of a class UntouchableClass of which I need to access the member variables to use in my DotLiquid template. Problem is, UntouchableClass has to inherit from Drop if I want to use it in my template, but I can't change it since it is from an existing library.

I've read about the Adapter pattern, but UntouchableClass does not have an interface from which to inherit the Adapter.

Also, I can't use multiple inheritance (I would create a class which inherits from both UntouchableClass and Drop but this is C# and from what I know this isn't possible).

Is there a design pattern that would suit this situation? Or is there a particular way to do this using DotLiquid?

|improve this question
  • why cant you override the method though its from an existing library – Computernerd Mar 7 '14 at 18:06
  • @Computernerd What method exactly are you talking about? I just need access to the member variables. – Deinonychus Mar 7 '14 at 18:13
  • you said " i cant change it since its from an existing library" – Computernerd Mar 7 '14 at 18:14
  • @Computernerd I meant I cannot modify the UntouchableClass to write UntouchableClass : Drop – Deinonychus Mar 7 '14 at 18:16
  • I think computernerd is suggesting your adapter class should inherit from UntouchableClass. Depending on how UntouchableClass is set up this may or may not be possible. If it's at all ugly (which is likely), I'd suggest using the object adapter pattern as I describe in my answer instead. – Ben Aaronson Mar 7 '14 at 22:10
6

Yes, the adapter pattern is appropriate here. Looking at the wikipedia article for the Adapter pattern, there are two versions, the 'Object Adapter Pattern' and the 'Class Adapter Pattern'. In the Object Adapter Pattern, the adapter contains an instance of the adapted class, whereas in the Class Adapter Pattern, the adapter inhereits from the adaptee.

The limitation you describe would most likely prevent you from using the Class Adapter Pattern. However, you should still be able to use the Object Adapter Pattern. You simply need to have an instance of the class you want to adapt (the appropriate way to instantiate and persist it would most likely depend on the situation). Every method you want to override or implement from Drop could then be a method call on the wrapped adaptee object.

|improve this answer
0

+1 @Ben Aaronson, BTW. Good answer.

I view inheritance as as a form of implied composition, where the compiler is doing the busywork of composition for you. There are differences, and much different consequences, but as a result I don't worry so much when I switch to one or the other.

One of the main differences, though, is that when you use composition to build a class on top of another, you aren't limited by what your base class is. In this case that's good -- it's exactly what you need.

In this case, the central problem is polymorphism. You need to implement a subclass of Drop. To the outside world, your class must look like a Drop. If your implementation is really just a wrapper -- i.e. adaptor -- that delegates down to an instance of UntouchableClass, that's fine.

IMHO the real value of design patterns is understanding at a really detailed level why they work.

|improve this answer
0

I won't accept my answer since it isn't directly linked to my question, but here is what worked:

DotLiquid has different rules for template rendering parameters. I thought Drop inheritance was essential, but it turns out it's only one possible condition.

There is a method called Template.RegisterSafeType(Type type, string[] allowedMembers) made specifically for this case.

For some examples, see here: TemplateTests

|improve this answer

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.