4

Typically, when trying to decouple classes I use Inversion of Control. Lately I've been using a third-party library whose components are sealed. Are there any design patterns to handle this situation? They have multiple component classes that're sealed and I quite often need to use them. I was about to inherit from it and give it an interface to operate through until I noticed it was sealed and impossible to do so.

The library doesn't change a whole lot (only in major versions) so I could pretty easily get away with keeping the classes coupled in this particular scenario, however this has got me wondering about cases where this would not be the case.

How do you keep coupling low in your code when using third-party sealed classes?

  • You mean decoupling the "sealed" classes among them or decoupling your code form the "sealed" classes? – Tulains Córdova Apr 14 '15 at 12:30
  • 9
    When inheritance is not an option, we use encapsulation and delegation. This means that instead of deriving your class from ThirdPartyComponent you have your class contain a ThirdPartyComponent. Have you tried that? – Mike Nakis Apr 14 '15 at 12:32
  • @user61852 decoupling from the sealed classes. – Shelby115 Apr 14 '15 at 12:35
  • 4
    @MikeNakis Hmmm...So you're saying to create a class that contains the object then expose the functions I'd want on an interface I'd typically use for IoC? I'm trying to think of a reason that wouldn't work and I'm coming up short. I guess I didn't think of that because I wrongly associated having the class with coupling with the class. – Shelby115 Apr 14 '15 at 12:39
  • Yes, that's how it is usually done. I wrote it as a comment instead of an answer precisely because it is so fundamental. – Mike Nakis Apr 14 '15 at 12:43
2

As some of the comments mentioned, you may be either consuming the library incorrectly or it may not be a well designed library. But ignoring this, a variation façade pattern seems appropriate.

I don't have enough information about your application, but I can think of two approaches off of the top of my head:

Simple

class MyObject
{
     private _libraryObject;
     public MyObject(LibraryObject source)
     {
           _libraryObject = source;
     }

     public MyProperty1
     {
         get { return _libraryObject.Property1; }
         set { _libraryObject.Property1 = value; }
     }
 }

Complex, but even more decoupled

//Inside repository class
GetObject()
{
     MyObject myObject = new MyObject();
     Mapper.Map(libraryObject, myObject); //Translate a LibraryObject to MyObject
     return myObject;
}

You can now do what ever you want with this class, including inherit from it.

| 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.