O que é “nível de granularidade” e como identificá-lo? – orientação-a-objetos design-pattern

No livro Padrões de Projeto – Soluções reutilizáveis de software orientado a objetos de Erich Gamma, logo na introdução do primeiro capítulo temos o seguinte texto:

“Projetar software orientado a objetos é difícil, mas projetar software reutilizável
orientado a objetos é ainda mais complicado. Você deve identificar objetos pertinentes,
fatorá-los em classes no nível correto de granularidade, definir as interfaces das
classes, as hierarquias de herança e estabelecer as relações-chave entre eles.”

Gostaria de saber o que é esse nível de granularidade e como identificá-lo.
Para isso, peço um exemplo.

O nível de granularidade seria basicamente definirmos um critério que iremos adotar para separar as nossas classes, pensando no conceito de orientação a objetos. Por exemplo:
Se temos que cadastrar um funcionário com os dados de Nome, CPF, Data de Nascimento e Salário; pensaríamos a princípio em criar a seguinte classe Funcionário:

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

    /*restante do código*/
}

Porém se formos pensar em reutilizar esse código, podemos definir uma classe Pessoa que vai conter os atributos que são básicos a todas as pessoas:

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

    /*restante do código*/
}

E assim sendo, nossa Classe Funcionário herdaria de pessoa e teria apenas o campo Salário a mais.

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

    /*restante do código*/
}

Portanto, a definição da granularidade é quem nos ajuda a definir qual atributo estará contido em cada classe, tornando assim nosso código melhor reutilizável.

Granularidade pode ser entendida como o nível de divisão em que os objetos são construídos. Para abordar em termos de classificação alta e baixa:

Granularidade baixa é a divisão em muitos detalhes dos objetos, comumente com muitas composições e poucos atributos por objeto; granularidade alta é o nível mais grosseiro, os objetos ficam com muitos atributos e poucas relações.

Faço um paralelo com a representação de notas fiscais em alguns sistemas corporativos, mantida com dois objetos: NotaFiscalNaoEmitida e NotaFiscalEmitida. Me parece um bom exemplo porque trata de dois extremos dos mesmos dados e é coerente com esta breve referência:

Construir objetos ao nível mais baixo de granularidade fornece flexibilidade ótima, mas pode ser inaceitável em termos de desempenho e uso de memória. (tradução livre)

A primeira possui só alguns campos próprios da nota fiscal e faz referência a dezenas de outras entidades como Cliente, Produto, Empresa, Endereco, Imposto, etc. Tem granularidade baixa.

Uma vez emitida e não mais modificada, e para fins de desempenho, consistência do histórico e simplicidade de armazenamento, a NotaFiscalEmitida tem uma cópia de todas as informações das relações armazenada em uma única linha do banco de dados. O objeto tem uma configuração absurda com mais de uma centena de campos e nenhuma relação, mas é totalmente independente de qualquer outra entidade e autocontido em seus dados. Tem granularidade alta.