Third Party Library

I Refuse To Re-Invent The Wheel

I just can't escape the fact that I'm not a one-man army, and I don't have to be. My arsenals can be acquired from already existing set of frameworks and modules. Should an application create everything from scratch? For maintainability purposes, perhaps it should, since all codes are available and documented in-house, and the output of the software project can be more controllable since developers would know what went wrong and directly change the codes. But imagine how a software should create everything from scratch: a 3D rendering engine, a Physics engine, a UI Graphics engine. Consider this paradigm if you were a one-man army, if not, a small development team. This decision will greatly slow down the production process right from the design to deployment. It's like building a bridge and each piece of concrete is created from scratch, each steel rods are created from scratch, everything is in-house and controlled. Compare this scenario to this following scenario: contract out a reliable concrete factory with high integrity value and use them according to its specifications, contract out a ready-made steel rods with approved quality and use them according to its specification, the same concept goes for other materials and constructions. The latter scenario promotes a more accelerated production than the first.
The key statement to this argument is :

Using third party libraries with controlled and contained number of dependencies wields the power of indirect delegation of work and accelerates progress.

There Has To Be A Catch

Consider the first version of an application. This application has dependency to several third party libraries : log4net, Dundas Chart, Irliccht Engine, and DevExpress. Suppose that the next version a decision has been made where, and this usually happens after much r&d, Dundas Chart should be replaced by WinFX, and DevExpress with SyncFusion libraries. How much of a codebase change do we expect here? Should we blame the early architect for making such stupid early choices? To that note, what if the earlier libraries used in the earlier architectural decision is found to be much better in its later release?

What To Do, What To Do?

I've been spending quite some time to try to decide how on earth I can escape from third-party coupling issues. So far, only a handful of design patterns that may or may not help in decoupling these third party libraries, namely: Proxy, Facade, Builder, and perhaps Adapter patterns, where classes in third party libraries are accessed through the 'middlemen', classes that interface with the third party libraries and the application. Thus, in theory, third party assemblies are referenced by these in-house middle assemblies, and, without the need for an application specific assembly to have reference to the third party libraries. Therefore, in theory, when third party libraries are changed from one to another, no application-specific codes that indirectly interact with the third library codes need to be changed. Another middle class assemblies that comply with the earlier middle class assemblies interfaces are developed, thus transparently creates a transition from one third party library to another.
There's a problem. This scenario only works perfectly in theory. Maintainability score : 6/10. It's great that we can now program against interfaces, but middle class assemblies create another layer that developers need to maintain. Also, the development time to write these middle class assemblies can be brutal. We may later find out that we need additional features out of the third party libraries, but the middle class assemblies have not supported such features. Hence, more development time will be sacrificed.


One resolution to this argument is an answer that I hate the most:

It depends.

Third party libraries like .NET controls can be proxied and composited through the Framework's Control composite. Sub-frameworks like Composite Application Guidance Framework a.k.a Prism for Silverlight and WPF, well, good luck proxying them out, because as far as I know, it's more reliable and easier to use them directly. Log4Net, from what I learned so far, uses Application configuration dependency. A minimal decoupling can be implemented through dependency injection so logging can be done by one application assembly, thereby logger configuration is done in the main application assembly and much of the logging responsibilities are shifted to a single class. If this method is not a viable option, then, damn it, use log4net directly.

Use third party libraries wisely. Some may not need to be directly referenced, while others are not so easy to be modularised. Create a system that is, before adding the third party library dependencies, already geared towards optimal decoupling and modularisation paradigm. Therefore, transitional period between the earlier and the later third party libraries can be shorter.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License