Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "Why use API". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is API?

API (Application Programming Interface) provides an abstraction of a problem and a way for customers to interact with software components that solve the problem. Components themselves are usually distributed in the form of software class libraries, and they can be used in multiple applications. In a nutshell, API defines a number of reusable modules so that each modular block can be embedded in the end-user's application.

You can write API for yourself, other engineers in your organization, or a large development community. It can be as small as a single function or as large as hundreds of classes, methods, global functions, data types, enumerated types, constants, and so on. Its implementation can be private or open source. An important basic definition of API is that API is a well-defined interface that can provide specific services for other software.

Modern applications are usually based on many API, which in turn rely on other API. As shown in the example application in figure 1-1, the application uses the API of three class libraries (1, 2, 3), and two of the three API use the other two class libraries (4 and 5). For example, an application that browses a picture may use the API that loads the GIF image, while the API itself may rely on the underlying API that compresses or decompresses the data.

Pictorial translation:

Application Code: application code

Library: class library

Figure 1-1 the application that invokes the routine from the hierarchical API. Each box represents a software class library, the gray part represents its public interface, for the class library is its API, and the white part represents the concrete implementation hidden behind the API.

API development can be seen everywhere in modern software development, and its purpose is to provide a logical interface for the function of a component while hiding the implementation details within the module. For example, the API we use to read GIF images might simply provide a LoadImage () method, which takes a file name as an argument and returns a two-dimensional array of pixels. All the details of file format and data compression are hidden under this seemingly simple interface. This concept is also illustrated in figure 1-1, that is, client code can only be accessed through the public interface of the API. The API public interface is shown in the gray area at the top of each box in figure 1-1.

Why C++ was chosen to describe API design

Although there are many general API design methodologies (which can be applied to any programming language or programming environment), they ultimately need to be expressed in a specific programming language. Therefore, it is necessary to understand the characteristics of a particular language in order to promote standardized API design. Therefore, this book is dedicated to using one language (C++) to describe the problems of API design, rather than scattered content to make it applicable to all languages. However, readers who want to develop API in other languages, such as Java or C #, can still get a lot of general insights from this book. The direct target of this book is the C++ engineers who write and maintain API, and their API is for other engineers to use.

At present, C++ is still one of the most widely used programming languages in large software projects, and it is increasingly becoming a * * language that focuses on code performance projects, so there are many kinds of C and C++ API that you can choose in your applications (I listed some above). This book focuses on how to use C++ to write excellent API, and introduces rich source code examples to better illustrate these concepts. In other words, this book will cover some C++-specific topics, such as templates, encapsulation, inheritance, namespaces, operators, const correctness, memory management, STL usage, Pimpl idioms, and so on.

In addition, C++ is undergoing great changes during the publication of this book. The new C++ specification is in the process of standardization in ISO/IEC. Currently, most C++ compilers follow the standard issued in 1998, called Clear98. Subsequent standards were published in 2003, correcting several defects in the previous edition. Since then, the Standards Committee has been working on a major new version of the specification. Until the standard is formally approved and a release date is set, this version has been informally referred to as Central0x. By the time you read this book, the new standard may have been released. However, at the time of writing this book, it was still called Central0x.

Nonetheless, we have reached the advanced stage of the standardization process, and we can confidently predict some new features. In fact, some mainstream C++ compilers have begun to implement many of the proposed new features. In terms of API design, some new features can be used to build more elegant and robust interfaces. Therefore, I have been trying to emphasize and explain the API design in Central0x throughout the book. Therefore, this book should still have reference value in the next few years.

Why use API

Why should we pay attention to API in software projects can be understood from two aspects: (1) Why should we design and write API? (2) Why use the API provided by others in the application? I'll answer these two questions in the next section and point out the benefits of using API in a project.

If you are writing modules for use by other developers, whether they are other engineers in the company or external customers, it would be wise to build API to give them access to these features. Doing so will bring the following benefits.

More robust code

Hide the implementation. By hiding the details of the internal implementation of the module, developers are free to modify the implementation of the module at some point in the future without having a significant impact on users. If not, it will lead to the following results: (1) the update of the code will be restricted; (2) users will have to rewrite the code to use the new version of the library. If you keep users updating software versions all the time, they are likely to be reluctant to update them or simply abandon them and look for API that doesn't require much maintenance. Therefore, good API design is critical to the success of the business or project.

Prolong life. Over time, the internal code of systems that disclose implementation details becomes complex, and each part of the system depends on the internal implementation details of other parts. As a result, the system will become fragile, rigid, non-portable and highly sticky (Martin,2000). In this way, the company has to spend a lot of manpower and money, or even rewrite it, in order to improve the code. If you take the time to do the API design in advance, and then maintain the design to ensure consistency, the software life can be extended and the cost can be saved in the long run. We will discuss this issue in depth in the previous part of Chapter 4.

