对于开发人员来说，工作都是从评估一个需求开始。我们第一个要解决的问题就是看待需求的视角。视角的不同，得到的设计方案可能是完全不同的。作为一个程序员，不能单单从个人视角来看待问题。而是要尝试从不同角色出发，不停思考。

上图是出自一个数据平台7日留存功能。在该原型图中，计算了每天的留存率，并以趋势图的形式呈现出来。常规服务端数据结构定义可能如下：

class RetainRatio {/*** 日期*/private String day;/*** 留存比例*/private double ratio;
}

RetainRatio代表了留存的数据结构，其中day为日期；ratio为留存率。服务端将数据封装为List结构，传递给客户端，由客户端进行展现。

乍看起来没有问题，但是，对于数据平台，可能存在着大量的其他图形分析的需求，如下图是一个行为按日期统计次数的趋势图。

class EventCount {/*** 日期*/private String day;/***次数*/private Integer count;
}

很明显，当整个系统中存在着大量画像分析时，将会出现非常多的数据结构定义。我们再来考虑一下，如此多的定义，带来的程序复杂度。

• 对于服务端开发人员，定义大量数据结构，来承载不同的趋势图结构。

• 对于客户端开发人员，需要理解不同数据结构，并使用不同的代码来渲染和展现UI效果。

程序设计者往往站在数据结构的角度来看待问题，那么，我们从客户端开发人员的角度进行思考。他们根本不想关注数据结构中的day、ratio、count等。而只关注如何将趋势图展现出来。他们唯一需要的就是横坐标和纵坐标。而具体字段的含义，于客户端代码的编写并没有太大关系。

本着解决一类问题，而不是解决一个问题的思路。我们试着将数据结构定义为如下形式：

public class TrendLine {/*** 名称*/private String name;/*** 曲线上的所有点*/private List pointList;
}
class TrendPoint {/*** 纵坐标的值*/private double verticalVal;/*** 横坐标的值*/private String horizontalVal;
}

TreadLine代表了一条趋势线，趋势线上有若干个点List；而每个TrendPoint中含有横坐标（horizontalVal）和纵坐标（verticalVal）。

如此一来，暴露给客户端的数据含义就变为了：线——点——横纵坐标，三个概念。那么整个系统中，所有类似趋势图的图表，均可利用这一结构进行封装。

我们再来看程序的复杂度：

• 服务端多中数据结构定义统一为一种，在计算时，均向该结构统一。

• 客户端不再理解具体的业务意义（天、行为、留存率等等），仅仅理解：线——点——坐标三个概念。UI展示时的代码，也只会有一份。

我们可以将这一思路，提升为“视角”这一概念。系统设计者在设计时，需要综合考量各个角色视角所关注的东西。

• 服务端，关注数据计算。

• 客户端，关注展示，而并不想关注具体业务是什么——例如本例中的天，次数，留存率，行为等等。

• 测试端，只关注计算和展示的结果是否正确，更加不会关注具体数据结构如何封装。

换句话说，上游向下游暴露什么数据，直接决定了下游理解的复杂度。上游向下游暴露的信息，在保证足够的情况下，应该是尽量收敛，而非无限扩散的。