再说粗粒度

下面是摘录CSDN上的有关粗粒度和细粒度的讨论：

  

    A: 個人理解：對象的粒度就是對象所容納的邏輯  
  粗粒度容納的邏輯多，細粒度容納的邏輯少    B:轻量级和重量级应该是按占用的资源多少衡量的

    B：对客户暴露了太多细节的相对来说就是细粒度的,比如你的一个Java   Bean,为它所有属性都提供了getter,setter方法,就是属于细粒度的,而如果提供类似   Object   getData(),或者setData(Object   o)这样方法的类就是粗粒度的,个人意见,仅供参考.

    C: 还是不太明白，你这里Object   getData()和setData(Object   o)方法中的Object对象不也隐含的暴露了细节吗？只不过需要多一次从object中取出其属性的手续而已。  
  To   bdsc()   ，我这里提到的粗粒度和细粒度，就权作与各位的一个交流，gof的设计模式我也看过，但太多的地方研究的不是太好！就如这里的粗粒度和细粒度，我好像明白一些，但又说不明白，希望能通过交流讨论理解的更透彻一些！

    D: 粒度似乎是根据项目模块划分的细致程度区分的，一个项目模块（或子模块）分得越多，每个模块（或子模块）越小，负责的工作越细，就说粒度越细，否则为粗粒度   

   E:  这个没有定论   只可意会  
  举个例子，   ejb中的实体bean就是粗粒度的   hibernate中的po就可以做到细粒度  
  如果还是不懂，那么更简单的例子  
  一个user类   其中有email属性   一个用户email很多个     你可以用一个list来表示很多个email  
  也可以再设计一个email类   然后user的email属性是email类组成的  
  那么后一种设计的粒度就更细。它抽象出了更多的模型对应现实逻辑。 

    F:  当客户需要数据的时候,它当然应该知道它的数据是什么样的啊,所以getData(),setData()时的Object   对象对于用户并不是黑箱,用户可以只用一个操作就完成数据的存取,这就是粗粒度的.粒度应该是相对与该类的使用者来说的,如果存取只需要有限的操作,而没有暴露太多的底层实现则是粗粒度的,相反你把每个属性暴露给用户让它都可以对之进行操作则是细粒度的.楼上所说实体Bean,如果我们对它的每个属性都提供getter,setter方法,却不提供getData(),setData()这样的操作,则也是细粒度的,所以在设计Enty   Bean时应该避免设计成细粒度的,因为这为增加网络开销.

   G:  粗粒度：表示类别级，即仅考虑对象的类别(the   type   of   object)，不考虑对象的某个特  
  定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。  
  细粒度：表示实例级，即需要考虑具体对象的实例(the   instance   of   object)，当然，细  
  粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。  
  一般全县权限的设计是解决了粗粒度的问题，因为这部分具有通用性，而细粒度可以看成业务部分，因为其具有不确定性

     H：kingofhawks第二次的解释很详细，我也很清楚了，以前只知道Entity   Bean不适合用于管理细粒度的对象，因为对于细粒度的对象来说，实现、部署EJB和使用JNDI访问开销太高。但不是很明白为什么会这样，现在知道了是因为需要大量存取操作之故。  
  而对于像Spring一样的轻量级容器则更适合管理细粒度的对象，因为它使用IoC使得省去了大量的JNDI查找，也不再需要额外的部署。由于几乎不依赖于容器，实现也更为简单。   
     不知道我这样理解对不对？  

    I:  楼主理解基本正确.粒度这个问题应该在设计时根据具体需求而决定,容器环境,性能要求等等都具有较大的影响.我发现在Java版里大家关注的很多都是非常细节的问题,至于设计方面的讨论太少了,现在觉得设计真的是太关键,在前期多花点工夫,在代码实现,维护,扩展,以及其他非功能性需求如性能等方面的满足上也许我们就不至于会那么焦头烂额了.欢迎大家多发些这种类型的讨论帖子，大家共同提高~~

    J:  粒度这个词语一般在权限管理方面用的比较多，举个例子来说，对于一个模块级别或以上的，就可以叫做粗粒度，对于详细到记录级别的，就可以叫做细粒度。实际上，我觉得这个划分是根据情况而定的，没有完全绝对的粗粒度或细粒度，只是根据你自己的理解所划分的了。  
  知道这个并没有什么实际的意义，我觉得。