Looking for Best Practices. What are some dos and Don'ts for extending a third party product to allow for merging new versions as easily as possible_问答_开发者

So I have been charged with taking an active third party product that we own source code for, and making proprietary changes that will break compatibility with future updates of the product. This product is laid out pretty well, but is an enterprise app, from database all the way up to UI, So I can't just do something simple like add a proprietary business layer to hide and extend the third party one and write my own UI. As the UI is a large part开发者_StackOverflow of what we bought to begin with.

So what I am looking for, are some guidelines, best practices, dos and donts, etc. To keep in mind as I take on this task.

The only really solid things I plan to do for sure are.

Keep any extensions to the product in my own files, or as segregated as possible. (I would like to hear any strategies, or horror stories you may have about this however)
Annotate any changes to existing methods, so that they are searchable, and have a good notation of the how and why the change was made, so that when I merge in an update, I can easily go through the list of my alterations, and make any modifications that are required.

Other than that I'm just planning to keep the Decorator, Facade, Proxy, and Adapter patterns close at hand, and try to do keep this as painless as possible going forward.

Any input is appreciated, Thanks.

In your application core, define an interface for any services provided by the third-party product.
In your infrastructure layer, implement each interface as an Adapter/Wrapper to the third-party product.
Code against the interface everywhere else in your application. Use Inversion of Control to register implementations of your service interfaces and automatically resolve the configured implementation by interface type and context. My favorite IoC library is StructureMap.

The result,

The only changes you must make to accommodate changes to future versions of the third-party product will be isolated to your infrastructure layer. Every reference to the service from elsewhere in your application will only have a dependency on the application core. Even if you completely abandon that third-party product in favor of an alternative implementation, the only part you will have to change is your registration of the service implementation with your IoC container. (Many tools automate this task by resolving implementations by naming and inheritance conventions)

No solution, but a tip: I'd keep a mirror of their source code in your own version control so you have tooling to merge their new revisions.

Not a solution but a tip:

You're second "solid thing" will be a great asset when you need to perform upgrades.

One suggestion I have is to look at the product's planned feature additions and timelines for the releases. I wrote an addition to an open source e-commerce application only to have the feature released officially a month or so later. If I had looked at the planned feature additions I could have avoided doing the extra work, but it was a good experience (both writing the addition and realizing it was released officially).

Option one indirectly points to creating your own business layer to keep third party components completely separate. But you have pointed in your answer that you do not want to do it. Without inheritance and creating one more layer, it will be more of source code management which depends upon how complicated it can become in future.

Mostly UI looks big, but if you break it down to common parts and use some sort of XML configuration and prism kind of composition then creating business layer is easier.

In this case you will be able to extend and replace your UI elements easily as need rises.

Second option is very painful as if you have difficulty in understanding third party source then you will be left with dirty code management as you will not have option to easily remove or create alternatives as it will be very tightly coupled source code.