从某个实例看公共库的设计

先看一个实例：
有一个公共库（下面称之为D)，提供了很多公共模块，内存管理是其中之一，内存管理包括了内存分区（静态内存区，动态内存区，扩展内存
区），申请释放，泄露检测，破坏检测等功能。某一个组件（下面称之为V）使用了公共库的内存管理，从扩展分区中申请了内存，V组件会有
缓存--会把申请到的内存缓存起来使用。


问题来了，由于D默认会使能泄露检测，导致认为V缓存的内存是泄露了，然后报错了。


双方争论，认为这个泄露要对方处理：
1、D的理由是公共库不能因为V这样的使用，而把检测给关闭，现在的使用上，很多有缓存的产品都是通过钩子过滤的，V也应该采取类似处理
，提供钩子，注册到D去过滤。


2、V的理由是这是很常见的一种使用内存的方法，使用过滤不合理，要求D关闭检测。


3、困难的是D没有关闭接口，只有过滤接口，作为公共库，直接关闭，会影响其他使用D的产品，因为他们认为D默认是启动检测的，D如果关闭
了，其他使用D的产品需要增加启动D检测的功能。


实际上，个人理解，V的诉求是正确的，D作为公共库，应该是只提供机制，但怎么使用应该由用户决定，D开始的默认启动泄露检测是错误的，
毕竟申请出来的内存做缓存是很常见的一种用法，一般情况D应该是：1，默认关闭泄露检测，使能破坏检测，这样可以满足大多数场景下的应
用；2，D另外提供内存池的配置接口，用户可以开启关闭检测功能。
被动的是D开始设计没有考虑周全，只提供了钩子过滤，而没有配置接口，导致了问题。


而作为一个公共库，后续如果要改动，其代价更是巨大，涉及配套产品太多了。


只提供机制，如何使用应该由用户决定，此为公共库的设计原则。