没有合适的资源?快使用搜索试试~ 我知道了~
首页C++进阶API设计指南:新手必备
C++进阶API设计指南:新手必备
需积分: 0 2 下载量 138 浏览量
更新于2024-07-28
收藏 2.62MB PDF 举报
《C++ API设计指南》是一本由Martin Reddy编著的专业书籍,针对C++编程语言的API(应用程序接口)设计提供了深入的阐述。作为C++新手的进阶读物,该书旨在帮助读者理解和掌握如何有效地创建、组织和管理在C++项目中使用的API,以便于代码重用、模块化和提高软件质量。
在本书中,作者详细探讨了以下关键知识点:
1. **C++ API基础**:首先介绍了C++语言特性,如类、模板、继承和多态等,这些都是API设计的基础,因为API通常是由类和函数组成的,这些概念决定了API的灵活性和可扩展性。
2. **接口与抽象**:作者强调了设计良好API的重要性,包括如何通过接口(Interface)提供抽象,使得API用户只需关注接口而不必关心底层实现细节。这有助于降低耦合度,提高模块间的松耦合性。
3. **设计模式的应用**:书中会涉及一些常见的设计模式,如工厂模式、装饰器模式、策略模式等,这些模式在API设计中扮演着优化和解耦的角色。
4. **错误处理与异常处理**:在API设计中,正确处理错误和异常至关重要。作者会讲解如何在API中设计健壮的错误处理机制,以及如何通过异常来传递错误信息。
5. **性能与效率**:对于性能敏感的C++应用,API设计者需要了解如何优化API调用,避免不必要的开销,并确保资源的有效管理。
6. **文档与注释**:良好的API文档是使用的关键。书中会涵盖如何编写清晰、易于理解的API文档,包括函数签名、参数说明和示例用法。
7. **版本控制与兼容性**:随着项目的迭代,API可能会发生变化。作者会介绍如何管理API版本,以及如何在新旧版本之间实现平稳过渡,保持向后兼容。
8. **实战案例分析**:书中还包含多个实际的API设计案例,通过实例展示理论知识在实际项目中的应用,帮助读者加深理解并提高实践能力。
《C++ API设计指南》是一本实用且全面的教材,适合C++开发者尤其是希望提升API设计技能的中级到高级工程师阅读。通过学习本书,读者不仅能掌握C++ API设计的最佳实践,还能培养出良好的软件工程思维,为项目开发带来更大的效益。
As an example of a well-known API, Microsoft’s Windows API (often referred to as the Win32
API) is a collection of C functions, data types, and constants that enable programmers to write appli-
cations that run on the Windows platform. This include s functions for file handling, process and
thread management, creating graphical user interfaces, talking to networks, and so on.
The Win32 API is an example of plain C API rather than a C
++
API. While you can use a C API
directly from a C
++
program, a good example of a specific C
++
API is the Standard Template Library
(STL). The STL contains a set of container classes , iterators for navigating over the elements in
those containers, and various algorithms that act on those containers (Josuttis, 1999). For instance,
the collection of algorithms includes high-level operations such as
std::search(), std::reverse(),
std::sort(), and std::set intersection(). The STL therefore presents a logical interface to
the task of manipulating collections of elements, without exposing any of the internal details for
how each algorithm is implemented.
TIP
An API is a logical interface to a software component that hides the internal details required to implement it.
1.2 WHAT’S DIFFERENT ABOUT API DESIGN?
Interfaces are the most import ant code that a developer writes. That’s because problems in an inter-
face are far mor e costly to fix than problems in the associated implementation code. As a result, the
process of developing shared APIs demands more attention than standard application or Graphical
User Interface (GUI) development. Of course, both should involve best design practices; however,
in the case of API development, these are absolutely critical to its success. Specifically, some of
the key differentiating factors of API development include the following.
• An API is an interface designed for developers, in much the same way that a GUI is an inter-
face designed for end users. In fact, it’s been sai d that an API is a user interface for program-
mers (Arnold, 2005). As such, your API could be used by thousands of developers around the
world, and it will undoubtedly be used in ways that you never intended (Tulach, 2008). You
must anticipate this in your design. A well-designed API can be your organization’s biggest
asset. Conversely, a poor API can create a support nightmare and even turn your users toward
your competitors (Bloch, 2005), just as a buggy or difficult-to-use GUI may force an end user
to switch to a different application.
• Multiple applications can share the same API. Figure 1.1 showed that a single application can
be composed of multipl e APIs. However, any one of those APIs could also be reused in sev-
eral other applications. This means that while problems in the code for any given application
will only affect that one application, errors in an API can affect all of the applications that
depend on that functionality.
• You must strive for backward compatibility whenever you change an API. If you make an
incompatible change to your interface, your clients’ code may fail to compile, or worse their
code could compile but behave differently or crash intermittently. Imagine the confusion and
chaos that would arise if the signature of the
printf() function in the standard C library was
4 CHAPTER 1 Introduction
different for different compilers or platforms. The simple “Hello World” program may not
look so simple any more:
#include <stdio.h>
#ifdef WIN32
#include <windows.h>
#endif
#ifdef cplusplus
#include <iostream>
#endif
int main(int, char *argv[])
{
#if STRICT ANSI
printf("Hello World\n");
#elif defined( WIN32)
PrintWithFormat("Hello World\n");
#elif defined( PRINTF DEPRECATED )
fprintf(stdout, "Hello World\n");
#elif defined( PRINTF VECTOR )
const char *lines[2] {"Hello World", NULL};
printf(lines);
#elif defined( cplusplus)
std::cout << "Hello World" << std::endl;
#else
#error No terminal output API found
#endif
return 0;
}
This may seem like a contrived example, but it’s actually not that extreme. Take a look at the stan-
dard header files that come with your compiler and you will find declarations that are just as convo-
luted and inscrutable, or perhaps worse.
• Due to the backward compatibility requirement, it is critical to have a change control process
in place. During the normal development process, many developers may fix bugs or add new
features to an API. Some of these developers may be junior engineers who do not fully under-
stand all of the aspects of good API design. As a result, it is important to hold an API review
before releasing a new version of the API. This involves one or more senior engineers check-
ing that all changes to the interface are acceptable, have been made for a valid reason, and are
implemented in the best way to maintain backward compatibility. Many open source APIs
also enforce a change request process to gain approval for a change before it is added to
the source code.
• APIs tend to live for a long time. There can be a large upfront cost to produc e a good API
because of the extra overhead of planning, design , versioning, and review that is necessary.
However, if done well, the long-term cost can be substantially mitigated because you have
the ability to make radical changes and improvements to your software without disrupting
your clients. That is, your development velocity can be greater due to the increased flexibility
that the API affords you.
51.2 What’s different about API design?
• The need for good documentation is paramount when writing an API, particularly if you do
not provide the source code for your implementation. Users can look at your header files to
glean how to use it, but this does not define the behavior of the API, such as acceptable input
values or error conditions. Well-written, consistent, and extensive documentation is therefore
an imperative for any good API .
• The need for automated testing is similarly very high. Of course, you should always test your
code, but when you’re writing an API you may have hundreds of other developers, and
thousands of their users, depending on the correctness of your code. If you are making major
changes to the implementation of your API, you can be more confident that you will not break
your clients’ programs if you have a thorough suite of regression tests to verify that the
desired API behavior has not changed.
Writing good APIs is difficult. While the necessary skills are founded on general software design
principles, they also require additional knowledge and development processes to address the points
just listed. Howeve r, the principles and techniques of API design are rarely taught to engineers. Nor-
mally, these skills are only gained through experience by making mistakes and learning empirically
what does and does not work (Henning, 2009). This book is an attempt to redress this situation, to
distill the strategies of industrial-strength, future-proof API design that have been evolved through
years of software engineering experie nce into a comprehensive, practical, and accessible format.
TIP
An API describes software used by other engineers to build their applications. As such, it must be well designed,
documented, regression tested, and stable between releases.
1.3 WHY SHOULD YOU USE APIs?
The question of why you should care about APIs in your own software projects can be interpreted in
two different ways: (1) why should you design and write your own APIs or (2) why should you use
APIs from other providers in your applications? Both of these perspectives are tackled in the follow-
ing sections as I present the various benefits of using APIs in your projects.
1.3.1 More Robust Code
If you are writing a module to be used by other developers, either for fellow engineers within your
organization or for external customers of your library, then it would be a wise investment to create
an API for them to access your functionality. Doing so will offer you the following benefits.
• Hides implementation. By hiding the implementation details of your module, you gain the
flexibility to change the implementation at a future date without causing upheaval for your
users. Without doing so, you will either (i) restrict yourself in terms of the updates you can
make to your code or (ii) force your users to rewrite their code in order to adopt new versions
of your library. If you make it too onerous for your clients to update to new versions of your
software, then it is highly likely that they will either not upgra de at all or look elsewhere for
an API that will not be as much work for them to maintain. Good API design can therefore
significantly affect the success of your business or project.
6 CHAPTER 1 Introduction
• Increases longevity. Over time, systems that expose their implementation details tend to
devolve into spaghetti code where every part of the system depends on the internal details
of other parts of the system. As a result, the system becomes fragile, rigid, immobile, and vis-
cous (Martin, 2000). This often results in organizations having to spend significant effort to
evolve the code toward a better design or simply rewrite it from scratch. By investing in good
API design up front and paying the incremental cost to maintain a coherent design, your soft-
ware can survive for longer and cost less to maintain in the long run. I’ll delve much deeper
into this point at the start of Chapter 4.
• Promotes modularization. An API is normally devised to address a specific task or use case.
As such, APIs tend to define a modular grouping of functionality with a coherent focus.
Developing an application on top of a collection of APIs promotes loosely coupled and mod-
ular architectures where the behavior of one module is not dependent on the internal details of
another module.
• Reduces code duplication. Code duplication is one of the cardinal sins of software engineer-
ing and shoul d be stamped out whenever possible. By keeping all of your code’s logic behind
a strict interface that all clients must use, you centralize the behavior in a single place. Doing
so means that you have to update only one place to change the behavior of your API for all of
your clients. This can help remove duplication of implementation code throughout your code
base. In fact, many APIs are created after discovering duplicated code and deciding to consol-
idate it behind a single interface. This is a good thing.
• Removes hardcoded assumptions. Many programs may contain hardcoded values that are
copied throughout the code, for example, using the filename
myprogram.log whenever data
are written to a log file. Instead, APIs can be used to provide access to this information with-
out replicating these constant values across the code base. For example, a
GetLogFilename()
API call could be used to replace the hardcoded "myprogram.log" string.
• Easier to change the implementation. If you have hidden all of the implementation details
of your module behind its public interface then you can change those implementation details
without affecting any code that depends on the API. For example, you might decide to change
a file parsing routine to use
std::string containers instead of allocating, freeing, and reallo-
cating your own
char * buffers.
• Easier to optimize . Similarly, with your implementation details hidden successfully, you can
optimize the performance of your API without requiring any change s to your clients’ code.
For example, you could add a caching solution to a method that performs some computation-
ally intensive calculation. This is possible because all attempts to read and write your under-
lying data are performed via your API, so it becomes much easier to know when you must
invalidate your cached result and recompute the new value.
1.3.2 Code Reuse
Code reuse is the use of existing software to build new software. It is one of the holy grails of mod-
ern software development. APIs provide a mechanism to enable code reuse.
In the early years of software development, it was common for a company to have to write all of
the code for any application they produced. If the program needed to read GIF images or parse a text
file, the company would have to write all that code in-house. Nowadays, with the proliferation of
71.3 Why should you use APIs?
good commercial and open source libraries, it makes much more sense to simply reuse code that
others have written. For example, there are various open source image reading APIs and XML pars-
ing APIs that you can download and use in your application today. These libraries have been refined
and debugged by many developers around the world and have been battle-tested in many other
programs.
In essence, software development has become much more modular, with the use of distinct com-
ponents that form the building blocks of an application and talk together via their published APIs.
The benefit of this approach is that you don’t need to understand every detail of every software com-
ponent, in the same way that for the earlier house building analogy you can delegate many details to
professional contractors. This can translate into faster development cycles, either because you can
reuse existing code or decouple the schedule for various components. It also allows you to concen-
trate on your core business logic instead of having to spend time reinventing the wheel.
One of the difficulties in achieving code reuse, however, is that you often have to come up with
a more general interface than you originally intended. That’s because other clients may have addi-
tional expectations or requirements. Effective code reuse therefore follows from a deep understand-
ing of the clients of your software and designing a system that integrates their collective interests
with your own.
C
++
APIs AND THE WEB
The trend toward applications that depend on third party APIs is particularly popular in the field of cloud
computing. Here, Web applications rely more and more on Web services (APIs) to provide core functionality. In the
case of Web mashups, the application itself is sometimes simply a repackaging of multiple existing services to
provide a new service, such as combining the Google Maps API with a local crimes statistics database to provide a
map based interface to the crime data.
In fact, it’s worth taking a few moments to highlight the importance of C
++
API design in Web development.
A superficial analysis might conclude that server side Web development is confined to scripting languages, such
as PHP, Perl, or Python (the “P” in the popular LAMP acronym), or .NET languages based on Microsoft’s ASP
(Active Server Pages) technology. This may be true for small scale Web development. However, it is noteworthy
that many large scale Web services use a C
++
backend to deliver optimal performance.
In fact, Facebook developed a product called HipHop to convert their PHP code into C
++
to improve the
performance of their social networking site. C
++
API design therefore does have a role to play in scalable Web
service development. Additionally, if you develop your core APIs in C
++
, not only can they form a high performance
Web service, but your code can also be reused to deliver your product in other forms, such as desktop or mobile
phone versions.
As an aside, one potential explanation for this shift in software development strategy is the result
of the forces of globalization (Friedman, 2008; Wolf, 2004). In effect, the convergence of the Inter-
net, standard network protocols, and Web technologies has created a leveling of the software playing
field. This has enabled companies and individuals all over the world to crea te, contribute, and com-
pete with large complex software projects. This form of globalization promotes an environment
where companies and developers anywhere in the world can forge a livelihood out of developing
software subsystems. Other organizations in different parts of the world can then build end-user
applications by assembling and augmenting these building blocks to solve specific problems. In
terms of our focus here, APIs provide the mechanism to enable this globalization and componentiza-
tion of modern software development.
8 CHAPTER 1 Introduction
剩余445页未读,继续阅读
andysonliang
- 粉丝: 0
- 资源: 9
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- IPQ4019 QSDK开源代码资源包发布
- 高频组电赛必备:掌握数字频率合成模块要点
- ThinkPHP开发的仿微博系统功能解析
- 掌握Objective-C并发编程:NSOperation与NSOperationQueue精讲
- Navicat160 Premium 安装教程与说明
- SpringBoot+Vue开发的休闲娱乐票务代理平台
- 数据库课程设计:实现与优化方法探讨
- 电赛高频模块攻略:掌握移相网络的关键技术
- PHP简易简历系统教程与源码分享
- Java聊天室程序设计:实现用户互动与服务器监控
- Bootstrap后台管理页面模板(纯前端实现)
- 校园订餐系统项目源码解析:深入Spring框架核心原理
- 探索Spring核心原理的JavaWeb校园管理系统源码
- ios苹果APP从开发到上架的完整流程指南
- 深入理解Spring核心原理与源码解析
- 掌握Python函数与模块使用技巧
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功