What is "granularity level" and how to identify it?

Question

In the book Design Standards - Reusable object-oriented software solutions by Erich Gamma, in the first chapter introduction we have the following text:

"Designing object-oriented software is difficult, but designing reusable software object-oriented is even more complicated. You must identify relevant objects, factor them into classes at the correct level of granularity, define the interfaces of classes, inheritance hierarchies and establish the key relationships between them."

I would like to know what that level of granularity is and how to identify it.
For this, I ask for an example.

Answer 1

The granularity level would be basically to define a criterion that we will adopt to separate our classes, thinking about the concept of object orientation. For example:
If we have to register an employee with the data of Name, CPF, Date of Birth and Salary; we would think in principle to create the following class Funcionário:

public class Funcionário
 {
     private String nome;
     private String cpf;
     private date datanasc;
     private double salario;

    /*restante do código*/
}

But if we think about reusing this code, we can define a class Pessoa that will contain the attributes that are basic to all people:

public class Pessoa
 {
     private String nome;
     private String cpf;
     private date datanasc;

    /*restante do código*/
}

And so, our Class Funcionário would inherit from person and would have only the field Salary more.

public class Funcionário extends Pessoa
 {
     private double salario;

    /*restante do código*/
}

Therefore, the definition of granularity is who helps us define which attribute will be contained in each class, thus making our code better reusable.

Answer 2

Granularity can be understood as the division level at which objects are built. To address in terms of classification high and low:

Granularity low is the division into many details of objects, commonly with many compositions and few attributes per object; granularity high is the grossest level, objects are left with many attributes and few relations.

I make a parallel with the representation of fiscal notes in some corporate systems, maintained with two objects: NotaFiscalNaoEmitida and NotaFiscalEmitida. It seems to me a good example because it deals with two extremes of the same data and is consistent with this brief reference:

Building objects at the lowest granularity level provides optimal flexibility, but can be unacceptable in terms of performance and memory usage. (free translation)

The first has only a few fields of the invoice and refers to dozens of other entities as Cliente, Produto, Empresa, Endereco, Imposto, etc. Has granularity low.

Once issued and no longer modified, and for performance purposes, historical consistency and storage simplicity, the NotaFiscalEmitida has a copy of all relationship information stored on a single row of the database. The object has an absurd configuration with more than a hundred fields and no relation, but is totally independent of any other entity and self-contained in its data. Has granularity high.