Promote modularity. API is usually used to accomplish a specific task or use case. Therefore, API defines a set of modular features with a consistent purpose. The structure of applications developed on the basis of a large number of API will be less coupled and more modular, and the behavior of each module does not depend on the internal details of other modules.

Reduce code duplication. Code repetition is one of the worst behaviors in software engineering, and you should avoid making such mistakes at all times. By putting all the code logic behind a strict interface and allowing all customers to use this interface, some behavior of the program can be handled uniformly. This means that the behavior of the API provided to all customers can be changed by updating only one place of code. This helps eliminate all duplicate implementations in the code. In fact, a lot of API is implemented in this way, people first find duplicate code, and then make a unified interface to replace these duplicate code, thus resulting in API. This is a good thing.

Eliminate the burden of hard coding. Many programs may contain hard-coded values that are constantly copied throughout the code. For example, use the specific file name "myprogram.log" where you need to write a log file. We can use API to provide this information without having to copy these constants at the entire code level, for example, using a GetLogFilename () API call instead of a hard-coded "myprogram.log" string.

Easy to change and implement. If you hide all the implementation details behind the public interface, you can change its internal implementation details without affecting any reliance on this API code. For example, you can change the way you used std::string to parse files to allocate, release, and reallocate char* buffers.

Easy to optimize. After successfully hiding the implementation details, you don't have to worry about changing the client code when optimizing the performance of API. For example, you can use the caching scheme to optimize a compute-intensive method. This is done because all operations to read and write potential data are done through this API, so the API knows exactly when the result in the cache is invalid and needs to be recalculated.

Code reuse

Code reuse is to use existing software to build new software. This is a sacred goal pursued by modern software development. API provides a mechanism for code reuse.

In early software development, it was common that companies had to write all the code for any application they made. If a program needs to read GIF pictures or parse text files, the company has to write all the code itself. Today, with the increase in excellent commercial and open source libraries, it is very easy to reuse code that has been written by others. For example, there are a variety of open source API for reading images and XML API for people to download and use. These libraries have been continuously improved and debugged by many program developers around the world, and have also been tested in practice in many other programs.

Software development has become more modular in nature by using different components that are used to build the various modules of the application and communicating with each other through the API that the components have released. The advantage of this approach is that you don't need to know all the details of each software component, and as in the previous analogy of building a house, many details can be delegated to professional contractors. This reduces the development cycle, on the one hand, because existing code can be reused, on the other hand, because development plans for various components can be separated, and it also allows developers to focus on core business logic. without wasting time reinventing the wheel.

However, one obstacle to code reuse is that more generic interfaces are often required than originally planned, as other customers may have additional expectations and requirements. Therefore, effective code reuse comes from in-depth understanding of software customers and system design that combines the interests of customers and themselves.

C++ API and WEB

Applications that rely on third-party APIs are becoming more and more common in the field of cloud computing. In this field, Web applications increasingly rely on Web services (API) to provide their core functions. For Web mashup applications (mashup), the application itself is sometimes simply re-encapsulating a variety of existing services to provide new services. For example, combining Google Map API with the local crime statistics database can provide a map-based interface for crime data.

In fact, it's worth taking some time to emphasize the importance of C++ API design in Web development. Superficial analysis may conclude that server-side Web development is limited to scripting languages such as PHP, Perl, Python (the popular LAMP architecture acronym "P"), or .net languages based on Microsoft ASP (dynamic server pages) technology. This may be true for small-scale Web development, but it is worth noting that many large-scale Web servers use backend services implemented by C++ for performance.

In fact, Facebook has developed a product called HipHop, which converts PHP code into Cellular codes to improve the performance of social networking sites. Therefore, C++ API design does have a place in the development of scalable Web services. In addition, using C++ to develop core API can not only build high-performance Web services, but also the code can be reused in other forms of delivery, such as desktop or mobile phone versions.

Beside the point, one possible explanation for this shift in software development strategy is the result of globalization (Friedman,2008;Wolf, 2004). In fact, the convergence of the Internet, standard network protocols and Web technology has created a software competitive platform. This enables companies and individuals from all over the world to create, contribute and compete in large and complex software projects. This form of globalization has led to an environment in which companies and developers around the world can make a living by developing software subsystems. Other organizations around the world can then combine and extend these building blocks to create end-user applications that solve specific problems. In terms of the focus of this book, API provides a mechanism to promote the globalization and componentization of modern software development.

Parallel development

Even if you're just writing internal software, the engineers you work with are likely to use your code editor. If you use good API design skills, you can simplify each other's work without having to answer many questions about how the code works and how to use it. This is particularly important when multiple developers develop interdependent code in parallel.

