代码的粒度（Granularity）
刚入行时候，从一10年+经验前辈那第一次听说“粒度”。当时说到方法传参个数问题，大概是说传参多就是细粒度，传参少就是粗粒度。这样描述并不准确。
粒度
“粒度”这个概念可以用到很多不同的地方，百科里介绍了物理学，分动力学，还有一个说的是胶片颗粒（film grain）的粒度，自己并不了解。这里只说编程（面向对象编程）里的粒度。
“粒度”表示的是精确程度问题。粗粒度角度描述一个系统，是关注系统中大的组件；细粒度角度描述一个系统是从组成大组件的小组件，或者更小组件的角度认识系统。
“粒度”此处是用来描述一个系统，或者对比多个系统的术语，它是一个相对的概念。
一个形象的例子：国家由多个省份（包括直辖市，自治区等）构成；每个省份由多个地级市（包括同级别的省会等）构成；每个地级市又由多个区县构成。可以一直细粒度到街道、社区、村等最小的单位。
省相对国家是细粒度的，地级市相对省份是细粒度的... ... 反之，就相对是粗粒度的。
程序开发中的粒度
从整体看某个程序系统，那它就同上边“国家”的概念一样，是粗粒度的，描述的是这个系统整体完成的是什么功能，做的什么事情。
系统功能一般又分为多个模块，大的功能又会分为若干模块或者步骤，粒度一步一步细化，直到最终的某个用户操作（输入内容，下拉选择，上传文件，点击按钮等），具体的功能最终得到实现。这是一个粒度由粗到细的过程。反之就是由细到粗。
再从代码设计的角度来说。代码的结构是由类型之间的关联起来的系统。系统的整体结构（架构）就是系统最粗的粒度，代码也同系统功能一样，也是有模块划分（可能类似功能结构划分，也可能有所区别）。那么从复杂结构代码模块，到其细小的组成部分就是粒度由粗到细的过程。
类型（class）的粒度
类型越复杂，组成类型的字段、类型聚合的字段、类型方法的依赖，越多，那么就说这个类型是粗粒度的。反之，类型越简单，类型就是细粒度的。
细品一下享元模式的定义：运用共享技术有效地支持大量细粒度的对象。
方法的粒度
开头说到“传参多就是细粒度，传参少就是粗粒度”。这样说也不是完全不对，他至少说明了这样一个问题：传参越多，那么从传参角度暴露的方法细节就越多，方法就有可能功能越发的单一，做的事情越具体。至于方法的粒度问题，借用单一职责原则的描述，自认为，方法实现的功能越单一，那么方法的粒度就越细，主要表现可能有：方法传参数量适中，且都是值类型，方法行数适中等。
