Reusability of Code

Reusability of Code

One of the first challenges to making reusable components is managing the dependency chain. If a component performs a simple task but requires too many external sources, it can become difficult to transplant into a different project, as the transplanted codes dependencies will be added into the destination projects dependency list.

Another challenge that needs to be addressed with reusability of a component; is whether or not the piece comes with documentation at least the ability to be debugged. An example of this could be a web service that does not properly expose a Web Service Descriptor Language. Yes, it can be reused into another project; however without the ability to diagnose issues nor easily identify the supported behavior for interacting with the service, will lead to an unreliable system.

Assuming that these problems have been solved, a reusable component needs to maintain a consistent public interface for callers. If the public interface is consistently changing it will cause build or runtime errors in programs that depend on this reusable component.

There are two ways solve this challenge, the first being to use static linking. When a program statically links against a reusable component it is consumed as part of the program at build time. From this point forward the interface will never break as it was ensured during project build time. This comes with a trade-off of the application being larger on disk. The component also becomes harder to service such as during vulnerability patching as every program that statically linked against it must be individually patched.

An alternative to static linking is to use dynamic linking. In dynamic linking each of the components of the program end up in multiple executable modules called Dynamic Link Libraries or Shared Objects. These additional modules are then loaded at runtime, which makes them easier to share with other programs. Another advantage of dynamic linking is...