For example, suppose you are writing a string encryption algorithm that other developers need to write to the configuration file. One way to do this is to have other developers wait for you to finish all the work, and then use your algorithm in their text output module. However, it is more efficient for you to meet in advance to negotiate the appropriate API, and then you put the API in place, while the API simply acts as a placeholder so that your colleagues can call them immediately, for example:

# include classStringEncryptor {public: / / sets the key voidSetKey (conststd::string & key) to be used when calling Encrypt () and Decrypt (); / / encrypts the input string std::string Encrypt (conststd::string & str) const based on the current key / based on the current key decryption input string / Decrypt () A string returned by Encrypt () returns the original string std::string Decrypt (conststd::string & str) const;} under the same key.

Next, you can provide a simple implementation of these functions so that the module can at least be compiled and linked. For example, the related .cpp file can look like this:

VoidStringEncryptor::SetKey (conststd::string & key) {} std::string StringEncryptor::Encrypt (conststd::string & str) {return str;} std::string StringEncryptor::Decrypt (conststd::string & str) {return str;}

In this way, your colleagues can use this API to continue their work without being held up by your progress. Although currently your API doesn't actually encrypt any strings, this is only a small implementation detail. What is important is that there is already a mutually agreed stable interface, a contract, and that the interface behaves appropriately, for example, Decrypt (Encrypt ("Hello")) will return "Hello". When you have finished your work and updated the .cpp file with the correct implementation, that part of your colleague's code can run without any modification.

In fact, some interface problems are probably not anticipated before you write the code, so the API design may require multiple iterations to ensure that it is just right. In most cases, API supports both sides to work in parallel with minimal pause.

This approach also uses test-driven or test-first development. Once the API is determined in advance, unit tests can be written to verify the expected functionality, and these tests can be run continuously to ensure that the agreement between you and your colleagues is not broken.

By extending the process to the organizational level, your project can have independent teams that may be far apart from each other or even follow different schedules. By pre-determining the dependencies of individual teams and modeling these relationships by creating API, each team can work independently, with little concern about how other teams implement the work behind API. The effective use of resources and the reduction of corresponding redundant communications can save a lot of overall costs for the organization.

When to avoid using API

Designing and implementing API usually takes more effort than writing ordinary application code, because the purpose of API is to provide a robust and stable interface for other developers to use. As a result, API has higher requirements in terms of quality, design, documentation, testing, support, and maintenance than software used only within a single application.

Therefore, if you are writing an internal module that does not need to communicate with other clients, the extra overhead of creating and maintaining a stable public interface for the module is not worth it, but this is not a reason to write poor code. Spending more time adhering to API design principles is not a waste of time and effort in the long run.

On the other hand, suppose you are a software developer who wants to use a third-party API in your application. The previous section discussed some reasons for reusing external API in your software, but sometimes you may need to avoid using a specific API, and in these cases, you should devote yourself to implementing the code or finding an alternative solution.

License restrictions. Although API can provide all the exquisite features you need, license restrictions may deter you. For example, if you want to use an open source package released by GNU GPL (General Public License, General Public license), then you must use GPL to publish all derivative works. If you use this package in your program, you must publish the source code for the entire application, which is a constraint that commercial applications may not accept. Other licenses (such as GNU Lesser General License GPL,LGPL) are more relaxed and more common in software libraries. Another sign of licensing problems is that commercial API fees may be too expensive for your project, or license terms may be too strict, such as charging each developer or even each user a license fee.

Function mismatch. Although API seems to solve the problem, it is possible to perform in a way that does not match the application constraints or functional requirements. For example, you may be developing an image processing tool that wants to provide Fourier transform functionality. Although there are many off-the-shelf implementations of FFT (Fast Fourier Transform, Fast Fourier transform), most of them are 1D algorithms, and 2D FFT is needed to process 2D image data. In addition, many 2D FFT algorithms can only work on datasets whose size is the power of an integer of 2 (such as 256x256or 512x512). Maybe the API you found doesn't run on a platform that must be supported, or it doesn't meet the performance standards you set for your program.

Lack of source code. Although there are many open source API, sometimes the API that meets the requirements may be closed-source products. In other words, only the header file of the interface is provided, and the C++ source file behind it is not published with different libraries. One of the important effects of this is that when there is an error in the library, the problem cannot be located by examining the source code. Reading the source code is an important way to track errors and find a solution.

Furthermore, without access to API's source code, you lose the ability to fix errors by modifying the source code. This means that the progress of a software project may be adversely affected by unexpected problems in the third-party API used, and you need to wait for the owner of the API to process your error report and issue a fix.

Lack of documentation. Although API seems to fully meet the needs of the application, if the documentation of API is poorly written or there is no documentation at all, then you will look for another solution. In this case, it may be that the unclear usage of API affects its use, or that you can't determine the behavior of API in a particular situation, or even that you can't trust developers who can't even take the time to explain the code.

This is the end of the content of "Why use API". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.