Monday, December 26, 2011

Design APIs for developers


Code reuse allows developers to build on top of others hard work, rather than starting from scratch for every program, There are two types of code reuse, 1) Copy and paste source code 2) use of others library. In general, software library has two parts: the public interface and the private implementation. The former contains software elements (e.g. classes and methods) that other developers are allowed and expected to use; this part is called the application programming interface or API. The latter implements the library’s functionality, but is usually not exposed to the library’s users. Whether creating desktop applications or server side application, the use of application programming interfaces (APIs) in modern software development is ubiquitous. These APIs are often large, complex, and broad in scope, containing many hundreds or thousands of classes and interfaces. A typical developer may use only a small portion of the total functionality of an API. API is a programmer interface. API consists of set of classes, their methods/fields. Programmers producing a library in c#/Java will package it into a DLL/JAR file containing classes. These classes and their members then become the library’s API. A common approach is only the pubic methods and fields (signature) are available for other programmers to use. We all know how the hardware is assembled by attaching parts together by well-defined interfaces. Similarly software components glued by its APIs. Developing whole application using in-house components is no longer the good way to so the business. Time to market, low cost development, reinventing the wheel etc. forced the business to choose existing shared libraries or frameworks. Component APIs allow us to selectively choose what is important and ignore the internals details, the client programmer just needs to concentrate on the Interface. A well-defined component in the modular system should carry information about all the other components it requires (Dependencies). If the system is built once and never re-used any of its components means there is no worry of API. People don’t have time to study the whole APIs and its documentation, they just want to finish the job, hence the contract must tell the purpose in clear terms using a) well defined naming conventions b) Provided with some examples so that client programmer just copy paste the code and modify it depends on their requirements. Naming and versioning APIs is very important for one reason, components are dynamic by nature, they evolve by bug fixes, feature enhancements etc. The backward compatibility of the API is an another factor that component developer should take care, since it may break all application that uses this component, the best practice is to support the deprecated API for sometime. Is it not advisable to remove method/fields from classes/interface, similarly classes/interface form the component. When applications grow in size and functionality, it becomes increasingly necessary to separate them into individual pieces, components/modules/plug-ins. Each of these separated parts then becomes one element of the modular architecture. Each part should be independent and provide well-defined exported interfaces so that the other parts can use them. Design for usability, client programmer should be easily able to perform important tasks, should be able to add new functionality or changing existing functionality. Finally the design should allow for testing typically by means of automated code.

No comments: