数组的数组方案显然可以工作，但相对于operator()方法来说，缺乏灵活性。尤其是，用[][]方法很难表现的时候，用operator()方法可以很简单的完成，因此[][]方法很可能导致差劲的表现，至少某些情况细是这样的。
例如，实现[][]方法的最简单途径就是使用作为密集矩阵的，以以行为主的形式保存（或以列为主，我记不清了）的物理布局。相反，operator() 方法完全隐藏了矩阵的物理布局，在这种情况下，它可能带来更好的表现。
可以这么认为：operator()方法永远不比[][]方法差，有时更好。
operator() 永远不差，是因为用operator()方法实现以行为主的密集矩阵的物理布局非常容易。因此，当从性能观点出发，那样的结构正好是最佳布局时，operator()方法也和[][]方法一样简单（也许operator()方法更容易一点点，但我不想夸大其词）。 Operator() 方法有时更好，是因为当对于给定的应用，有其它比以行为主的密集矩阵更好的布局时，用 operator() 方法比[][]方法实现会容易得多。 作为一个物理布局使得实现困难的例子，最近的项目发生在以列访问矩阵元素（也就是，算法访问一列中的所有元素，然后是另一列等），如果物理布局是以行为主的，对矩阵的访问可能会“cache失效”。例如，如果行的大小几乎和处理器的cache大小相当，那么对每个元素的访问，都会发生“cache不命中”。在这个特殊的项目中，我们通过将映射从逻辑布局（行，列）变为物理布局（列，行），性能得到了20%的提升。
当然，还有很多这类事情的例子，而稀疏矩阵在这个问题中则是又一类例子。通常，使用operator()方法实现一个稀疏矩阵或交换行／列顺序更容易，operator()方法不会损失什么，而可能获得一些东西――它不会更差，却可能更好。
使用 operator() 方法。
该从外（接口优先）还是从内（数据优先）设计类？从外部！ 良好的接口提供了一个简化的，以用户词汇表达的视图。在面向对象软件的情况下，接口通常是单个类或一组紧密结合的类的public方法的集合. 首先考虑对象的逻辑特征是什么，而不是打算如何创建它。例如，假设要创建一个Stack（栈）类，其包含一个 LinkedList：
class Stack {
public: // …
private:
LinkedList list_;
};
Stack是否应该有一个返回LinkedList的get()方法？或者一个带有LinkedList的set()方法？或者一个带有LinkedList的构造函数？显然，答案是“不”，因为应该从外向里设计接口。也就是说，Stack对象的用户并不关心 LinkedList；他们只关心 pushing 和 popping。
现在看另一个更微妙的例子。假设 LinkedList类使用Node对象的链表来创建，每一个Node对象有一个指向下一个Node的指针：
class Node { /*…*/ };
class LinkedList {
public: // …
private:
Node* f